Breaking cAmEL case on enum Err's

1

Suppose we have:

pub enum FooBarErr {
//
}

where it is intended to be used as

Result<..., FooBarErr>

Now, Rust convention says that we should not use ___underscores___ in FooBarErr, using purely CamelCase instead. However, does anyone else find that enum fields of the form

BlahBlah__Detail

to be much easier to read than BlahBlahDetail

?

Is the use of ___ in Err enums normal, or is it still frowned upon?

2

The first time I read this, my first thought was that double-underscores are reserved, but, now that I actually look, it doesn't seem to actually be written down anywhere in the API guidelines or in the style repo. Apparently, I just sort of assumed that Rust had followed the lead set by C and JavaScript here.

I've also seen procedural macros that use double-underscores, essentially treating the double underscore as reserved for code generation, but that's really just working around poor support for hygiene in the procedural macro API.

In any case, using double-underscore in normal code is never normal, and using underscores in enum variants isn't normal at all. But in any case, if bstr can get away with nonstandard style, then so can you.

3

What would be the actual words for BlahBlah and Detail? For me enum variant names should be short and clear description what this variant means, and lines long detailed description should be placed on the tripple-slash doc comment.

4

@notriddle: Sorry for the confusion, the question should have been better written. It's not "camel case vs double underscore" that I'm asking -- it's "camel case vs underscore" at all that I'm asking. If above, instead of double underscore I was just using a single underscore, would you still have reservations ?

5

Imagine you are implementing a command interface. So you have some object that the user can issue many different commands to. Depending on the state of the object[1], some commands work, some commands fail. Thus, there are lots of functions of type

Result<T, ObjCmdErr>

where ObjCmdErr has shape

Cmd1_Reason1(...),
Cmd1_Reason2(...),
Cmd2_Reason1(...),
Cmd3_Reason1(...),
Cmd3_Reason2(...),
Cmd3_Reason3(...),

I realize that Underscores in general should not be used in Enums -- but in this case, I really like how it visually separates the "Cmd" from the "Reason"

[1] This can't be resolved statically.

6

Don't you have separate functions for each commands? In that case, I'd rather make enum Cmd1Err { Reason1, Reason2, ... } for each commands and let that ObjCmdErr an enum-of-enums.

6 Likes
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.