DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/11/2017 06:10 AM, Dicebot wrote:
> On Thursday, 11 May 2017 at 03:46:55 UTC, Nick Sabalausky (Abscissa) wrote:
>> 1. Why are FQNs alone (assume they still worked like they're supposed
>> to) not good enough? Needs to be addressed in DIP. Currently isn't.
>
> It is already addressed in the DIP. FQNs only help if they are used and
> current idiomatic D code tends to rely on unqualified imports/names.
>

I didn't see that. Certainly not in the "Existing solutions" section. It 
needs to be there.

But in any case, I'm not talking about the "existing solution" of 
projects *already* using FQNs for things, I'm talking about the 
"existing solution" of just letting a library user spend two seconds 
adding an FQN when they need to disambiguate.

>> 2. The library user is already going to be informed they need to fix
>> an ambiguity anyway, with or without this DIP.
>
> Only if you consider "after compiler/library upgrade your project
> doesn't work anymore" a sufficient "informing" which we definitely don't.

I definitely do. But even if you don't, see my "@new_func" alternate 
suggestion.

>
>> 3. Updating code to fix the ambiguity introduced by a new symbol is
>> always trivial (or would be if FQNs were still working properly and
>> hadn't become needlessly broken) and inherently backwards-compatible
>> with the previous version of the lib.
>
> Trivial compilation error fixup that takes 5 minutes to address in a
> single project takes up to one month to propagate across all our
> libraries in projects per my experience. Actually fixing code is hardly
> a problem with breaking changes, ever. It is synchronization between
> developers and projects that makes it so painful.
>

This needs to go in the DIP.

> And in override case, there is no backwards compatible solution
> available at all (see Steven comment).

This needs to be made explicit in the DIP. Currently, I see nothing in 
the DIP clarifying that FQNs cannot address the override case.

>> Unlike when symbols being added to a lib, the fix in user-code for a
>> deprecation *can* be non-trivial and *can* be non-backwards-compatible
>> with the previous version of the lib, depending on the exact
>> circumstances. Therefore, unlike added symbols, the "deprecation"
>> feature for removed symbols is justified.
>
> Please elaborate. User code fix is always either using FQN or renaming,
> what non-trivial case comes to your mind?
>

For *added* symbols, yes. Which is why I find this DIP to be of 
questionable value compared to "@deprecated".

That's what my quoted paragraph above is referring to: *removed* (ie, 
deprecated) symbols. When a symbol is *removed*, the user code fix is 
NOT always guaranteed to be trivial. That's what justifies the existence 
of @deprecated. @future, OTOH, doesn't meet the same criteria strength 
because, as you say, when a symbol is added, "User code fix is always 
either using FQN or renaming".