DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.