DIP 1007 Preliminary Review Round 1

[Leandro Lucarella via Digitalmars-d]

On Monday, 24 April 2017 at 15:58:12 UTC, rikki cattermole wrote:
> On the flip side, it would be great for development, feature 
> not yet done but planned? Annotate it. Even before a release 
> ever happens.

This is not the intended usage of this DIP. The intention here is 
to only mark symbols that are already implemented but to avoid 
breakage without a clean (non-breaking) update path in a 
development branch.

This is not to "reserve" symbols for future plan. Even when at 
first this is intended to be used only internally by the compiler 
(and runtime), I will give a more general example:

In semver terms, suppose that you have a library at v1.0.0 
release and you want to add a symbol to a base case that is 
supposed to be subclassed by user code. Normally you will do this 
in a v1.1.0 release, since you are adding a new feature, but 
since adding a new method to a base class is not really a 
non-breaking change, because if user code added a method with the 
same name in a subclass, then it will break.

So this change needs to be delayed for v2.0.0, you write the code 
in that branch to add the method. You don't just plan it. Then 
you go to v1.x.x branch add the `@future` declaring that the 
symbol will appear in an upcoming release. So when you release 
v1.1.0 your user gets a nice warning and can plan how to adapt 
his code to the upcoming v2.0.0.

At some point the user upgrades to v2.0.0 and since he had a 
clean non-breaking update path, what in essence will be a 
breaking change actually never really broke the user's code (if 
he incrementally upgraded from v1.0.0 to v1.1.0 and then v2.0.0). 
Boom!

This not only allows the user to do incremental upgrades without 
*ever* breaking his code, it also *encourages* users to stay up 
to date, since doing so guarantees no breaking changing, while 
making a big jump from an old version to a newer one will in fact 
break his code.

This is the spirit of this DIP. Of course it could be abused, as 
many other features, this is why it is suggested that at first 
it's only available to the compiler. But even if it makes it to 
the user (which I think it will be very beneficial for D), if a 
library author abuses this feature, just educate them, ask not to 
reserve arbitrary symbols as reserving symbols that are not used 
in the short term just annoys the users for no reason. Is like if 
a library author would change the name of the functions in every 
release just for fun. Of course he could do it, but what would be 
the point to it?