DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

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.

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

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

And in override case, there is no backwards compatible solution 
available at all (see Steven comment).


> 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?

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

You describe a typical library that doesn't follow SemVer and 
generally doesn't bother much about providing any upgrade 
stability. Naturally, such library developer will ignore 
`@future` completely and keep following same development patterns.

Not everyone is like that though. This document 
(https://github.com/sociomantic-tsunami/neptune/blob/master/doc/library-maintainer.rst) explains the versioning/development model we use for all D libraries and within such model feature that is written in one major version can be added as `@future` in the previous major version at the same time.

And for druntime object.d case it is pretty much always worth the 
gain to delay merging already implemented addition for one 
release, putting `@future` stub in the one before. There can 
never be any hurry so there is no way to be "late".