Closed neilpa closed 9 years ago
I’ve run into this, too—and IIRC this impedes the use of const(Value.Null)
which would otherwise be what you mean.
Thus far my workaround has been { _, _, _ in … }
— i.e. disambiguate to the 3-parameter version. { _ in … }
doesn’t work because a single _
matches both the overload that does not receive the input and the overload that does (binding it as a 3-tuple). When I use the single parameter I will instead write { blah($0.0) }
, for which the single-argument-as-3-tuple overload wins.
I can think of a couple of potential resolutions:
const(Value.Null)
or { _ in Value.Null }
without a problem.What do you think?
I would lean toward 2. It enables const
and { _ in … }
while single param usage still works with $0.0
as you said (or a less tersely { str, _, _ in … }
).
I would also be hesitant to add more custom operators over the existing set. Instead I would favor a few extra named operator functions for common parsing patterns. Although those deserve a separate issue.
Instead I would favor a few extra named operator functions for common parsing patterns. Although those deserve a separate issue.
I perused the open issues and you've already noted the pain points I've hit so far.
Yeah, I’m leaning that way myself. Going to change the title of this issue to capture that.
I was experimenting with Madness and found the overload of
-->
makes it a bit cumbersome when the mapping doesn't require the original input.Is there a better approach for this sort of thing when parsing keywords, etc.?