multiple `alias this` suggestion

[Carl Sturtivant via Digitalmars-d]

On Friday, 28 April 2017 at 07:07:44 UTC, Daniel N wrote:
> 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;
> }

If having templates with dynamic bindings (set at the landing 
site) of some kind is obligatory, then this is about as good as 
it can get. I wouldn't call it awesome except in the sense that 
it cleverly makes the best of an awkward situation. It's not a 
clean abstraction: subsequently mixing in more "features of a 
struct" into your struct can make a formerly usable name in the 
outside world unusable.

However I am trying to arrive at a mechanism whereby this is 
unnecessary.

AliasThis has the same issues as led to the definition of mixin 
templates if there are multiple such. So there are two broad 
paths that could be followed. The first is to just swallow a 
similar mechanism as mixin templates, and try to allow arbitrary 
interaction among many distributed AliasThis declarations with 
fallback to fully qualified names in the event of ambiguity as in 
your example.

The second path is to endeavor to create a different mechanism 
that does not suffer from that approach, so an additional entity 
can be added to the list of things being aliased-to-this without 
making existing names unusable outside of the definition being 
made, exactly the way mixin templates don't.

I am trying to explore this second path.