4 ms·

I wonder if it makes sense to add operator overloading to a language, but in a way that requires that closure under each overloaded operator and the existence o

I wonder if it makes sense to add operator overloading to a language, but in a way that requires that closure under each overloaded operator and the existence of identities/annihilators. The operating principle here is to ensure that principle of least surprise for library consumers (sometimes at the cost of making life harder for library authors).

jmull 6y ago
That's not a bad idea, but I think the problem is essentially solved. C++ introduced operator overloading to the wide world, and it was promptly abused (with the stream operators, among other things). But I believe the lesson was learned. Few libraries hoping to achieve general usage will abuse operator overloading too badly, and if they do, potential users will resist adopting it widely. There's an interesting class of language features, of which operator overloading is one, that are tempting to abuse which should really mostly only be used for what are essentially language extensions provided by a library. I think what is more useful than even more language features to restrict the usage of these, is strong documentation and evangelism/marketing around the feature to help ensure it will be used appropriately.
- pjmlp 6y ago
  CLU, ML, Lisp, Ada, Modula, Eiffel, Smalltalk were the ones that introduced it to the world.
- catlifeonmars 6y ago
  > Few libraries hoping to achieve general usage will abuse operator overloading too badly, and if they do, potential users will resist adopting it widely. Perhaps this is true for some language ecosystems and less true for others. But for the sake of argument, I’ll assume that this is generally true. Even in that case, if each library “abuse”s operator overloading in a new and interesting way, the problem still exists for the library ecosystem as a whole. > I think what is more useful than even more language features to restrict the usage of these, is strong documentation and evangelism/marketing around the feature to help ensure it will be used appropriately. I can’t imagine this scaling as well as building (or specifically choosing not to build) something into a language.

jmull 6y ago

That's not a bad idea, but I think the problem is essentially solved. C++ introduced operator overloading to the wide world, and it was promptly abused (with the stream operators, among other things). But I believe the lesson was learned. Few libraries hoping to achieve general usage will abuse operator overloading too badly, and if they do, potential users will resist adopting it widely. There's an interesting class of language features, of which operator overloading is one, that are tempting to abuse which should really mostly only be used for what are essentially language extensions provided by a library. I think what is more useful than even more language features to restrict the usage of these, is strong documentation and evangelism/marketing around the feature to help ensure it will be used appropriately.

pjmlp 6y ago
CLU, ML, Lisp, Ada, Modula, Eiffel, Smalltalk were the ones that introduced it to the world.
catlifeonmars 6y ago
> Few libraries hoping to achieve general usage will abuse operator overloading too badly, and if they do, potential users will resist adopting it widely. Perhaps this is true for some language ecosystems and less true for others. But for the sake of argument, I’ll assume that this is generally true. Even in that case, if each library “abuse”s operator overloading in a new and interesting way, the problem still exists for the library ecosystem as a whole. > I think what is more useful than even more language features to restrict the usage of these, is strong documentation and evangelism/marketing around the feature to help ensure it will be used appropriately. I can’t imagine this scaling as well as building (or specifically choosing not to build) something into a language.