Pow Expressions - not worth the juice?

[Sam Potter]

On Tuesday, 3 February 2026 at 17:50:12 UTC, Walter Bright wrote:
> On 2/3/2026 7:24 AM, user1234 wrote:
>> I must add: this brings the topic of defining global operator 
>> overloads as well. A very old topic in D NG.
>
> This feature is not in D because it leads to impenetrable code. 
> One terrifying example of this is overloading operators such 
> that what looks like ordinary code is actually a regular 
> expression machine.

I had a very interesting experience using D for the 
implementation of a math library earlier last year.

Because of D's import rules, I quickly realized that if I wanted 
to have a generic "operator" like `pow` or `intersect` or `abs` 
or whatever else, what actually made the most sense was to have a 
separate file (e.g. "pow.d") where all the `pow` overloads lived. 
That way, if I wanted to use `pow`, the prescription was simple: 
`import pow;`. All of the issues with precedence between imports 
that crop up when you have `pow` littered all over the place 
simply evaporated.

I've since had to rewrite this library in C++ :( :( but I kept 
this organizational choice and have had close to 0 compilation 
errors that originated from ADL weirdness.

Well, you can see where I'm going with this... `^^` is just 
notation for `pow`... Having to define operators *in* a class 
didn't prevent me from doing anything, but if I had been able to 
define them in `opPow.d` (or whatever), I think the design of my 
library would have been even clearer and more rational.

FWIW, in a math library, overloads of `pow` are myriad: are you 
raising an integer to an integer? No, a matrix to a matrix? Oh... 
a diagonal matrix raised to an arbitrary precision rational 
number... Or maybe a polynomial in the Bernstein basis raised to 
a polynomial in the monomial basis...