multiple `alias this` suggestion

[Daniel N via Digitalmars-d]

On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:
> On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant wrote:
>> On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
>>> On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
>>> wrote:
>>>> On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
>>>> Schveighoffer wrote:
>>>>> I think you can appreciate that this doesn't scale. Imagine 
>>>>> a case which has 2 or 3 optional alias this items.
>>>>>
>>>>> -Steve
>>>>
>>>> Agreed, not manually, as it is exponential in the number of 
>>>> conditions.
>>>
>>> Image using frameworks which conveniently allow adding 
>>> features to a struct...
>>>
>>> struct Beholder
>>> {
>>>   mixin Entity!Movable;
>>>   mixin Render!"Beholder.png";
>>> }
>>>
>>> ... then you couldn't even solve it manually without 
>>> rewriting the framework.
>>>
>>> With distributed 'alias this' you could seamlessly combine 
>>> any number of frameworks from different vendors.
>>
>> Please explain "seamlessly" with the prospect of name 
>> collisions.
>
> :) Disclosure: I have a negative view of mixin templates. 
> Entanglement with names at the landing site is unhappy.
>

You don't have to fear mixin collisions since there is an 
awesomely designed builtin feature to solve this issue.

mixin template fun() { int a; }

struct A
{
     mixin fun f1;
     mixin fun f2;
}

void main()
{
     auto a = A();

     a.f1.a = 1;
     a.f2.a = 2;
}