Hacker News new | past | comments | ask | show | jobs | submit login

Having operators defined for value types within the langauge spec is different thing than defining operator overloading for arbitrary struct and class types.

For numeric value types mathematical operators are the only sane option.

For arbitrary classes - not so much.

A sane language in the slot of C++ in the language ecosystem would not have operator overloading. It would have matrix types defined in the language spec with mathematical operators operating on them.




One part of the philosophy of the language maintainers is that they're somewhat humble about their designs in the standard library, and very much against breaking changes.

Some folks prefer absl's flat_hash_map over std::unordered_map for a hash table, and it's not great that you need to choose or risk having both in a codebase, but it _is_ nice that you can have your preferred hash table and use operator[] whichever you decide.

Python also has operator overloading, and people seem to like that numpy can exist using it. And container types. Weirdly doesn't cause much consternation compared to C++ (maybe because the criticisms of the latter come from C programmers?)

I've occasionally missed overloading in JS/TS though.


> It would have matrix types defined in the language spec with mathematical operators operating on them.

This is unfortunately impossible (IMO). The problem is matrixes have multiple operations that don't translate nicely like complex numbers do. If you want to be consistent, you have to pick and choose What A * B means, under which contexts, and when is that illegal (or what should happen on an error).

For complex numbers, there's only one definition of A * B that matters and no failure cases.

I fear there's not clean way to do matrix operations that won't make some community really irritated for choosing "wrong". (Physics, engineering, science, etc.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: