Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly <[email protected]>
wrote:
== Quote from Andrei Alexandrescu ([email protected])'s
article
For the same reason, C accepts enum X { a, b, } but not ,a ,b.
Mechanically generating enum values is easier if each value has a
trailing comma.
This has always seemed weird to me. C doesn't accept a trailing comma
in function parameter lists. I don't mind it accepting commas in enum
blocks mostly because leaving a trailing comma in multi-line blocks
can mean a smaller diff if I want to append new elements to the block
later, but it certainly isn't sufficient to justify the syntax IMO.
You know, this just reminded me of something. What is the purpose of
allowing trailing commas in enums in C? mostly for this:
enum {
val1,
val2,
#ifdef INCLUDE_VAL_3
val3
#endif
};
Which would require some weird preprocessor logic for val2 if a trailing
comma weren't allowed
But hasn't this behavior been *specifically* frowned upon by Walter due
to it's lack of maintainability? In fact, I'd say that except for C
portability (which is becoming more and more a moot argument), we could
get rid of allowing the comma at the end of the last enum definition.
In fact, it would discourage the undesirable behavior of versioning
around elements versus versioning around the enum.
I know the argument is over for splitter, but I just thought this was an
interesting connection to explore.
-Steve
NO! Allowing trailing comma in stuff is great if it's being generated by
CTFE, or if it's just a long list you're adding to/removing
from/commenting parts out during development. I'd rather trailing commas
be allowed in array literals, too.
