On Thursday, 16 March 2017 at 17:12:05 UTC, Jonathan M Davis
wrote:
Unfortunately, the nature of traits is such that altering them
in a fashion that includes a deprecation cycle really doesn't
work. You can deprecate the whole trait, but you really can't
change its behavior without risking code breakage.
While not a nice solution, a pragma(msg,"deprecated") inside a
static if would do the trick. You could also argue for a
static-deprecated language feature.
It wouldn't entirely surprise me if we could get away with just
changing it - I expect that comparatively little code would
break, and the code that did would often be doing stuff like
returning a value of the enum type that's not actually a valid
value of that enum type, so the change would catch bugs - but
the odds are quite high that _someone_ would have correct code
that broke as a result. It's just that most code would either
not care, or it would be broken as-is. Unfortunately, not all
code would be in that boat, so making the change is likely
unacceptable.
Maybe a little bit off-topic, but would it be possible to scrape
github and use dcd or dscanner to count the usages of enums and
isSomeString? Just to measure how big the playing field is.
Sometimes a little measuring brings up surprising insights and
turns choices into no-brainers.
In any case, while it would be nice to be able to deprecate the
fact that isSomeString is true for enums, there's really no way
to do so. The nature of traits just doesn't play well with that.
- Jonathan M Davis
I get your point though, there is no easy out.
