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.
