On 04/25/2017 08:33 AM, Steven Schveighoffer wrote:
In the general case, one year is too long. A couple compiler releases
should be sufficient.
* When the @future attribute is added, would one add it on a dummy
symbol or would one provide the implementation as well?
dummy symbol. Think of it as @disable, but with warning output instead
of error.
This is a pointless limitation. What is the benefit of requiring the
author to *not* provide an implementation until the transition period is
over? It runs counter to normal workflow.
Instead, why not just say "Here's a new function. But !!ZOMG!! what if
somebody is already using a function by that name??!? They'd have use
FQNs to disambiguate! Gasp!!! We can't have that! So, fine, if it's that
big of a deal, we'll just instruct the compiler to just NOT pick up this
function unless it's specifically requested via FQN".
That sounds FAR better to me than "Here's a new function, but we gotta
keep it hidden in a separate branch/version/etc and not let anyone use
it until we waste a bunch of time making sure everyone's code is all
updated and ready so that once we let people use it nobody will have to
update their code with FQNs, because we can't have that, can we?"
Pardon me for saying so, and so bluntly, but honestly, this whole
discussion is just stupid. It's full-on C++-grade anti-breakage
hysteria. There are times when code breakage is a legitimate problem.
This is not REMOTELY one of them.
