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.
