On Wednesday, 24 June 2015 at 13:43:04 UTC, Jacob Carlborg wrote:
Can't we update isSomeString to detect this use case?
We _could_ but that would be a disaster. The whole point of isSomeString is to test whether something is a string exactly. The code used by a function that's overloaded specifically on strings needs to operate on strings. If isSomeString suddenly accepted something which implicitly converted to a string rather than a string, then most functions which used isSomeString in their template constraints, would fail to compile when used with such a range. In general, implicit conversions in template constraints are incredibly dangerous - especially when alias this is involved - because unless the conversion is actually done, the type in question won't act exactly as whatever it converts to, and when given something that implicitly converts, it will either not compile, or it will have incorrect behavior.
A while back, it was temporarily changed so that isSomeString, isIntegeral, etc. accepted implicit conversions, but that was reverted fairly quickly, precisely because it's so dangerous. Templated functions should only be dealing with implicit conversions when they force the conversion.
We could choose to write overloads for Phobos functions which accepted ranges that implicitly converted to string, explicitly convert them to string, and then call the string overload, but then they'd always allocate, whereas maybe the overload which operated on non-strings would have been better, because it wouldn't have required any allocation. So really, what we need is to either change is that strings are ranges of their code unit type rather than dchar, or we need to be using byCodeUnit and friends a lot more. I believe that Walter has been trying to do that with the lazy versions of functions, but any of them which result in ranges of dchar are going to no longer be strings, and even those that use byCodeUnit won't be able to take advantage of overloads for strings or arrays anymore, because they won't be strings.
Part of what we need to do is go through Phobos and make it so that the various range-based functions which operate on strings operate on ranges of char just as well, then byCodeUnit and its ilk can be optimized appropriately. But they're not going to work with the current overloads which take strings, because they are neither arrays nor strings.
- Jonathan M Davis
