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