ranges of characters and the overabundance of traits that go with them

[Sebastiaan Koppe via Digitalmars-d]

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.