April 22, 2017
On Fri, Apr 21, 2017 at 08:32:55PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote:
[...]
> > https://github.com/dlang/dmd/pull/3998/files
> > 
> > It's written against C++ DMD as it was in 2014 so it may not be feasible anymore to easily port it to DDMD.
> 
> This one looks easy to port.
> However I am not sure if those are disired semantics and that was one
> of the points raised against the PR iirc.

I see. So the first thing to do is to work out the desired semantics, before we make another attempt at implementing it.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??
April 24, 2017
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:
> I agree, I like how this solves the ambiguity problem nicely. However, this disallows using introspection to declare multiple alias this piecemeal. e.g.:
>
> struct S(bool foo)
> {
>   int x;
>   alias x this;
>   static if(foo)
>   {
>      string y;
>      alias y this;
>   }
> }
>
> One thing we can do also is just use declaration order to prioritize which alias this to use.

Not necessary in this case:

struct S(bool foo)
{
  int x;
  static if(!foo)
  {
     alias x this;
  }
  else
  {
     string y;
     alias x, y this;
  }
}

It's easier to analyze if  isn't distributed, i.e. if only one location applies.

April 24, 2017
On Friday, 21 April 2017 at 14:51:42 UTC, Meta wrote:
> auto x = top(1,2,3);
>
> void takesMember1(member1) {}
> void takesMember2(member2) {}
> void takesMember3(member3) {}
>
> static assert(__traits(compiles, { takesMember1(x); }));  //Passes
> static assert(__traits(compiles, { takesMember2(x); })); //Passes
> static assert(__traits(compiles, { takesMember3(x); })); //Passes
>
> This is a little bit surprising until you think about it a bit. It's also how we would want multiple alias this to behave were it implemented, which is a plus.

Nice!

April 26, 2017
On Monday, 24 April 2017 at 16:52:49 UTC, Carl Sturtivant wrote:
> On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:
>> I agree, I like how this solves the ambiguity problem nicely. However, this disallows using introspection to declare multiple alias this piecemeal. e.g.:
>>
>> struct S(bool foo)
>> {
>>   int x;
>>   alias x this;
>>   static if(foo)
>>   {
>>      string y;
>>      alias y this;
>>   }
>> }
>>
>> One thing we can do also is just use declaration order to prioritize which alias this to use.
>
> Not necessary in this case:
>
> struct S(bool foo)
> {
>   int x;
>   static if(!foo)
>   {
>      alias x this;
>   }
>   else
>   {
>      string y;
>      alias x, y this;
>   }
> }
>
> It's easier to analyze if  isn't distributed, i.e. if only one location applies.

It's easier to analyze if AliasThis isn't distributed, i.e. if only one location appears in a given instantiation.



April 26, 2017
On 4/24/17 12:52 PM, Carl Sturtivant wrote:
> On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:
>> I agree, I like how this solves the ambiguity problem nicely. However,
>> this disallows using introspection to declare multiple alias this
>> piecemeal. e.g.:
>>
>> struct S(bool foo)
>> {
>>   int x;
>>   alias x this;
>>   static if(foo)
>>   {
>>      string y;
>>      alias y this;
>>   }
>> }
>>
>> One thing we can do also is just use declaration order to prioritize
>> which alias this to use.
>
> Not necessary in this case:
>
> struct S(bool foo)
> {
>   int x;
>   static if(!foo)
>   {
>      alias x this;
>   }
>   else
>   {
>      string y;
>      alias x, y this;
>   }
> }
>
> It's easier to analyze if  isn't distributed, i.e. if only one location
> applies.

I think you can appreciate that this doesn't scale. Imagine a case which has 2 or 3 optional alias this items.

-Steve
April 26, 2017
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. But I think some template machinery could mixin the right stuff in one place avoiding that problem, implanting the existing names in an `alias this`. So
  AliasThis!(x,y,z)
which could detect if each name exists in an instantiation and only use that name if so, and would be placed outside of any `static if` to do the job.

I'm leaning toward the notion that a single AliasThis of the kind I suggested  with a suitable template library to help out with matters such as the one you raised is enough.

(Some name management for shadowed names could be in that library too --- different topic, will discuss elsewhere.)


April 26, 2017
On 4/21/2017 5:17 AM, Andrei Alexandrescu wrote:
> This is interesting, and would be timely to discuss before an implementation of
> multiple alias this gets started. -- Andrei

mixin templates already have an established method for resolving overloads and such with the names they introduce. Any multiple alias this solution should investigate any parallels with that.

April 27, 2017
On Wednesday, 26 April 2017 at 20:19:19 UTC, Walter Bright wrote:
> On 4/21/2017 5:17 AM, Andrei Alexandrescu wrote:
>> This is interesting, and would be timely to discuss before an implementation of
>> multiple alias this gets started. -- Andrei
>
> mixin templates already have an established method for resolving overloads and such with the names they introduce. Any multiple alias this solution should investigate any parallels with that.

The suggestion for multiple alias this I postulate in the original post in this thread is a clean way to avoid that complexity. Here's a summary.
https://forum.dlang.org/post/vkqriubvydntloptgfit@forum.dlang.org

I am leaning toward the view that with some template support from a small library, to help use it effectively inside templates, that it provides a simple and effective solution to the problem. Here's one postulated template.
https://forum.dlang.org/post/irjupadpohusatrzowqu@forum.dlang.org

April 27, 2017
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.

April 28, 2017
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.