structs, classes, interfaces - Part III, Solution

[Reiner Pope]

Jari-Matti Mäkelä wrote:
> Reiner Pope wrote:
>  
>> I wonder if we can extend the alias this syntax to get rid of the
>> unnecessary symbols. Since, conceptually, aliasing just "binds" the
>> second name to the first, giving the first variable a new name, why
>> don't we just allow variables to be named "this". The code above becomes
>>
>> struct C : IA, IB {
>>      A this;
>>      B this;
>> }
>>
>> To me it's quite consistent with "alias  b this".
> 
> Maybe I'm missing something, but why should alias be used in the first
> place? Currently it's only a weak typedef (extended to other symbols) with
> some overloading semantics. Adding mixin-like behavior inside structs feels
> a bit inconsistent to me at least. Would it also allow aliasing some
> symbols outside the struct? Doesn't it complicate metaprogramming a bit by
> mixing runtime and compile time code?

I think it makes sense in the first place because one of alias's 
meanings is "give the first symbol another name." In the case of "alias 
B this", you are giving B the name, "this". Since all member accesses 
and member functions are of the form

     this.foo

or

    this.func()

(but the "this." may be omitted) it makes sense that if B gets the name 
"this", then it behaves like a member (as far as calling goes).


    -- Reiner