Change new alias syntax to alias this : identifier

[9rnsr]

A compiler change for the proposed syntax in here:
dlang/dlang.org#200

[deadalnix]

Why colon instead of = ?

[denis-sh]

To @deadalnix:
As = may be used for aliasing of superclass constructors. See this comment.

[IgorStepanov]

Will be this pull merged before 2063 as have been promised?
By the way, may be make sense to add aliases syntax for multiply alias this?
alias this: Symbol1, Symbol2, Symbol3;
I say only about syntax layer, not semantic.
I want work under alias this issue this summer.
And now, I want to suggest syntax instead of multiply alias this: SymbolX; statements.
This syntax is similar to multiply inheritance syntax and declare some order of subtyping (It's can help us in future).

[Dgame]

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.

[Dgame]

@9rnsr : Do you think this is ready?

[WalterBright]

At this point, the old syntax is fairly entrenched and cannot be removed - does this add enough value to justify having two syntaxes?

[denis-sh]

@WalterBright,

At this point, the old syntax is fairly entrenched and cannot be removed...

There are no proposals to remove anything in this pull and alias y x is already a known old syntax which may eventually be deprecated because of existed alias x = y syntax. I see no reasons to make an exception for alias y this syntax.

does this add enough value to justify having two syntaxes?

We have to have two syntaxes as there are two different things. alias x = y is for one-to-one-aliasing e.g. alias f = func or alias this = super.this (no exactly aliasing, but looks like it for user, currently not supported) in contrary to alias this: x1.

[Dgame]

Will this ever merged?

[denis-sh]

Will this ever merged?

+1, what about something like voting in NG? It's a pity we "deprecated" alias <id> <id> except this case.

[IgorStepanov]

Yes, I'm waiting this pull since 2.063 release.

[mihails-strasuns]

As a late comment - I actually don't like it.
IMHO alias Something this is quite natural spelling for its semantics (contrary to "normal" alias) and having 3 different syntaxe for almost same thing does not sound justified.

[Dgame]

And what if multiple 'alias this' are allowed?
alias foo, bar this? IMO alias this : foo, bar is far more intuitive.

[IgorStepanov]

@Dicebot

IMHO alias Something this is quite natural spelling

Old notation have a big trouble.
When I see list of alias declararions, like this
alias SomeTemplate!(SomeArg1!(int, double), 42)(SomeAnotherName function(Class1, Interface2)) MyAlias;
It's hard to find necessarynecessary alias declaration.

List like

alias MyAlias = ...
alias MyAnotherAlias = ...

is much pretty.

However alias this = notation can't be used for alias this, because it conflicts with aliassing of constructor.
alias this: syntax is similar to inheritance syntax and that is good for me.

[mihails-strasuns]

I'd argue that in case of long weird type string it is good style to write like this:

alias MeaningfulSymbolName = SomeVeryWeirdTemplatedtype;
alias MeaningfulSymbolName this;

( I can only hope it actually works as intended :) )

[denis-sh]

@Dicebot, you arguments and workaround are the same as for non-this alias. And the decision has alread be made to place alias name as first parameter. And I see no difference in current question.

[mihails-strasuns]

I am not sure if I am following. All I am saying is that alias this and alias are quite distinct and right now former does not have motivation for reverse argument order (one that latter had). Thus introduction of new syntax is not justified.

No idea what decision are you speaking about.

[denis-sh]

All I am saying is that alias this and alias are quite distinct and right now former does not have motivation for reverse argument order (one that latter had).

And what I say is I don't see this difference. alias <long long stuff> this makes this keyword harder to see just like alias <long long stuff> abba make abba id harder to see.

[Dgame]

It's pending for nearly a year now. Is this rejected or will this be merged?

[Dgame]

Still open... Comes with 2.065 or 2.066?

[denis-sh]

Still open... Comes with 2.065 or 2.066?

Some people hope...

[JinShil]

@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 alias that this and alias newSymbol = existingSymbol have different semantics, but the syntax should be consistent across the language if at all possible.

[DmitryOlshansky]

@JinShil
Seconded.
The fate of this pull should have been settled long ago (= merged).

[JinShil]

@tgehr posted a proposal on the forum (http://forum.dlang.org/post/ld5c9r$18lt$1@digitalmars.com)

If the consensus is that alias this syntax was a mistake then both forms should be removed and the concept should be re-introduced as specially named member instead:

Assuming that the new member here will just be called opThis (but there
may well be a more descriptive name) and everything else stays the same,
it's eg:

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. opThis for
member forwarding and implicit conversion instead of special alias this
members.

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 alias this = ...; and alias ... this; with completely
different semantics would just be an ugly patchwork, and there really is
no need for special syntax for alias this, especially given that other
features like it (eg. opDispatch) are implemented by having the language
recognize specially named members.

Of course, the design of alias this is also not orthogonal.
Eg. one may want to forward members perfectly without enabling implicit
conversions. (opForward?)

This proposal should be considered.

[JinShil]

As time has passed, and I have been able to digest this issue a little more, I believe that the problem is not the alias this = existingname syntax, but rather that constructors misuse the this keyword. Had that not been done, alias this = existingname would probably be fine.

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 alias this = existingname syntax.

[quickfur]

ping
Any decision on this? Are we going ahead with this, or should we just close it?

[ntrel]

@JinShil I like the opThis idea syntax-wise, but it's not clear how it would work with multiple opThis properties - see: #3998 (comment).

So, unless that can be resolved, and assuming we want to preserve the possibility of constructor forwarding (alias this = ParentClass.this), I suggest we go with this pull's alias this : foo syntax.

[andralex]

I'd say we close this. @9rnsr ? @WalterBright ?

[9rnsr]

Ok.

[ntrel]

Does this mean we should restore the alias this = symbol syntax instead? It would still be better than the current syntax.

[mihails-strasuns]

Does this mean we should restore

I doubt so.