Review of std.net.isemail part 2

[Don]

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.