New names - 2.068 roundup

[Jonathan M Davis via Digitalmars-d]

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