I've made a few minor changes:

* Renamed EmailStatusCode.Off -> None and On -> Any
* Added and clarified the documentation for EmailStatusCode.Any and None
* Updated the documentation

Github: https://github.com/jacob-carlborg/phobos/tree/isemail
Docs: http://dl.dropbox.com/u/18386187/isemail.html

-- 
/Jacob Carlborg

Jacob Carlborg Wrote:

> I've made a few minor changes:
> 
> * Renamed EmailStatusCode.Off -> None and On -> Any
> * Added and clarified the documentation for EmailStatusCode.Any and None
> * Updated the documentation
> 
> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html
> 
> -- 
> /Jacob Carlborg


I believe enum values are to be named lowercase first. EmailStatusCode.any

On 3/30/11 1:30 AM, Jesse Phillips wrote:
> Jacob Carlborg Wrote:
>
>> I've made a few minor changes:
>>
>> * Renamed EmailStatusCode.Off ->  None and On ->  Any
>> * Added and clarified the documentation for EmailStatusCode.Any and None
>> * Updated the documentation
>>
>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>
>> --
>> /Jacob Carlborg
>
>
> I believe enum values are to be named lowercase first. EmailStatusCode.any

I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase.

-- 
/Jacob Carlborg

On 2011-03-30 01:27, Jacob Carlborg wrote:
> On 3/30/11 1:30 AM, Jesse Phillips wrote:
> > Jacob Carlborg Wrote:
> >> I've made a few minor changes:
> >> 
> >> * Renamed EmailStatusCode.Off ->  None and On ->  Any
> >> * Added and clarified the documentation for EmailStatusCode.Any and None
> >> * Updated the documentation
> >> 
> >> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html
> >> 
> >> --
> >> /Jacob Carlborg
> > 
> > I believe enum values are to be named lowercase first. EmailStatusCode.any
> 
> I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase.

All names are camelcased. All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless). enum values fall in the same camp as variables.

We don't really have an actual document anywhere that lays out the style. Andrei has resisted the idea, though I don't think that he's entirely against it, so unfortunately, I don't think that there's currently anywhere that you can look it up. Discussions of the newsgroups have made the decisions on the naming conventions clear though, at least as long as you've paid attention and remember them, which obviously isn't going to happen for newer folks on the list, and unless you're regularly writing Phobos code and making sure that you follow the appropriate conventions, it's probably not all that hard to forget them if they're not what you'd do anyway.

In any case, enum values follow the same style as normal variables - camelcased, beginning with a lowercase letter.

- Jonathan M Davis

Jonathan M Davis wrote:
> On 2011-03-30 01:27, Jacob Carlborg wrote:
>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>> Jacob Carlborg Wrote:
>>>> I've made a few minor changes:
>>>>
>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any
>>>> * Added and clarified the documentation for EmailStatusCode.Any and None
>>>> * Updated the documentation
>>>>
>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
>>>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>>
>>>> --
>>>> /Jacob Carlborg
>>> I believe enum values are to be named lowercase first.
>>> EmailStatusCode.any
>> I don't know what the style guide says about enum members but if that's
>> the case I'll change the names to begin with lowercase.
> 
> All names are camelcased. 

That's not true. ALLCAPS is relatively common in Phobos.
There is absolutely no way PI is going to become pi.

> All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless). 

That part is clear.

> enum values fall in the same camp as variables.

I never heard that before, and it doesn't seem to be true throughout Phobos. Grepping for all enum declarations (there isn't very many of them actually), I found some which were like that, some which start with uppercase, and some which are all caps.

I think you're assuming more concensus on style than has ever actually been discussed.

On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:

> Jonathan M Davis wrote:
>> On 2011-03-30 01:27, Jacob Carlborg wrote:
>>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>>> Jacob Carlborg Wrote:
>>>>> I've made a few minor changes:
>>>>>
>>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation
>>>>>
>>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>>>
>>>>> --
>>>>> /Jacob Carlborg
>>>> I believe enum values are to be named lowercase first. EmailStatusCode.any
>>> I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase.
>> 
>> All names are camelcased.
> 
> That's not true. ALLCAPS is relatively common in Phobos. There is absolutely no way PI is going to become pi.
> 
>> All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless).
> 
> That part is clear.
> 
>  > enum values fall in the same camp as variables.
> 
> I never heard that before, and it doesn't seem to be true throughout Phobos. Grepping for all enum declarations (there isn't very many of them actually), I found some which were like that, some which start with uppercase, and some which are all caps.
> 
> I think you're assuming more concensus on style than has ever actually been discussed.


