New names - 2.068 roundup

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 24 June 2015 at 13:50:09 UTC, Vladimir Panteleev 
wrote:
> - I think the implementation is better done through composition

Perhaps, though I was thinking of this as being just a temporary 
step for migration until it is deprecated - it helps a lot of 
code continue to just work, but at the cost of a silent 
allocation which we would want to avoid.

If it needed composition on the usage point, it'd defeat the 
point of minimizing code breakage.

> - 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.

Aye, that's a compromise again - it could just allocate a new 
string in that eager method, but since it is implicit, that could 
easily waste a lot more time than the extra cached string.

Ideally though, a year from now, that'd be deprecated and removed 
in favor of having the user migrate to explicit allocation on 
their end, becoming fully lazy. (That's what I really want to do: 
make phobos all lazy and make the allocation a user-level 
decision, I'm just trying to offer something that has a less 
breakage migration path.)



So my plan is:

1) Change to lazy with the implicit conversion in a 
version(future_phobos) else {} block. Tell everyone this 
conversion sucks and they want to get away from it. Use 
-version=future_phobos to see what code is likely to break when 
they recompile so they can start handling it.

2) Next release, put deprecated("use .array or lazy instead") (or 
maybe not .array as it can yield dchar when you want char, but 
whatever actually works right) on that method.

3) A year later, move this code into a version(D_067_compatible) 
block so the old eager behavior is now opt-in. So now, the 
default build no longer has the alias this, eager method, nor the 
string cache member.

4) Eventually, kill that version too to clean up the code.



That should be a reasonable migration path, with minimal code 
breakage, ample warning, and a really easy fix that the compiler 
tells you about to update your code.