TLBB: The Last Big Breakage

Jesse Phillips Jesse.K.Phillips+D at gmail.com
Sun Mar 16 11:14:34 PDT 2014


On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu 
wrote:
> I believe this is a bridge we do need to cross. One question is 
> how we go about it: all at once, or gradually?

I don't think this is quite the right question to ask. In the 
ideal, all changes would be placed in the compiler all at once 
and we'd have a perfect compiler. The only real answer is to do 
it all at once, if we can achieve that with synchronized that is 
great.

The emphasis on gradual needs to be placed on the upgrade path. 
In the specific example it looks to be a very straight forward 
removal. In this case that just means deprecate first, then in 
the future remove.

I think the upgrade path is so important that planning a sequence 
of changes is more important than "getting it over with" (which 
was valid in the past). To provide an example, if we were to go 
forward with the arr.length = 0 change, the path would look like.

* Provide a way for people to write a "reset" array. This might 
mean a new function to handle the details, or require 
assumeSafeAppend() after assigning length to zero.

* Later deprecate the use of arr.length = 0, in the case of 
requiring assumeSafeAppend() this can be the first step as it 
already exists.

* Another later is to implement arr.length = 0 with the new 
semantics.

* Further on we can deprecate the "reset" function we originally 
created, to eventually remove.

The only change to this process that I see as we gain users is to 
extend how long each of these stages survives. This is based on 
the principle of code should be able to compile with the previous 
and current compiler. Regression fixes applied as a point release 
are exceptions.


More information about the Digitalmars-d mailing list