[dmd-beta] Migration path for enum Endian?

[Andrei Alexandrescu]

On 9/6/11 5:16 PM, Jonathan M Davis wrote:
> On Tuesday, September 06, 2011 17:01:28 Andrei Alexandrescu wrote:
>> On 9/6/11 4:52 PM, Jonathan M Davis wrote:
>>> On Tuesday, September 06, 2011 17:03:30 Nick Sabalausky wrote:
>>>> The names inside std.system.Endian were changed from UpperCamelCase to
>>>> lowerCamelCase, which makes sense, but maybe the old names should
>>>> still
>>>> exist for migration?
>>>
>>> Yu can't rename enum values without breaking code. Any final switches
>>> would be broken if you left in the old values as would anything using
>>> std.traits.EnumMembers.
>>
>> I think EnumMembers is used rarely enough to not warrant much worry. If
>> final switch fails to compile because it doesn't handle all aliases of
>> the same value, that's a bug in the compiler. So I think keeping old
>> values alongside new ones is good practice.
>
> I don't know how rare EnumMembers usage is, but it's definitely used. I use it
> in unit tests and the like. It's probably not a big issue for
> std.system.Endian though. Regardless, it was discussed in the pull request. I
> said that I hadn't provided duplicate enum values with the old names, and you
> merged it in that way.

Doesn't mean we're sworn into that, and now that the problem was raised 
by a second person, I thought I'd put it back on the plate.

>>> A simple renaming is caught and pointed out quite well
>>> by the compiler's spellchecker.
>>
>> Code breakage is what it is.
>
> True. But this is easy-to-fix code breakage. My point is that you _can't_ avoid
> code breakage when renaming enums. It's just a question of what code you're
> going to break, how easy such breakage is going to fix, and how common it is.
> Renamings are going to be more common but very easy to fix. Something like
> EnumMembers may be less common, but it's going to be more subtle when it
> breaks, and the code which uses it would have to be changed to explicitly
> ignore duplicate enum values, which could be problematic.

I don't quite buy into this all. Anyway, perhaps an EnumDistinctMembers 
abstraction would be the best outcome of this discussion.


Andrei