On Saturday, 29 March 2025 at 19:06:18 UTC, Walter Bright wrote:
>
> Nobody understands C++ the language, and far too many C++ code bases are incomprehensible.
>

There is no reason to assume that D fares better than C++ here if D had the same amount of users... If anything arbitrary restrictions wrt operator overloading make D harder to understand. Plus as others have pointed out, the compiler cannot enforce the semantics of an overloaded plus operator whatsoever.

Also, on top of all that, there is no evidence that people think "operators are not functions", many people do think that as that is just the truth. What you do here is you let some random set of anecdotes guide your language design.

On 3/29/2025 12:24 PM, sfp wrote:
> There's nothing preventing people from writing incomprehensible "operator madness"-style code in D. Whether or not `+` behaves like addition is up to the programmer, and where the function `opBinary!"+"` is defined is immaterial.

If an operator overload can only be defined in the definition of the type, then people know where to look for it.


> Open debugger, step into `a+b`. Problem solved.

From just reading code, an overloaded operator will not be apparent.

I recall when David Abrahams wrote a C++ regex package that used operator overloading for regex operations. Seeing it in action, it was surprisingly difficult to figure from reading the code which was C++ code and which was regex code.

It took maybe 10 years for the C++ community to reach the conclusion that iostreams was operator overloading abuse and a bad idea.


> For the highly nontrivial code that I write, being able to define operators as free functions would make my code simpler. Being forced to define them as member functions results in ugly, tortured code.

I have not seen your code and so cannot form an opinion about it. No doubt it is possible to write good code with freestanding operator overloads. But the history of it is not encouraging.

I've often had the fortune (or misfortune!) of having to work on code I haven't touched for 5 years or more, and it being quite baffling. Once I figure it out again, I wind up redoing it for better clarity. Sometimes that meant making the code less clever.

This can work:
```
return a.plus(b);
```

On Sunday, 30 March 2025 at 03:11:48 UTC, Walter Bright wrote:
> On 3/29/2025 12:24 PM, sfp wrote:
>> There's nothing preventing people from writing incomprehensible "operator madness"-style code in D. Whether or not `+` behaves like addition is up to the programmer, and where the function `opBinary!"+"` is defined is immaterial.
>
> If an operator overload can only be defined in the definition of the type, then people know where to look for it.

Not actually true. Frequently in the kind of library that you're referring to, where operator overloading gets abused, some unrelated "helper" class will get returned. Once something like that's going on, all bets are off, and being forced to define your operators in the type is of no help. You can do this in D.

>> Open debugger, step into `a+b`. Problem solved.
>
> From just reading code, an overloaded operator will not be apparent.
>
> I recall when David Abrahams wrote a C++ regex package that used operator overloading for regex operations. Seeing it in action, it was surprisingly difficult to figure from reading the code which was C++ code and which was regex code.
>
> It took maybe 10 years for the C++ community to reach the conclusion that iostreams was operator overloading abuse and a bad idea.

You can write code that is difficult to figure out just from reading with or without operator overloading. And, incidentally, if someone wanted to sit down and start porting David Abrahams' C++ regex library or even iostreams itself to D, I don't think forcing operator to be member functions would stop them.

>
>> For the highly nontrivial code that I write, being able to define operators as free functions would make my code simpler. Being forced to define them as member functions results in ugly, tortured code.
>
> I have not seen your code and so cannot form an opinion about it. No doubt it is possible to write good code with freestanding operator overloads. But the history of it is not encouraging.
>
> I've often had the fortune (or misfortune!) of having to work on code I haven't touched for 5 years or more, and it being quite baffling. Once I figure it out again, I wind up redoing it for better clarity. Sometimes that meant making the code less clever.

I want to be able to define standard mathematical operators for standard mathematical entities (numbers, matrices, polynomials, etc). My code is nontrivial because of the domain I work in, not because of the code itself. By and large, D has helped make the code I've written significantly shorter, clearer, and more understandable than the equivalent C++ code I would have written. In the past I'd all but given up on doing any serious metaprogramming in C++ because of the abysmal compile times, and now I can actually do it. It's damn useful and has made my life easier. It's really a testament to how well designed the language is and how well the features come together.

Not being able to define operators as free functions was a surprising restriction. I've done my best to understand the technical issues surrounding this feature, and my assessment is that there is no real impediment to enabling it other than generational trauma inherited from C++.

On Sunday, 30 March 2025 at 05:30:42 UTC, sfp wrote:
>
> I want to be able to define standard mathematical operators for standard mathematical entities (numbers, matrices, polynomials, etc). My code is nontrivial because of the domain I work in, not because of the code itself.

I suspect it would be possible to use CTFE over strings in order to have an evaluate function return a user defined type (say a matrix), while using normal infix maths operators.

So one would end up with something like:

```
matrix a, b, c;

a = eval!matrix( "b * c" );

```

So that the whole thing would be a compile time transformation.  To what extent one could then do type checking of the expression would be an open question.

On Saturday, 29 March 2025 at 18:48:04 UTC, Walter Bright wrote:
> But overloading operators with freestanding functions? It becomes a nightmare with non-trivial programs.

Even good old Fortran has free operators:

https://en.wikibooks.org/wiki/Fortran/language_extensions#Operator_Overloading

... but it's a nightmare for other reasons. ;-)