I dun a DIP, possibly the best DIP ever

[Steven Schveighoffer]

On 4/22/20 8:21 PM, Manu wrote:
> On Thu, Apr 23, 2020 at 2:50 AM Steven Schveighoffer via Digitalmars-d 
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic..com>> wrote:
> 
>     On 4/22/20 10:37 AM, Manu wrote:
>      > I think efficient implementation here would depend on a static fold,
>      > which I plan for a follow-up, and it's a very trivial expansion from
>      > this DIP.
>      > Static reduce would allow `...` as an argument to a BinOp
>      > Ie; `Tup + ...` would expand `Tup[0] + Tup[1] + Tup[2] + ...`
>      > You could do `is(FindType == Tup) || ...`, and it would evaluate
>     true if
>      > FindType exists in Tup, with no junk template instantiations!
> 
>     This is awesome, and I'm not seeing why you would save it for later.
> 
> 
> Because it's strictly additive, DIP's with over-reach tend to fail.

Without the folding, I think this feature leaves a lot on the table. I'd 
still be happy with the DIP as-is, but it obviously doesn't help me as 
much in the projects I'm using.

> 
>     In general, couldn't this DIP be done just strictly on binary operators
>     and do what this DIP does with commas?
> 
>     i.e.
> 
>     foo(T) , ... expands to foo(T[0]), foo(T[1]), ..., foo(T[n])
> 
> 
> That looks really grammatically challenging to me. I wouldn't know where 
> to start attempting to implement that :/

Is this not the same difficulty as `Tup + ...` which is what you 
suggested above? I thought it was the same thing.

My thought was that if you went for the binary operator implementation, 
then you have one addition, instead of one now and one later, and the 
binary form can capture everything this DIP captures without needing to 
be an "additional" piece.

-Steve