DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 4/25/17 7:29 AM, Jacob Carlborg wrote:
> On 2017-04-24 17:03, Mike Parker wrote:
>> DIP 1007 is titled "'future symbol' Compiler Concept".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. Due to DConf taking place during the review period, the
>> period will be extended by a week. The review period will end at 11:59
>> PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
>> complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> How is this supposed to be used?
>
> * Take the example of the recent __cmp addition to object.d, would we
> say: "this PR has to wait one year because we need to add the @future
> attribute and let users update their code"?

__symbol is reserved by the language. I don't think we need to worry 
about those.

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.

> * If the implementation is provided, is it possible to use the symbol by
> the users the symbol was added for in the beginning? In the above
> example that would be the compiler generating a code to __cmp

I would think the implementation should not be provided. The idea is to 
reserve the symbol for future use, not to implement it. If you add an 
implementation and the compiler allows using that implementation, then 
you potentially break code. This DIP should aim not to break any code.

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.

-Steve