On Friday, 7 February 2014 at 21:02:54 UTC, Daniel Kozak wrote:
>> Is alias this = that not a thing? If not, why?
> Because
> alias this = that;
> alias this = anotherThat;
>
> is wierd

I'm calling FUD here.  It appears the reason it was removed is because '=' can be used for aliasing superclass constructors.

(https://github.com/D-Programming-Language/dlang.org/pull/200#issuecomment-11711854)

On Friday, 7 February 2014 at 22:09:21 UTC, Jesse Phillips wrote:
>
> I'd like for 'alias that this' to go away.
>
> I'm fine with 'alias this = that'
>
> If we must 'alias this : that' or "this implicitly casts to that" is also reasonable to me.
>
> Yes 'alias that this' can stay for backwards compatibility.
>
> No 'alias this : that' has not been implemented (that I'm aware of).

It appears it has been implemented, but not acted upon:
https://github.com/D-Programming-Language/dmd/pull/1341

On 02/08/2014 12:46 AM, Mike wrote:
> On Friday, 7 February 2014 at 22:55:05 UTC, Timon Gehr wrote:
>> On 02/07/2014 11:23 PM, Jakob Ovrum wrote:
>>>>
>>>
>>> Reserving `alias this = ...;` allows adding aliasing of constructors in
>>> the future, assuming it can be meaningfully defined.
>>
>> What a mess that would be. 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.
>
> Timon, this makes a lot of sense.  Would you mind elaborating with a
> simple syntax sample?

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?)

On Saturday, 8 February 2014 at 13:43:23 UTC, Timon Gehr wrote:
> Of course, the design of alias this is also not orthogonal.
> Eg. one may want to forward members perfectly without enabling implicit conversions. (opForward?)

One can easily do that with opDispatch for named members, or using std.typecons.Proxy for all members.

On 02/08/2014 02:59 PM, Jakob Ovrum wrote:
> On Saturday, 8 February 2014 at 13:43:23 UTC, Timon Gehr wrote:
>> Of course, the design of alias this is also not orthogonal.
>> Eg. one may want to forward members perfectly without enabling
>> implicit conversions. (opForward?)
>
> One can easily do that with opDispatch for named members, or using
> std.typecons.Proxy for all members.

That's wrapping, not forwarding.

On Saturday, 8 February 2014 at 14:47:27 UTC, Timon Gehr wrote:
> On 02/08/2014 02:59 PM, Jakob Ovrum wrote:
>> On Saturday, 8 February 2014 at 13:43:23 UTC, Timon Gehr wrote:
>>> Of course, the design of alias this is also not orthogonal.
>>> Eg. one may want to forward members perfectly without enabling
>>> implicit conversions. (opForward?)
>>
>> One can easily do that with opDispatch for named members, or using
>> std.typecons.Proxy for all members.
>
> That's wrapping, not forwarding.

Right, perfect forwarding in D is still quite messy (outside of AliasThis).

On 08/02/2014 13:43, Timon Gehr wrote:
> class C{
>      this(int x){ ... }
>      ...
> }
>
> class D: C{
>      alias this = super; // (inherit constructors)
>      this(double y){ ... } // (overload with a new constructor)
> }

That syntax is indeed confusing if we also had 'alias this : baz' syntax, because it looks quite like you're saying instances of D convert automatically to an instance of C, which is implicit OOP anyway and makes that statement look redundant.

That is not the suggested syntax that causes the conflict. Forwarding constructors would be done like this:

class D: C{
	alias this = super.this;
}

The idea is that 'alias foo = bar' syntax introduces a new symbol called 'foo'.

For the record, constructor forwarding is just an idea I discussed with Kenji, not something that has been accepted necessarily.