"alias that this" or "alias this : that"

[Timon Gehr]

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