DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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