Comment by ModernMech | Hacker News Reader

Comment by ModernMech | Hacker News Reader

The problem with operator overloading is that it introduces a degree of ambiguity into the language. You can say what you will about the dot notation for math, and I agree it’s unwieldy, but at least it’s consistent. And at any rate, the mess can be solved with a comment. If every library I use has its own definition of what + is in different contexts, now I have to consult the library for all the ways they use + and keep that straight in my head. This complexity is a nontrivial constant cost for developers.

The real reason people seem to like operator overloading is that it’s a feature that scratches a certain itch. We all love our code to look elegant and simple, and often times this need inspires developers to set down the path of language design. This is a long dark path that’s not for the feint of heart. Many who start down this road dabble for a bit and then turn back quickly when things get rough.

Operator overloading is a low barrier of entry to language design, so developers looking to make simple elegant code reach for it in the name of aesthetics. They get to feel like language designers by playing with syntax, while staying within the safety of a language they know and love. But in my opinion, the aesthetic gains are not worth the increase in complexity for the language. Both for writers and readers of code.

> The problem with operator overloading is that it introduces a degree of ambiguity into the language.

How is it any different in any way from any other overloading (i.e. generic functions or allowing two classes to have methods with the same name?)

It’s much easier to grep for function names

These days even emacs users can use LSP.

Nevertheless I agree with your point.

But shouldn’t overloading be used where its results are intuitive thus lookup should rarely be needed? /s

That's a question of interface design. You can also create ugly, ambiguous interfaces with functions (10 arguments, it mutates some of them, etc), or any other language feature. If a library designer uses operator overloading well, then it should be obvious what "a+b" is doing if you know the types involved.

On one hand it's a question of philosophy -- do you provide the user with tools to better express themselves, if they might possibly shoot themselves in the foot and create a crappy interface?

On the other hand, it could be an engineering issue. Maybe it's not worth the technical challenge or the increase in complexity for the language designers. I'd be more sympathetic to this reason. Then again, Python and C++ manage it.

Really consistent, how can you ensure that sum(a, b) actually does what it states without looking at the implementation?

It's not that complicated--other languages typically define precedence levels and grouping (left/right) for operators. Any symbols not in the predefined set can all have the same precedence level and group left-to-right.

I think you have a good point when it comes to the public API exposed to users of a module or library; it's one thing if you are just using operator overloading in your internal implementations, but I'd imagine it'd be pretty confusing not seeing docstrings or being able to search for specific methods. Not sure how you would easily find that in the docs without peering into the object whose methods are overloaded.

Reply on news.ycombinator.com