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.

https://github.com/dlang/DIPs/pull/63

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
> DIP 1007 is titled "'future symbol' Compiler Concept".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it complete.

This review round is now closed. Thanks to everyone who participated.