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