Re: [Nmh-workers] nmh internals: argument processing

[Ken Hornstein]

>> But ... it still somehow sticks in my craw the idea of returning an
>> array index.  It just seems wrong to me, somehow.  So I'm going to
>> change your second #define for X to be:
>> 
>> #define X(sw, minchars, id) { sw, minchars, id },
>
>That seems very redundant.  :-)  Like having
>
>    const int foo[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
>
>since you're cementing the relationship between the enum and array index
>through X().  If the two were being haphazardly maintained and at risk
>of divergance then I could see the point.

I understand your point, believe me.  But even though it's redundant,
it still bugs me from a style perspective.  I'm not sure I can even put
it into words.  Also ... I could envision some cases where we might want
to put some common options at the beginning of the array in the
DEFINE_SWITCH_ARRAY() macro.  You'll quite fairly point out they could
also be put in the DEFINE_SWITCH_ENUM() macro.  Still, there are cases
already where smatch() can return something that's out of bounds for
the array (AMBIGSW) so I'd rather not return the array index at all.
You still get the value of only putting the enum declaration in one place,
so there's still value here.

--Ken