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
