On Mon, Apr 24, 2017 at 04:58:12PM +0100, rikki cattermole via Digitalmars-d wrote:
> On 24/04/2017 4:03 PM, Mike Parker wrote:
> > DIP 1007 is titled "'future symbol' Compiler Concept".
> > 
> > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
[...]
> This DIP concerns me, for any other language I would go so far as to saying, I would expect people to overuse this to the extreme. Going by what they "think" they may need in the future instead of what they definitely will need.

Initially I also had the same concern, but after reading the DIP in its entirety, I think it may be worth considering. The DIP, as it stands, proposes to make this feature available *only to the compiler* as a hard-coded list of symbols, meaning that in its first incarnation it will only be used for adding new symbols to e.g., druntime.

*If* it passes this first round of implementation / general usage in the D community, then a followup DIP can be made to make this feature available to the general user.  But if any major issues arise in this first stage, we can simply forego further implementation, perhaps even revert the feature.

I think this is a perfectly acceptable implementation plan. IMO it's worth a try.

(And I would make it a point that IMO the first implementation of this DIP should NOT make this feature generally available to the user; that should be done only as a followup DIP.)


> 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 good and bad.  If overused, it could lead to the situation you described, where people aggressively "reserve" future symbols that eventually turn out to be unnecessary, thus potentially "wasting" good names in the namespace.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On 4/25/17 12:24 PM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Apr 24, 2017 at 04:58:12PM +0100, rikki cattermole via Digitalmars-d wrote:
>> On 24/04/2017 4:03 PM, Mike Parker wrote:
>>> DIP 1007 is titled "'future symbol' Compiler Concept".
>>>
>>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
> [...]
>> This DIP concerns me, for any other language I would go so far as to
>> saying, I would expect people to overuse this to the extreme. Going by
>> what they "think" they may need in the future instead of what they
>> definitely will need.
>
> Initially I also had the same concern, but after reading the DIP in its
> entirety, I think it may be worth considering. The DIP, as it stands,
> proposes to make this feature available *only to the compiler* as a
> hard-coded list of symbols, meaning that in its first incarnation it
> will only be used for adding new symbols to e.g., druntime.
>
> *If* it passes this first round of implementation / general usage in the
> D community, then a followup DIP can be made to make this feature
> available to the general user.  But if any major issues arise in this
> first stage, we can simply forego further implementation, perhaps even
> revert the feature.

I missed this part. Now that I read that, I think we aren't going to gain much by having this language feature internal to the compiler.

If we want to limit usage, what I'd *rather* see is that the @future (or TBD attribute) only has special meaning inside object.d. Having to adjust a hard-coded compiler list seems like it will result in zero PR changes (save the one that prompted this DIP) that might give us any insight into whether this is a useful feature.

If this DIP does not address the actual language, I would vote no. You can always make a special case solution in the compiler without a DIP.

>> 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 good and bad.  If overused, it could lead to the situation you
> described, where people aggressively "reserve" future symbols that
> eventually turn out to be unnecessary, thus potentially "wasting" good
> names in the namespace.

I think this is not really that big of a deal. Other than object.d, there's nothing people absolutely have to include. Just don't import libraries that abuse this, and you won't have this problem.

I'd also hazard to guess that a very popular project that abused this feature would simply develop forks which didn't.

-Steve

On Tuesday, 25 April 2017 at 18:32:09 UTC, Steven Schveighoffer wrote:
> I missed this part. Now that I read that, I think we aren't going to gain much by having this language feature internal to the compiler.

The way I understood it, the feature will only stay internal to the compiler until it's deemed "safe" for general use.

> If we want to limit usage, what I'd *rather* see is that the @future (or TBD attribute) only has special meaning inside object.d. Having to adjust a hard-coded compiler list seems like it will result in zero PR changes (save the one that prompted this DIP) that might give us any insight into whether this is a useful feature.

The proposal does include something like that.

> Alternatively, if it proves to be simpler to implement, the feature can be added as an attribute with reserved double-underscore prefix (i.e. @__future) with compiler checks ensuring that it is not used outside of core.*/std.*/object modules. If that course of action is chosen, such an attribute should be defined in the core.attribute module of DRuntime.

On 4/26/17 4:32 AM, Olivier FAURE wrote:
> On Tuesday, 25 April 2017 at 18:32:09 UTC, Steven Schveighoffer wrote:
>> I missed this part. Now that I read that, I think we aren't going to
>> gain much by having this language feature internal to the compiler.
>
> The way I understood it, the feature will only stay internal to the
> compiler until it's deemed "safe" for general use.

The question I have is: who is going to adjust this list? If the answer is nobody, then when is it deemed "safe" for general use? How do we judge whether it's safe to allow others to use it, when nobody is using it?

What's more useful to me is to require the @future attribute on all new symbols in object.d, and then see how that process works. Given that the very nature of @future is that it's supposed to be temporary, then if we decide it's not worth the hassle, we can just abandon the feature.

