On 05/10/2017 11:04 PM, Nick Sabalausky (Abscissa) wrote:
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:
Ugh, frustrating... Seems like every time I try to clarify something I
manage to make a jumbled mess of it. Lemme see one last time if I can
distill that down my basic counter-arguments:
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.
2. The library user is already going to be informed they need to fix an
ambiguity anyway, with or without this DIP.
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.
3. Unlike deprecations, this only provides a heads-up for trivial
matters that don't really need a heads-up notice:
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.
4. Unlike deprecation, this feature works contrary to the actual flow of
development and basic predictability:
When a lib author wants to remove a symbol, they already what the symbol
is, what it's named and that they have X or Y reason to remove it. But
when a lib author wants to add a symbol, it's more speculative: They
don't actually KNOW such details until some feature is actually written,
implemented and just about ready for release. At which point it's a bit
late, and awkward, to go putting in a "foo *will* be added".
