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