Splitter quiz / survey

[Robert Fraser]

Steven Schveighoffer wrote:
> On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly <sean at invisibleduck.org> 
> wrote:
> 
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'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.