opConcatAll?

[Andrei Alexandrescu]

On 7/3/20 3:17 AM, Petar Kirov [ZombineDev] wrote:
> 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).

How are parens handled?