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