I think Andrei introduced the camelCase enum convention with his Phobos overhaul back in 2.029.  All new modules, and most modules which have seen major changes since then, follow it -- at least in the public API. Examples include std.algorithm, std.datetime, std.file, std.getopt, std.range and std.stdio.

I wouldn't mind if PI became pi -- I'd never dream of naming a variable pi anyway, unless it's actually supposed to represent π.  Renaming E to e, on the other hand, that's a lot worse.

-Lars

Lars T. Kyllingstad wrote:
> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
> 
>> Jonathan M Davis wrote:
>>> On 2011-03-30 01:27, Jacob Carlborg wrote:
>>>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>>>> Jacob Carlborg Wrote:
>>>>>> I've made a few minor changes:
>>>>>>
>>>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any * Added and
>>>>>> clarified the documentation for EmailStatusCode.Any and None *
>>>>>> Updated the documentation
>>>>>>
>>>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs:
>>>>>> http://dl.dropbox.com/u/18386187/isemail.html
>>>>>>
>>>>>> --
>>>>>> /Jacob Carlborg
>>>>> I believe enum values are to be named lowercase first.
>>>>> EmailStatusCode.any
>>>> I don't know what the style guide says about enum members but if
>>>> that's the case I'll change the names to begin with lowercase.
>>> All names are camelcased.
>> That's not true. ALLCAPS is relatively common in Phobos. There is
>> absolutely no way PI is going to become pi.
>>
>>> All type names begin with an uppercase letter, and all variables begin
>>> with a lowercase letter (with the possible exception of private member
>>> variables beginning with _ - but what's private to a class or struct
>>> isn't as critical as the public API regardless).
>> That part is clear.
>>
>>  > enum values fall in the same camp as variables.
>>
>> I never heard that before, and it doesn't seem to be true throughout
>> Phobos. Grepping for all enum declarations (there isn't very many of
>> them actually), I found some which were like that, some which start with
>> uppercase, and some which are all caps.
>>
>> I think you're assuming more concensus on style than has ever actually
>> been discussed.
> 
> 
> I think Andrei introduced the camelCase enum convention with his Phobos overhaul back in 2.029.  All new modules, and most modules which have seen major changes since then, follow it -- at least in the public API.  Examples include std.algorithm, std.datetime, std.file, std.getopt, std.range and std.stdio.
> 
> I wouldn't mind if PI became pi -- I'd never dream of naming a variable pi anyway, unless it's actually supposed to represent π.  Renaming E to e, on the other hand, that's a lot worse.
> 
> -Lars

Hardly. The only examples I could find were
algorithm: SwapStrategy, SortOutput
range: traverseOptions, SearchPolicy
There are many more which use other conventions, in other modules.

Note that manifest constants (eg, enum int XXX = value;) are completely different to enumerated types (eg, enum XXX { AAA, BBB, CCC } )
They're using a keyword in common, but they're quite different concepts.

On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:

> Lars T. Kyllingstad wrote:
>> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
>> 
>>> Jonathan M Davis wrote:
>>>> On 2011-03-30 01:27, Jacob Carlborg wrote:
>>>>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>>>>> Jacob Carlborg Wrote:
>>>>>>> I've made a few minor changes:
>>>>>>>
>>>>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation
>>>>>>>
>>>>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>>>>>
>>>>>>> --
>>>>>>> /Jacob Carlborg
>>>>>> I believe enum values are to be named lowercase first. EmailStatusCode.any
>>>>> I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase.
>>>> All names are camelcased.
>>> That's not true. ALLCAPS is relatively common in Phobos. There is absolutely no way PI is going to become pi.
>>>
>>>> All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless).
>>> That part is clear.
>>>
>>>  > enum values fall in the same camp as variables.
>>>
>>> I never heard that before, and it doesn't seem to be true throughout Phobos. Grepping for all enum declarations (there isn't very many of them actually), I found some which were like that, some which start with uppercase, and some which are all caps.
>>>
>>> I think you're assuming more concensus on style than has ever actually been discussed.
>> 
>> 
>> I think Andrei introduced the camelCase enum convention with his Phobos overhaul back in 2.029.  All new modules, and most modules which have seen major changes since then, follow it -- at least in the public API. Examples include std.algorithm, std.datetime, std.file, std.getopt, std.range and std.stdio.
>> 
>> I wouldn't mind if PI became pi -- I'd never dream of naming a variable pi anyway, unless it's actually supposed to represent π.  Renaming E to e, on the other hand, that's a lot worse.
>> 
>> -Lars
> 
> Hardly. The only examples I could find were algorithm: SwapStrategy,
> SortOutput
> range: traverseOptions, SearchPolicy
> There are many more which use other conventions, in other modules.

