I dun a DIP, possibly the best DIP ever

[Steven Schveighoffer]

On 4/23/20 8:36 AM, WebFreak001 wrote:
> On Wednesday, 22 April 2020 at 12:04:30 UTC, Manu wrote:
>> [...]
>>
>> https://github.com/dlang/DIPs/pull/188
>>
>> [...]
> 
> looking at it again, I actually quite start to like it because when I 
> first looked at it I thought it would start to be a C++ mess like 
> allowing (Tuple + )... to basically work like AST macros and sum 
> together a tuple. But actually thinking about ... as a unary operator 
> like described in the DIP makes it quite clear.
> 
> But how exactly would it handle parentheses? For the most simple 
> implementation I would expect (Tup + 10)[2]... to error because it would 
> first try to evaluate (Tup + 10) like in current D, and thus error, and 
> after that try to expand the Result[2]... - For correct syntax I would 
> think of (Tup + 10)...[2] here

If are looking for the second item out of the tuple, your last 
expression is correct. However, it's kind of silly not to just do:

Tup[2] + 10

The first instance is not invalid, it's going to be:

(Tup[0] + 10)[2], (Tup[1] + 10)[2], ...

which could be valid for some types (they could support opBinary!"+" and 
opIndex)

> 
> If both (Tup + 10)[2]... and (Tup + 10)...[2] however are going to 
> perform the same thing, I can see multiple potential pitfalls because 
> the compiler tries to be too smart.

I think they will be different because of where the ... operator is applied.

> 
> It also says it goes through the expr tree but recursing through the 
> entire expression tree might introduce unexpected issues and would be a 
> non-intuitive experience to the programmer. Take a call like 
> `X!(T!Tup)...` for example: if normally `T!Tup` expects a Tuple as 
> argument but if the ... would go through the entire expression tree, it 
> would change it to: `X!(T!(Tup[0]), T!(Tup[1]), ..., T!(Tup[$-1]))` - 
> performing unwanted expansion of T!Tup when even though I wanted 
> `X!(T!(Tup)[0]), X!(T!(Tup)[1]), ..., X!(T!(Tup)[$-1])`
> 

I had a discussion with Manu on this elsewhere in the thread -- I 
believe he is going to update the DIP to clarify this situation. In 
essence, you have to first evaluate the T!Tup expression into its tuple, 
and then use the result inside the expanding expression for it to work 
properly.

> About the part "f(Items.MemberTup...)" I sent in another reply I think 
> it would very much make sense that it just expands to 
> f(Items[0].MemberTup, Items[1].MemberTup, ...) because when doing an 
> access to a non-tuple member it's also not actually existing on the 
> whole tuple list but only on individual items.

Yep.

> 
> I could actually much rather see a use-case of accessing all members of 
> MemberTup inside the Items tuple, which could probably be realized using 
> __traits(getMember, Items, MemberTup)...
> 

That would be cool. Of course, MemberTup has to be a list of names, but 
a very nice feature -> convert a list of names into a list of members 
without messy templates!

Manu -- another clarification in the DIP is needed here -- __traits is 
not a template, but I think it should be treated similarly. That is, 
__traits(allMembers, Foo)... should be equivalent to 
__traits(allMembers, Foo)

-Steve