DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 5/11/17 1:21 PM, Nick Sabalausky (Abscissa) wrote:
> 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?

How does this work?

class Base
{
   void foo() @future { ... }
}

class Derived : Base
{
   void foo() { ... }
}

void bar(Base b) // could be instance of Derived
{
    // which one is called? Derived.foo may not have been intended for
    // the same purpose as Base.foo
    b.foo();
}

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

No, an implementation is in mind and tested. Just not available. You 
could even have the implementation commented out. In Phobos/Druntime, we 
wouldn't accept such a prospect without requiring a fleshing out of the 
details ahead of time.

If it makes sense to just add the symbol with an implementation, then 
I'd rather do that. Otherwise, we create a new way to overload/override, 
and suddenly things work very differently than people are used to. 
Suddenly templates start calling the wrong thing and code actually 
breaks before a change is actually made.

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

It's also possible to implement the symbol with a different temporary 
name, and use that name if you need it before it's ready.

I'm just more comfortable with a symbol that changes absolutely nothing 
about how a function can be called, but is a warning that something is 
coming than I am with a callable symbol that acts differently in terms 
of overloading and overriding.

I'll admit, I'm not the DIP author, and I don't know the intention of 
whether the implementation is allowed to be there or not.

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

Not sure I agree there would be no breakage. The symbol is there, it can 
be called in some cases. This changes behavior without warning. I've had 
my share of is(typeof(trycallingThis())) blow up spectacularly in ways I 
didn't predict. To change what happens there is a bad idea IMO.

-Steve