On Tuesday, 28 October 2014 at 19:45:09 UTC, Andrei Alexandrescu
wrote:
On 10/10/14 10:09 AM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
Here's my destruction:
* "symbol can be a field or a get-property (method annotated
with @property and taking zero parameters)." -> actually:
(a) the @property annotation is not necessary
(b) there may be one ore more parameters so long as they're all
defaulted
So the text should be "obj.symbol must be a valid expression".
* "At the AliasThis declaration semantic stage, the compiler
can perform the initial checks and reject the obviously
incorrect AliasThis declarations." -> it might be simpler (for
the sake of simplifying generic code) to just delay all error
checking to the first use.
* I don't think the pseudocode helps a lot. Better let's have a
clear and precise specification (I've edited the lookup order
into an ordered list).
* Regarding the lookup, opDispatch shouldn't come before alias
this, or should come before base class lookup. Essentially
alias this is subtyping so it should enjoy similar privileges
to base classes. A different way to look at it is opDispatch is
a "last resort" lookup mechanism, just one step above the UFCS
lowering.
* The DIP should specify the working of alias this as
rewrites/lowerings, not pseudocode. Basically for each kth
declaration "alias symbolk this;" the compiler rewrites
"obj.xyz" as "obj.symbolk.xyz" and then does the usual lookup
on that expression. That means the whole algorithms is applied
again etc. If more than one rewrite typechecks, that's an
ambiguity error.
* IMPORTANT: The DIP must discuss rvalue vs. lvalue cases. The
rewrite approach simplifies that discussion because it's clear
what happens by simply reasoning about the rewritten
expression. Lvalue vs. rvalue matters a lot practically.
Consider:
struct A
{
private int x;
alias x this;
}
struct B
{
private int _x;
int x() { return x; }
alias x this;
}
Then x can be passed by reference, modified directly etc. for A
but not for B.
===========
Congratulations on taking this to a DIP. It clarifies things
really nice and it's an example to follow for future language
changes.
Andrei
Thanks for answer, I hope, I'll able to to carefully consider
your comments tomorrow.
Now I want to ask about the one thing.
What do you think about compatibility with existing alias this
implementation?
For example you wrote: "Regarding the lookup, opDispatch
shouldn't come before alias this, or should come before base
class lookup.".
This requirement breaks the existing code.
We can apply this change in DIP, however if we want to apply this
change to compiler, we should be careful. Moreover, I don't see
the way to create deprecation path: old
implementation->deprecated old implementation & new
inmplementation -> prohibited old implementation & new
inmplementation.
If we will change the semantic order of proprerty resolving, we
will not able to warn user about changes. Suddenly his code will
be compiled in a different way.
And please comment my way to resolving "is" expression via
alias-this:
http://forum.dlang.org/thread/[email protected]?page=5
Thanks for the DIP review.
