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

[Jonathan M Davis via Digitalmars-d]

On Thursday, March 16, 2017 12:55:32 Sebastiaan Koppe via Digitalmars-d 
wrote:
> On Thursday, 16 March 2017 at 07:44:59 UTC, Jonathan M Davis
>
> wrote:
> > So, if we deprecated isSomeString, we'd be telling a lot of
> > folks to change their code when it's perfectly fine as-is. I
> > agree that it would be nice to fix isSomeString, but I just
> > don't think that it's reasonable to deprecate it at this point.
>
> If you can't deprecate, what about only deprecating the enum
> behaviour (e.g. insert a static assert if anybody uses an enum on
> it)?

No, because isSomeString!T is supposed to work with an enum just like it
works with int or a user-defined type Foo. It should be false. A _function_
that inadverently accepted enums could alter its template constraint and add
an overload specifically for enums and deprecate it - though in a lot of
cases, if the function didn't purposefully accept enum, it was going to get
a compilation error anyway when an enum was used with it. But regardless,
the only real options we have with isSomeString are

1. do nothing
2. change it to include !is(T == enum) and break anything that used it in a
   template constraint and actually did work with enums and had enums used
   with it.
3. make the downsides the current behavior in the documentation clear but
   not actually change the code.
4. deprecate it (and presumably replace it with something else that isn't
   true for enums)

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. Changing a trait means that who knows how many template
constraints and static if braches will suddenly pass where they failed
before or fail where they passed before, changing what does and doesn't
compile all over the place.

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.

However, while deprecating isSomeString would not immediately break any code
and would therefore be more acceptable in that regard, it would actually
affect a _lot_ more code - most of which is likely perfectly good code -
which on some level actualy makes deprecating it worse than just changing
it.

Honestly, if I had to choose between just changing isSomeString (possibly
warning about it beforehand) and deprecating it, I'd prefer to just change
it.

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