Should we add `a * b` for vectors?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Oct 6 20:36:47 UTC 2017


On Friday, October 06, 2017 21:58:04 Timon Gehr via Digitalmars-d wrote:
> On 06.10.2017 00:04, Jonathan M Davis wrote:
> >> I'm very much in favor of this. Also, those rewrites should be
> >> consistently applied for all types, even built-ins (the compiler
> >> implementation can be more complex, but the language rules would be
> >> simplified).
> >> One immediate benefit would be that opCmp could be reliably used for
> >> all
> >> types that support comparison, for example 2.opCmp(3).
> >> Another benefit would be that operators such as += can reassign class
> >> references, for example when a value type is implemented as a unique
> >> reference to immutable data.
> >
> > Being able to do 2.opCmp(3) would be pretty cool, but I'm still
> > convinced
> > that allowing for operators to be overloaded outside of the type is a
> > terrible idea. It's far cleaner for them to be tied to the type
>
> It's far from clean because it enforces a certain calling convention.

It forces them to actually be designed with the type and be easily located
with the type. Would you want a programmer to be able to go and implement
opBinary!"+" for strings? I sure wouldn't. And I don't want anyone doing
that for user-defined types that they didn't define either.

> > - especially
> > when you consider that it's not possible to differentiate between
> > conflicting overloadeded operators.
>
> This is just not true. D has enough mechanisms for differentiating
> between conflicting overloads.

It isn't possible to differentiate when you do foo + bar, though I suppose
that it would then be possible to differentiate if you called
foo.opBinary!"+"(bar). However, that completely defeats the purpose of
overloaded operators.

> > And having them declared outside of the
> > type just opens up all of the problems that were just being complained
> > about in this thread with templated code not being able to access free
> > functions that weren't imported in the module that it's in.
>
> Those are UFCS issues, but I'd rather have UFCS than no UFCS.

And I'd rather never see operators overloaded by anything but the type
they're for.

- Jonathan M Davis



More information about the Digitalmars-d mailing list