I dun a DIP, possibly the best DIP ever

Steven Schveighoffer schveiguy at gmail.com
Mon May 11 21:11:02 UTC 2020


On 5/11/20 3:46 PM, Q. Schroll wrote:
> On Friday, 8 May 2020 at 21:18:26 UTC, Adam D. Ruppe wrote:
>> On Friday, 8 May 2020 at 20:53:39 UTC, Q. Schroll wrote:
>>>     alias Tup = Tuple!(int, long);
>>
>> This is just a struct, the ... shouldn't do anything to it (probably 
>> should be a syntax error).
> 
> It surely is a struct, but it's a struct with an alias-this to a tuple 
> of the kind you're discussing. That's what my question was about.
> 
>> The ... thing is all about compiler tuples which are unfortunately 
>> named the same but totally separate to library tuples.
> 
> I surely can distinguish a language construct from an aggregate type 
> defined in the library. It's not about the library type! I wasn't fooled 
> by the nomenclature, you were.
> 
> You all (maybe with exception of Timon Gehr) got me all wrong. My 
> question wasn't about std.typecons.Tuple per se. It was about 
> alias-this. I used std.typecons.Tuple as a well known example of an 
> aggregate type with an alias-this to a tuple (tuple in the sense you're 
> discussing all the time). See the reference now?
> 
> Consider:
> 
>      struct S(Ts...)
>      {
>          Ts variables;
>          alias variables this;
>      }
> 
>      void f(int, long);
> 
>      auto obj = S!(int, long)(1, 2L);
> 
> Now, per the DIP, will `f( (obj+5)... )` rewrite to 
> `f(obj.variables[0]+5, obj.variables[1]+5))` by going through S's `alias 
> variables this` or would it just ignore alias this altogether?
> 
> Is it better formulated, now that I'm not using an example quite many 
> people here are familiar with?

I think the answer is no.

I think you will have to be explicit in the reference to the variables:

f((obj.variables + 5)...)

This should also work:

f((anyOldStruct.tupleof + 5)...)

and this:

f((someStdTypeconsTuple.expand + 5)...)

There are many expressions that *result* in compiler tuples that would 
NOT be expanded. e.g. template instantiations and the like. I think only 
symbols and __traits expressions should be expanded, and not via alias this.

This is something Manu and I discussed on slack, and I think he was 
going to update the DIP to reflect on how this would work (he may have 
already, I haven't read it in a while).

-Steve


More information about the Digitalmars-d mailing list