Re: Revisiting Userland Operator Overloads

On Fri, Aug 6, 2021, at 3:18 PM, Scott Arciszewski wrote: > My recommendation is to have a base interface for every operator that can > be overloaded, so that these can be composed together. > > AddOverloadInterface { __overloadAdd(): self; } > SubOverloadInterface { __overloadSub(): self; } > MulOverloadInterface { __overloadMul(): self; } > DivOverloadInterface { __overloadDiv(): self; } > ModOverloadInterface { __overloadMod(): self; } > LeftShiftOverloadInterface { __overloadLeftShift(): self; } > RightShiftOverloadInterface { __overloadRightShift(): self; } > XorOverloadInterface { __overloadXor(): self; } > etc. > > Then if you were implementing matrix math, you could do this: > > MatrixMath implements AddOverloadInterface, SubOverloadInterface, > MulOverloadInterface { > > } That would be roughly how Stringable/__toString works now. I'd be OK with that, if it's going to be a language trend. > This prevents you from having to define methods for operations you don't > support. > > It's probably worth exploring whether common combinations are worth > defining for convenience. Now that intersection types are a thing, I don't think combo interfaces are worth much here. If anything, it would be just more impetus for type aliases to reduce typing. (Human typing, I mean, not code typing.) --Larry Garfield