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?
