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