operator overloading outside the type

[sfp]

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