I don't intend to start a big debate about this, but I don't think you looked very hard.  All of the modules I mentioned follow the camelCase convention, and as far as I can tell, none have public enums that follow other conventions.

std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput

std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst, AutoStart

std.file: SpanMode

std.getopt: config (actually not conventional, should be Config, but its members are still camelCased)

std.range: StoppingPolicy, TransverseOptions, SearchPolicy

std.stdio: KeepTerminator


> Note that manifest constants (eg, enum int XXX = value;) are completely different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're using a keyword in common, but they're quite different concepts.

I think a sensible rule is that types (and templates that evaluate to types) start with a capital letter, while values (and functions/templates that evaluate to values) are camelCased.

-Lars

On 3/30/11 10:49 AM, Jonathan M Davis wrote:
> On 2011-03-30 01:27, Jacob Carlborg wrote:
>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>> Jacob Carlborg Wrote:
>>>> I've made a few minor changes:
>>>>
>>>> * Renamed EmailStatusCode.Off ->   None and On ->   Any
>>>> * Added and clarified the documentation for EmailStatusCode.Any and None
>>>> * Updated the documentation
>>>>
>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
>>>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>>
>>>> --
>>>> /Jacob Carlborg
>>>
>>> I believe enum values are to be named lowercase first.
>>> EmailStatusCode.any
>>
>> I don't know what the style guide says about enum members but if that's
>> the case I'll change the names to begin with lowercase.
>
> All names are camelcased. All type names begin with an uppercase letter, and
> all variables begin with a lowercase letter (with the possible exception of
> private member variables beginning with _ - but what's private to a class or
> struct isn't as critical as the public API regardless). enum values fall in
> the same camp as variables.
>
> We don't really have an actual document anywhere that lays out the style.
> Andrei has resisted the idea, though I don't think that he's entirely against
> it, so unfortunately, I don't think that there's currently anywhere that you
> can look it up. Discussions of the newsgroups have made the decisions on the
> naming conventions clear though, at least as long as you've paid attention and
> remember them, which obviously isn't going to happen for newer folks on the
> list, and unless you're regularly writing Phobos code and making sure that you
> follow the appropriate conventions, it's probably not all that hard to forget
> them if they're not what you'd do anyway.
>
> In any case, enum values follow the same style as normal variables -
> camelcased, beginning with a lowercase letter.
>
> - Jonathan M Davis

Ok, then I'll change to that.

-- 
/Jacob Carlborg

On 2011-03-30 04:23, Don wrote:
> Jonathan M Davis wrote:
> > On 2011-03-30 01:27, Jacob Carlborg wrote:
> >> On 3/30/11 1:30 AM, Jesse Phillips wrote:
> >>> Jacob Carlborg Wrote:
> >>>> I've made a few minor changes:
> >>>> 
> >>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any
> >>>> * Added and clarified the documentation for EmailStatusCode.Any and
> >>>> None * Updated the documentation
> >>>> 
> >>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html
> >>>> 
> >>>> --
> >>>> /Jacob Carlborg
> >>> 
> >>> I believe enum values are to be named lowercase first. EmailStatusCode.any
> >> 
> >> I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase.
> > 
> > All names are camelcased.
> 
> That's not true. ALLCAPS is relatively common in Phobos. There is absolutely no way PI is going to become pi.
> 
> > All type names begin with an uppercase letter, and
> > all variables begin with a lowercase letter (with the possible exception
> > of private member variables beginning with _ - but what's private to a
> > class or struct isn't as critical as the public API regardless).
> 
> That part is clear.
> 
>  > enum values fall in the same camp as variables.
> 
> I never heard that before, and it doesn't seem to be true throughout Phobos. Grepping for all enum declarations (there isn't very many of them actually), I found some which were like that, some which start with uppercase, and some which are all caps.
> 
> I think you're assuming more concensus on style than has ever actually been discussed.

I'd have to go digging through the mailing list to find posts on it, but Andrei made it clear that that was what was the intended naming convention and pretty much all of the newer stuff in Phobos follows that convention. Older stuff definitely doesn't follow that convention, but the newer stuff does. In particular, all caps was viewed as bad for enums because of how often they get used in D, and having variables which are all caps used frequently is ugly/annoying. I don't think that there was a huge discussion about it, and I believe that the push for the style I described came primarily from Andrei, but what discussion that there was agreed on treating enum values identically to normal variables as far as their naming coventions go. And all of the newer stuff follows that convention. And since you have to use the enum's name with all of the enum values anyway, it's not like you need a drastic difference in naming to distinguish enums other than manifest constants.

- Jonathan M Davis