opConcatAll?
Steven Schveighoffer
schveiguy at gmail.com
Fri Jul 3 20:27:10 UTC 2020
On 7/3/20 3:06 PM, Ali Çehreli wrote:
> On 7/2/20 12:28 PM, Nick Treleaven wrote:
>
> > Sounds good, although I think multiple other operations beside
> > concatenation could benefit from being intercepted:
> >
> > opNary(string op, T...)(T args)
>
> Given the confusions raised elsewhere in this thread, I think that
> syntax gives the biggest benefit; defined for a single operator. And we
> don't even need a new keyword:
>
> opBinary(string op, T...)(T args)
Just nitpicking, but opBinary is not a keyword, so neither would opNary be.
>
> which would solve Steve's original issue. Of course, doing the expected
> thing and the associativity issue would still be left to the
> implementer. For example, in order to stay consistent with the rest of
> the type system, the programmer should handle b and c before a below
> because ^^ is right-associative:
>
> a ^^ b ^^ c
>
> Well, we have to trust the programmer anyway.
Any non-commutative operations rely on order of operations. Division,
subtraction, etc.
> So, I propose an extension to opBinary to optionally take multiple
> arguments.
It would be kind of weird/unfortunate for this to support a + b + c, but
not a + b - c.
We could still do it all with opBinary, as:
opBinary(string[] ops, Args...)(Args args)
And either enforce precedence by reordering the operations (like Petar
suggests) into RPN, or give up when precedence isn't strictly
left-to-right. One can always break up the operations into
subexpressions and sub-calls to opBinary/opNary.
I think there are sufficient cases which could benefit from this to
warrant a consideration for making a DIP. What I'm really more concerned
about is pushback on "operator abuse", which clearly this could allow. I
wouldn't go forward without some feedback from Walter.
-Steve
More information about the Digitalmars-d
mailing list