DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.