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@puremagic.com <mailto:digitalmars-d@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.
I think you'll discover that the map's are the more expensive operations. You'll see a huge improvement from that alone.
If people get behind this DIP, I'm completely confident you'll get fold too.
> 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.
The grammar for binary expression is easy to interact with.
`,` separators are NOT a binary expression, they are frequently just hard-wired into the grammar as separators, and so everywhere a comma appears in the grammar where the value may be involved in an expansion need to have grammatical modifications, and everywhere that a comma is not present in the grammar where an expansion may be accepted must have a grammatical modification to allow commas in that location too.
I haven't tried it, but the thought of hacking in such a change to the grammar everywhere a comma appears terrifies me, resulting ambiguity feels very likely.
Hooking a special token on the right of a binary expression should be a 1-line change however.
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.
static fold has a degenerate edge case (empty tuple), and handling that case has options subject to value judgement. I don't want this DIP to get lost in that debate. There are a few reasonable options in that case, and I could make arguments for and against each option that I can think of.
static fold is probably useful about 10% as often as static map. This DIP as is will make the biggest impact on compile perf and brevity and we should take it as eagerly as we are able.
We'll do fold as an immediate follow up though. If it gets in good shape and it looks no more likely to increase controversy before the DIP's get far through the pipeline, then maybe we can merge the DIPs.