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
