I dun a DIP, possibly the best DIP ever

[WebFreak001]

On Thursday, 23 April 2020 at 13:38:10 UTC, Steven Schveighoffer 
wrote:
> 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

sure it's silly but it might be something else than [2] like 
.foobar()

>
> The first instance is not invalid, it's going to be:
>
> (Tup[0] + 10)[2], (Tup[1] + 10)[2], ...
>

I don't quite see how this is? Isn't the ... working on the arary 
index like in the examples? If you had a (Tup + 10)[OtherTup + 
8]... wouldn't it then extend to (Tup + 10)[OtherTup[0] + 8], 
(Tup + 10)[OtherTup[1] + 8], ..., (Tup + 10)[OtherTup[$ - 1] + 8] 
?

If the ... works depending on if the identifier in there is a 
tuple or not it would become extremely random and no longer be 
representable using a context free grammar