opConcatAll?

[Petar]

On Thursday, 2 July 2020 at 20:26:15 UTC, Steven Schveighoffer 
wrote:
> On 7/2/20 3:28 PM, Nick Treleaven wrote:
>> On Thursday, 2 July 2020 at 15:47:39 UTC, Steven Schveighoffer 
>> wrote:
>>> a ~ b ~ c ~ d
>>>
>>> will translate to
>>>
>>> a.opConcatAll(b, c, d)
>> 
>> Sounds good, although I think multiple other operations beside 
>> concatenation could benefit from being intercepted:
>> 
>> opNary(string op, T...)(T args)
>> 
>> E.g. perhaps BigInt can avoid one or more reallocations for >2 
>> args. The compiler would try opNary first in that case, and 
>> fallback to successive calls to opBinary as now.
>> 
>> In fact, maybe some types could benefit from intercepting 
>> different operations at once:
>> 
>> opNary(string[] ops, T...)(T args)
>
> That would be awesome, and cover my case!
>
> -Steve

We kind of have this already, but a bit closer to what jmh was 
describing earlier.
Though it's just an implementation detail inside druntime for 
implementing array ops:

https://github.com/dlang/druntime/blob/v2.092.1/src/core/internal/array/operations.d#L15-L36

I think that it would be pretty cool if this technique could be 
applied to user-defined types (e.g. allow library authors to 
provide their own `arrayOp` implementation of their types).