>> If we want to limit usage, what I'd *rather* see is that the @future
>> (or TBD attribute) only has special meaning inside object.d. Having to
>> adjust a hard-coded compiler list seems like it will result in zero PR
>> changes (save the one that prompted this DIP) that might give us any
>> insight into whether this is a useful feature.
>
> The proposal does include something like that.

I may have missed it. There's a lot of text, it's hard to see what is actually being proposed and what isn't.

>
>> Alternatively, if it proves to be simpler to implement, the feature
>> can be added as an attribute with reserved double-underscore prefix
>> (i.e. @__future) with compiler checks ensuring that it is not used
>> outside of core.*/std.*/object modules. If that course of action is
>> chosen, such an attribute should be defined in the core.attribute
>> module of DRuntime.
>

I'm wondering if you actually wrote this? It seems to be quoted.

Sure, we can allow such a thing, and prepending double underscores seems like a reasonable thing, since this should be used lightly and infrequently.

-Steve

On Wednesday, 26 April 2017 at 11:26:19 UTC, Steven Schveighoffer wrote:
> I'm wondering if you actually wrote this? It seems to be quoted.

That was a quote from the DIP. (guess I should have used a colon)

On 4/28/17 4:31 AM, Olivier FAURE wrote:
> On Wednesday, 26 April 2017 at 11:26:19 UTC, Steven Schveighoffer wrote:
>> I'm wondering if you actually wrote this? It seems to be quoted.
>
> That was a quote from the DIP. (guess I should have used a colon)

Ah, OK. Sorry for the confusion, I wasn't sure where it came from.

-Steve

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?

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer wrote:
> Really, what you are doing is reserving the overload spot. In cases where the overload would have selected your local function, then you should get no warning (as the additional symbol won't conflict). In cases where your function conflicts with a newly-reserved base class function, then the warning should be that you will eventually need to include the `override` keyword.
>
> Actually, that brings up a problem with this, what is the mechanism to say "maybe override"? Let's say you have:
>
> // in imported library
> class Base
> {
>    void foo() @future;
> }
>
> // in user library
> class Derived : Base
> {
>    void foo() {...} // triggers warning
> }
>
> What is the next step the user has to take to remove the deprecation warning, but still have valid code? If you put override on foo, it's not really overriding anything as Base.foo doesn't really exist (right?). Basically, we need a way to write Derived such that it works with both the @future reserved Base.foo, and the permanent Base.foo. With deprecation, the path is clear, you just stop using that symbol. This is not as clear.
>
> If adding override is allowed even when base symbol doesn't really exist, that might work, but it needs to be explicit in the DIP.

This is a very good point. We'll send a PR with a proposed solution to address this issue soon.

Thanks!

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer wrote:
> Actually, that brings up a problem with this, what is the mechanism to say "maybe override"? Let's say you have:
>
> // in imported library
> class Base
> {
>    void foo() @future;
> }
>
> // in user library
> class Derived : Base
> {
>    void foo() {...} // triggers warning
> }
>
> What is the next step the user has to take to remove the deprecation warning, but still have valid code?

Right now I have two possible approaches in mind.

One is to simply allow overriding `@future` symbol which doesn't require any extra stuff but can be viewed sub-optimal because it couples two loosely related concepts and would require special cases in how future symbols are handled inside compiler (they stop being completely ephemeral).

Other would be an accompanying DIP to be able to specify `overide(strict)` (default, same as plain `override`) vs `override(optional)` to be able to define methods that may or may not override base one, with no specific relation to `@future`.

I don't have any hard opinion on the matter of my own, what do you think?

On 5/10/17 11:15 AM, Dicebot wrote:
> On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer wrote:
>> Actually, that brings up a problem with this, what is the mechanism to
>> say "maybe override"? Let's say you have:
>>
>> // in imported library
>> class Base
>> {
>>    void foo() @future;
>> }
>>
>> // in user library
>> class Derived : Base
>> {
>>    void foo() {...} // triggers warning
>> }
>>
>> What is the next step the user has to take to remove the deprecation
>> warning, but still have valid code?
>
> Right now I have two possible approaches in mind.
>
> One is to simply allow overriding `@future` symbol which doesn't require
> any extra stuff but can be viewed sub-optimal because it couples two
> loosely related concepts and would require special cases in how future
> symbols are handled inside compiler (they stop being completely ephemeral).
>
> Other would be an accompanying DIP to be able to specify
> `overide(strict)` (default, same as plain `override`) vs
> `override(optional)` to be able to define methods that may or may not
> override base one, with no specific relation to `@future`.
>
> I don't have any hard opinion on the matter of my own, what do you think?

I prefer the first one. The reason is simply because it doesn't require any new grammar. The override requirement is already a protection against changing base class. In this case, we have two possible outcomes:

1. The base class finally implements the method and removes future. In this case, the derived class continues to function as expected, overriding the new function.

2. The base class removes the method. In this case, the override now fails to compile. This is not as ideal, as this does not result in a version that will compile with two consecutive versions of the base. But there is a possible path for this too -- mark it as @deprecated @future :)

-Steve