New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change new alias syntax to alias this : identifier
#1341
Conversation
Why colon instead of = ? |
To @deadalnix: |
Will be this pull merged before 2063 as have been promised? |
I also thought that this is delivered with 2,063. After all, it was announced on the changelog page of 2,062 for 2063. The release process of D is apparently anything but mature. |
@9rnsr : Do you think this is ready? |
At this point, the old syntax is fairly entrenched and cannot be removed - does this add enough value to justify having two syntaxes? |
There are no proposals to remove anything in this pull and
We have to have two syntaxes as there are two different things. |
Will this ever merged? |
+1, what about something like voting in NG? It's a pity we "deprecated" |
Yes, I'm waiting this pull since 2.063 release. |
As a late comment - I actually don't like it. |
And what if multiple 'alias this' are allowed? |
Old notation have a big trouble. List like
is much pretty. However |
I'd argue that in case of long weird type string it is good style to write like this:
( I can only hope it actually works as intended :) ) |
@Dicebot, you arguments and workaround are the same as for non- |
I am not sure if I am following. All I am saying is that No idea what decision are you speaking about. |
And what I say is I don't see this difference. |
It's pending for nearly a year now. Is this rejected or will this be merged? |
Still open... Comes with 2.065 or 2.066? |
Some people hope... |
@WalterBright @andralex: I ask that this pull request be acted upon sooner rather than later. As a recent student of D, it caused me quite a bit of confusion, and judging by the answers to some of my questions on the forum, it's causing confusion for others too. Either... alias that this;
alias existingSymbol newSymbol; ... or ... alias this : that;
alias newSymbol = existingSymbol; ... but mixing the two is too inconsistent. I realize |
@JinShil |
@tgehr posted a proposal on the forum (http://forum.dlang.org/post/ld5c9r$18lt$1@digitalmars.com) If the consensus is that Assuming that the new member here will just be called struct Tuple(T...){
T expand;
alias opThis = expand;
}
struct Foo{
int opThis;
}
struct Bar{
@property double opThis(){ return ...; }
} The language would then simply consider members named eg. This will enable what I assume is the more natural use case for the syntax: class C{
this(int x){ ... }
...
}
class D: C{
alias this = super; // (inherit constructors)
this(double y){ ... } // (overload with a new constructor)
} But having both Of course, the design of This proposal should be considered. |
As time has passed, and I have been able to digest this issue a little more, I believe that the problem is not the A related issue is that of inheriting constructors and forwarding posted by @andralex (http://forum.dlang.org/post/heuuk9$1nfq$1@digitalmars.com) in 2009 (Wow! 5 years ago). Perhaps addressing that issue first would shed different light on this issue, maybe even allowing us to go back to using |
ping |
@JinShil I like the So, unless that can be resolved, and assuming we want to preserve the possibility of constructor forwarding ( |
I'd say we close this. @9rnsr ? @WalterBright ? |
Ok. |
Does this mean we should restore the |
I doubt so. |
A compiler change for the proposed syntax in here:
dlang/dlang.org#200