And wouldn't it be possible to create something very close to what you are asking for with a bit of comptime coding? Have the function work on a comptime decided type. I mean I get that you won't be able to use the operator symbols as names and you would lose infix syntax. Is those what you are after?
A control flow problem worth solving is understanding async and multithtreaded code.
And yes the expressiveness of actual infix operators is, to me, a strict requirement. The language is for humans, not machines after all, and stuff like add(mul(add(a, b), mul(a, c))) for, say, dual quaternion a, b, and c is a non starter. Most of my code would unfortunately become unreadable and there are often no sensible variable names for those intermediate results.
Out of curiosity, aren't there other languages designed with more appropriate expressiveness for your needs then? Julia, for example?
Zig supports C ABI, not C++ ABI.
And in the C++ community, doing exports for interop as "extern C" (in general, because many other languages prefer it) is accepted anyways. Would you make the choice to add that complexity?
That alone is already enough to stop most if not all foreign language interfaces from resolving a symbol to a function pointer. That's the simplest hurdle to overcome. There are also complex mechanisms to deal with such as virtual method tables that figure into the calling conventions of overridable methods. Not even C++ compilers manage to keep the ABI stable between every compiler version: sometimes libraries compiled with a new version cannot be used with software compiled by an old version. Rust doesn't even have an ABI specification yet.
That said, I do wish that there was a standardized way to expose vtables across foreign language boundaries. Although, I understand that differences in how vtables work across different languages, or even different implementations of the same language (cough cough c++ cough cough) would make creating a useful standard difficult.
btw, I know it's not as nice as first-class operator overloading, but Zig's comptime might enable writing DSLs for e.g. vector/matrix math: https://www.reddit.com/r/Zig/comments/g83h12/comment/foleoa8
Also I’ve heard that argument a ton. It’s total complete rubbish as far as I’m concerned. Extrapolating, if you see a function call, what really can you say about the “cost” of that function? To me, without actual investigation, the answer is zilch. The function might be inlined, in the i-cache, referencing a lazily loaded symbol. It might be a small function, it might be huge, it may flush the cache, idk. If the goal was to be able to estimate the performance at a glance, well, we should use assembly, and even then the performance isn’t always clear.
The right way to do this is to support arithmetic operators for types that implement a specific interface.