multiple `alias this` suggestion

[Carl Sturtivant via Digitalmars-d]

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.

The idea of mixin template instantations bringing in AliasThis 
declarations is amplifying my negative view. Still, I suppose 
this could be made to work following analogous rules. Yuck.

Do we even need mixin templates when some form of multiple 
AliasThis is available? And if that form is really clean, haven't 
we then gained something?