DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Thursday, 11 May 2017 at 17:35:31 UTC, Nick Sabalausky 
(Abscissa) wrote:
>> 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.

It is mostly discussed in "Comparison with other languages" 
section - it is not a solution for the DIP problem, it is one of 
problems the DIP tries to solve. You put it kind of backwards in 
my opinion.

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

This suggestion seems considerably more complex - it requires 
either additional tools to specify "yes, I truly want to use that 
new function" or forcing developer to always use FQN to do it. 
Required compiler changes are likely to be more convoluted too 
because same symbols would have to be interpreted as regular of 
"fake" ones depending on the context.

Most importantly, I don't see motivation behind it. For 
conservatively maintained libraries defining no-op stub one 
version before introducing actual implementation is hardly a 
problem. Everyone else won't bother about it at all and just add 
new symbols in a regular manner.

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

No, it does not.

That paragraph is a generic rationale why _any_ breaking changes 
without deprecation paths are so painful. I have no interest in 
trying to convince anyone who doesn't get it by now.

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

Yeah, will do.