On Monday, 23 June 2025 at 10:14:25 UTC, Jonathan M Davis wrote:
D has done a number of things with overloaded operators to try
to minimize the ability to do what many consider to be
overloaded operator abuse (e.g. using using overloaded
operators to define a DSL - or really much of anything that's
not trying to behave like the operators do for built-in types).
Making it so that you can't add overloaded operators anywhere
but directly to the type itself helps minimize that abuse
(though there are certainly folks who would like to do it, and
there have been discussions / arguments about it in the past).
I think everyone agrees that pointers can be abused, misused, and
used to make things blow up. Yet nobody argues they should be
removed, because it's up to the programmer to do things that make
sense. The restrictions on operator overloading reflect the use
cases of the language designers and nothing more. That's the case
with all language design decisions, but we shouldn't pretend it's
based on any special insight.
The reality is that it forces the programmer to add hacks to get
around it. You end up doing things like
```
struct MyString {
string s;
alias s this;
}
struct MyInt {
int i;
alias i this;
}
```
and then you overload operators on those structs. I'm not sure
I'd call that a win when the only argument behind it is that the
programmer can't be trusted to write proper code. (User-defined
precedence is a different matter completely. There are no
meaningful benefits to it when you can use parens. That seems to
be a big reason people say operator overloading is bad.)