Fixing enum names in Phobos

[Jonathan M Davis]

Okay. Per the current naming conventions in Phobos, enum values are supposed 
to be camelcased just like any other variable. The enum _type_ is pascal cased 
just like any other user-defined type, but the values are camelcased. A number 
of the older parts of Phobos do not follow this convention. Ideally, this 
would be fixed so that Phobos can be more consistent, and for the most part, 
those in this newsgroup have agreed that they'd prefer to have Phobos fixed to 
be more consistent and put up with the temporary code breakage rather than 
have it permanently inconsistent. The question is whether it's worth it in 
this case. The enums that I'm aware of in Phobos which are not properly 
camelcased are:

std.compiler.Vendor: DigitalMars (and the recently added GNU, LLVM, and 
Unknown).

std.mmfile.MmFile.Mode: Read, ReadWriteNew, ReadWrite, ReadCopyOnWrite

std.JSON_TYPE: STRING, INTEGER, FLOAT, OBJECT, ARRAY, TRUE, FALSE, NULL

std.socket.AddressFamily: UNSPEC, UNIX, INET, IPX, APPLETALK

std.socket.SocketType: STREAM, DGRAM, RAW, RDM, SEQPACKET

std.socket.ProtocolType: IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, IPV6

std.socket.SocketShutdown: RECEIVE, SEND, BOTH

std.socket.SocketFlags: NONE, OOB, PEEK, DONTROUTE

std.socket.SocketOptionLevel: SOCKET, IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, 
IPV6

std.socket.OptionLevel: DEBUG, BROADCAST, REUSEADDR, LINGER, OOBINLINE, 
SNDBUF, RCVBUF, DONTROUTE, SENDTIMEO, RCVTIMEO, TCP_NODELAY, 
IPV6_UNICAST_HOPS, IPV6_MULTICAST_IF, IPV6_MULTICAST_LOOP, IPV6_JOIN_GROUP, 
IPV6_LEAVE_GROUP

std.stream.BOM: UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE

std.system.Endian: BigEndian, LittleEndian

std.traits.ParameterStorageClass: NONE, SCOPE, OUT, REF, LAZY

std.traits.FunctionAttribute: NONE, PURE, NOTHROW, REF, PROPERTY, TRUSTED, 
SAFE

std.traits.Variadic: NO, C, D, TYPESAFE

std.xml.DecodeMode: NONE, LOOSE, STRICT

std.xml.TagType: START, END, EMPTY


So, the question is. Which, if any, should we fix to be camelcased?

It will break code to fix any of these. We can't really go through a clean 
deprecation process on these without outright replacing the enum types 
themselves, which would have a nasty cascading effect through everything that 
uses them. The spellchecker will catch the changes easily, and so fixing any 
code that uses them will be easy, but it will still be annoying. So, is this 
temporary breakage worth the gain in consistency? And if so, for which ones? 
Or should we just leave them as-is?

- Jonathan M Davis