<div dir="ltr"><div dir="ltr">On Thu, Apr 23, 2020 at 2:50 AM Steven Schveighoffer via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/22/20 10:37 AM, Manu wrote:<br>
> I think efficient implementation here would depend on a static fold, <br>
> which I plan for a follow-up, and it's a very trivial expansion from <br>
> this DIP.<br>
> Static reduce would allow `...` as an argument to a BinOp<br>
> Ie; `Tup + ...` would expand `Tup[0] + Tup[1] + Tup[2] + ...`<br>
> You could do `is(FindType == Tup) || ...`, and it would evaluate true if <br>
> FindType exists in Tup, with no junk template instantiations!<br>
<br>
This is awesome, and I'm not seeing why you would save it for later.<br></blockquote><div><br></div><div>Because it's strictly additive, DIP's with over-reach tend to fail.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In general, couldn't this DIP be done just strictly on binary operators <br>
and do what this DIP does with commas?<br>
<br>
i.e.<br>
<br>
foo(T) , ... expands to foo(T[0]), foo(T[1]), ..., foo(T[n])<br></blockquote><div><br></div><div>That looks really grammatically challenging to me. I wouldn't know where to start attempting to implement that :/</div><div>The current patch in the compiler is extremely sanitary and self-contained, but I can't imagine how to do that without making some pretty aggressive changes to the parser. I think that's likely to have unexpected and far-reaching side-effects.</div><div>It could be expanded to support that syntax in the future, but I'd rather move with the simple definition I have in the DIP today. I think what you describe above is very risky :/</div></div></div>