DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/11/2017 07:19 AM, Steven Schveighoffer wrote:
> On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
>>
>> 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.
>

Yes, I'm aware that's the idea the author had in mind, but that still 
doesn't begin to address this:

What is the *benefit* of requiring of requiring the author to *not* 
provide an implementation until the transition period is over?

I maintain there is no benefit to that. Drawing a parallel to "how you 
do it with deprecated symbols" is not demonstrating a benefit. For that 
matter, I see the parallel with deprecated symbols as being "The 
deprecation tag goes with an implemented function. Symmetry would imply 
that a 'newly added' tag also goes on an implemented function." So the 
symmetry arguments goes both ways. But regardless, what we *don't* 
usually do is develop functionality *after* first finalizing its name. 
That's just silly.

 > 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 lib author makes a guess that they're going to write a 
function with a particular name and the] function is marked as @future.
 > In LV3, the function is implemented and the @future tag is removed.

Fixed step 2 for you.

And yes, that *is* the progression suggested by this DIP, but one of my 
key points is: that's a downright silly progression. This is better:

- In Library version 1 (LV1), the function doesn't exist.
- In LV2, the new function is marked as @new_symbol to prevent the 
(somehow) TERRIBLE HORRIBLE AWFUL consequence of the new symbol causing 
people to be required to toss in a FQN, but there's no harm in STOPPING 
people from actually using the new functionality if they request it 
unambiguously, now is there? No, there isn't.
- In LV3, the @new_symbol tag is removed.


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

Or, if the tag is added to the actual implementation then there IS NO 
FREAKING BREAKING CHANGE until the @new_func or whatever tag is removed, 
but the library user is STILL given fair (albiet useless, imo) warning 
that it will be (kinda sorta) broken (with a downright trivial fix) in a 
followup release.


 > I'd say the need for this tag is going to be very rare,

That's for certain.

 > but necessary when it is needed.

I can't even begin to comprehend a situation where a heads-up about a 
mere "FQN needed here" qualifies as something remotely as strong as 
"necessary". Unless the scenario hinges on the current brokenness of 
FQNs, which seriously need to be fixed anyway.


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

Sounds like useless cognitive bother on the library author for extremely 
minimal (at best) benefit to the library user. Doesn't sound like 
sufficient justification for a new language feature to me.

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

It's going out of the way to create and use a new language feature 
purely out of fear of a trivial breakage situation. Actual breakage or 
not, it's "all breakages are scary and we must bend over backwards 
because of them" paranoia, just the same.