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?

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;
}

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.

Here's a way to use single hierarchical AliasThis as per this thread without editing vendor code. No special mechanism for name collisions is needed.

// contain arbitrary names from vendors, & do some renaming if desired
struct EntityWrapper(T)
{
    //one hierarchical AliasThis in here (or none)
  mixin Entity!T;
}
struct RenderWrapper(string s)
{
    //one hierarchical AliasThis in here (or none)
  mixin Render!s;
  alias t2 = t; //e.g.
}

struct Beholder
{
  EntityWrapper!Movable entity;
  RenderWrapper!"Beholder.png" render;
    //one hierarchical AliasThis in here
  alias entity, render this; //if render.t is shadowed, it gets out as t2
}

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.

On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:
> One thing we can do also is just use declaration order to prioritize which alias this to use.

Presumably using declaration order as a means of prioritizing which name wins was rejected as a design possibility in the case of mixin templates which don't do this.

There is a strong parallel between name collisions between multiple mixin template instantions in the same scope, and muliple AliasThis declarations in the same scope: both bring an arbitrary collection of names and their concomitant collisions into that scope.

So presumably using declaration order as a means of prioritizing which name wins in the case of AliasThis would be rejected for the same reasons as for mixin templates.

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
> Image using frameworks which conveniently allow adding features to a struct...
>
> struct Beholder
> {
>   mixin Entity!Movable;
>   mixin Render!"Beholder.png";
> }

Why distribute features as mixin templates when with AliasThis fully implemented they can be distributed as structs and are therefore encapsulated?

struct Beholder
{
    //now Entity(T) is a struct template, not a mixin template
  Entity!Movable entity;
    //ditto
  Render!"Beholder.png" render;
    //in my hierarchical form
  alias entity, render this;
}

Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here.
https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm@forum.dlang.org

Broadly speaking, a mixin template is just "a bunch of unencapsulated declarations". And AliasThis is a way to remove a layer of encapsulation from "a bunch of declarations". (Though it cannot be used currently outside of a struct or class.) This just screams for simplification.

On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote:
> On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
>
> Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here.
> https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm@forum.dlang.org
>

OK, you have a point.

I realise syntax is the least important part of this proposal, but "alias this" is the only alias that still is backwards...

If you do write a DIP at least consider this:
alias this : entity, render;

On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:
> On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote:
>> On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
>>
>> Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here.
>> https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm@forum.dlang.org
>>
>
> OK, you have a point.
>
> I realise syntax is the least important part of this proposal, but "alias this" is the only alias that still is backwards...
>
> If you do write a DIP at least consider this:
> alias this : entity, render;

PS One could of course eat the cake and keep it still, at the cost of additional complexity.

Distributed and prioritized:
alias this : a_prio1, a_prio2, a_prio3;
alias this : b_prio1, b_prio2;

any a* could clash with any b* but a:s wont clash with their own kind since they are internally prioritised the same goes for b:s.

On Wednesday, 3 May 2017 at 19:52:46 UTC, Daniel N wrote:
> On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:
>> On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote:
>>> On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
>>>
>>> Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here.
>>> https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm@forum.dlang.org
>>>
>>
>> OK, you have a point.
>>
>> I realise syntax is the least important part of this proposal, but "alias this" is the only alias that still is backwards...
>>
>> If you do write a DIP at least consider this:
>> alias this : entity, render;
>
> PS One could of course eat the cake and keep it still, at the cost of additional complexity.
>
> Distributed and prioritized:
> alias this : a_prio1, a_prio2, a_prio3;
> alias this : b_prio1, b_prio2;
>
> any a* could clash with any b* but a:s wont clash with their own kind since they are internally prioritised the same goes for b:s.

Reasonable. I may eventually resort to this possibility, but right now I am trying to force out the consequences of avoiding this extra complexity. (And syntax, yes, noted.)

Not finished posting to this thread yet.

On Thursday, 4 May 2017 at 14:09:49 UTC, Carl Sturtivant wrote:
>
> Reasonable. I may eventually resort to this possibility, but right now I am trying to force out the consequences of avoiding this extra complexity. (And syntax, yes, noted.)
>
> Not finished posting to this thread yet.

As no one pointed it out before, FYI there has been a previous DIP (https://wiki.dlang.org/DIP66) on which the old dmd PR was based on.