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.)

Reply via email to