On 05/10/2017 09:51 PM, Nick Sabalausky (Abscissa) wrote:
This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.
FQNs need fixed. This DIP is just a questionable workaround for our
borked FQNs that that smacks of C++-style "no breakage at all costs"
design philosophies being applied to both D language and D libraries.
I guess that's my overview. More specifically, what I mean is this:
D's system of fully-qualified names ("FQNs") was intended to address the
matter of conflicting symbols: When a symbol name is ambiguous, instead
of blindly choosing one, the compiler errors and forces the programmer
to clarify.
For this DIP to be convincing, I would need to see this DIP address the
following:
1. Why it would be insufficient to simply rely on D's system of FQNs (if
fixed from their current admittedly half-broken state)? Currently, FQNs
are not addressed, or even mentioned at all, in the "Existing solutions"
section.
2. Why having to disambiguate a symbol with a FQN when upgrading a
library is a sufficiently large problem to justify a new language
feature. (This would seem very difficult to justify, since with or
without this DIP, programmer will be informed by the compiler either way
that they need to disambiguate which symbol they want).
Aside from FQNs, I have additional concerns:
3. Can we even except a library's author to *reliably* know ahead of
time they're going to add a symbol with a particular name? Seems to me a
library author would need a magic crystal ball to make effective use of
this feature...
4. Unless...once they've developed a new version of their lib that's
sufficiently close to release that they know that their API changes
won't...umm...change any further, then they retroactively create an
interim "transition" release which adds these "future" declarations...so
that the programmer knows they need to adjust their code to
disambiguate. But again, as in #2, the programmer will be told that
*anyway* when compiling with the new version. So what's the point?
5. Once the programmer *is* informed they need to disambiguate a symbol
(via this DIP or via a normal ambiguous symbol error), it's an
inherently trivial (and inherently backwards-compatible) fix (which
can't always be said of fixing removed-symbol deprecations - as this DIP
tries to draw parallels to). So, unlike deprecated symbols, I fail to
see what non-trivial benefit is to be gained by an "early notification"
of a to-be-added symbol.
I think this DIP would have merit in a language that had a tendency for
symbols to hijack each other. But D's module system already eliminates
that, so AFAICT, the only thing this DIP is left "improving" is to allow
lib authors, only under very select circumstances, to go out of their
way to provide ahead-of-time notice of a guaranteed-trivial fix they
must make (at least once FQNs are actually fixed). Therefore, I find the
whole idea extremely unconvincing.
