New names - 2.068 roundup

[Steven Schveighoffer via Digitalmars-d]

On 6/24/15 9:50 AM, Vladimir Panteleev wrote:
> On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
>> We disagreed on this on irc, but I ask you to consider the following
>> which limits the code breakage a lot more than my first proposal in chat:
>>
>> [...]
>
> Some thoughts:
>
> - I think the implementation is better done through composition (i.e. a
> function that takes any range, and returns a type that works like that
> range but also allows implicit conversion to string. Not sure how
> feasible this is, maybe multiple alias this will help.
>
> - On the performance side, one point is that this grows the size of the
> struct by two machine words (string's .ptr and .length). This type is
> likely to be passed by value through function parameters, too.
>
> - Another perf. issue is that this introduces additional cost every time
> the implicit conversion to string is done (you need to at least check if
> the string value has been calculated).

I think these points are not quite as bad as you think:

1. Any code that was written to use the string version is currently 
passing a string for the extension. Only provide a cached conversion to 
string if that is the case (i.e. you have 2 strings passed in), and 
we'll be fine for existing code. Store the cached string into one of the 
two stored ranges. Don't even bother allowing conversion from non-string 
ranges to a string, just don't compile. This solves the space problem.

2. Code that is using the string version can call array, or can 
specifically say "string x = ..." instead of "auto x = ..." to avoid 
extra checks if they want to squeeze out that little test instruction. I 
don't see why we should care about an extra check for code that is 
deprecated or undesirable, and I don't see how the extra check is that 
bad either.

I really like Adam's idea. A lot.

-Steve