[dmd-beta] Migration path for enum Endian?

[Jonathan M Davis]

On Tuesday, September 06, 2011 17:24:42 Andrei Alexandrescu wrote:
> 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.

I'm just saying that it was discussed before and that you were involved in it. 
If we want to revisit it, we can.

> >>> 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.

That may very well be a good idea. I'm just saying that there _will_ be code 
breakage from changing enum values pretty much no matter what you do. It's 
just a question of the nature of the breakage and what the pros and cons of 
going with one type of breakage over another are.

- Jonathan M Davis