DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
> On 04/25/2017 08:33 AM, Steven Schveighoffer wrote:
>>
>> In the general case, one year is too long. A couple compiler releases
>> should be sufficient.
>>
>>>
>>> * When the @future attribute is added, would one add it on a dummy
>>> symbol or would one provide the implementation as well?
>>
>> dummy symbol. Think of it as @disable, but with warning output instead
>> of error.
>>
>
> This is a pointless limitation. What is the benefit of requiring the
> author to *not* provide an implementation until the transition period is
> over? It runs counter to normal workflow.

The idea (I think) is to have a version of the library that functions 
*exactly* like the old version, but helpfully identifies where a future 
version will not function properly. This is like @deprecate. You don't 
put a @deprecate on a symbol and at the same time remove the symbol's 
implementation -- you leave it as it was, and just tag it so the warning 
shows up. That's step one.

> Instead, why not just say "Here's a new function. But !!ZOMG!! what if
> somebody is already using a function by that name??!? They'd have use
> FQNs to disambiguate! Gasp!!! We can't have that! So, fine, if it's that
> big of a deal, we'll just instruct the compiler to just NOT pick up this
> function unless it's specifically requested via FQN".

The point is not to break code without fair warning. This is the 
progression I have in mind:

In Library version 1 (LV1), the function doesn't exist.
In LV2, the function is marked as @future.
In LV3, the function is implemented and the @future tag is removed.

LV1 + user code version 1 (UCV1) -> works
   * library writer updates his version
LV2 + UCV1 -> works, but warns that it will not work in a future version.
   * user updates his code to mitigate the potential conflict
LV2 + UCV2 -> works, no warnings.
LV3 + UCV2 -> works as expected.

The important thing here is that the library writer gives fair warning 
that a breaking change is coming, giving the user time to update his 
code at his convenience. If he does so before the next version of the 
library comes out, then his code works for both the existing library 
version AND the new one without needing to rush a change through.

> That sounds FAR better to me than "Here's a new function, but we gotta
> keep it hidden in a separate branch/version/etc and not let anyone use
> it until we waste a bunch of time making sure everyone's code is all
> updated and ready so that once we let people use it nobody will have to
> update their code with FQNs, because we can't have that, can we?"

It depends on both the situation and the critical nature of the symbol 
in question. I'd say the need for this tag is going to be very rare, but 
necessary when it is needed. I don't think there's a definitive 
methodology for deciding when it's needed and when it's not. Would be 
case-by-case.

> Pardon me for saying so, and so bluntly, but honestly, this whole
> discussion is just stupid. It's full-on C++-grade anti-breakage
> hysteria. There are times when code breakage is a legitimate problem.
> This is not REMOTELY one of them.

This is not anti-breakage. Code is going to break. It's just a warning 
that the breaking is coming.

-Steve