News for hackers. Stuff that matters.
Re:Lies we tell ourselves to keep using Golang by delta64 on Friday April 29, 2022 @10:44AM (#31205833)
The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people

In languages with operator overloading this just isn't a concern at all because == does the obvious thing

Re:Lies we tell ourselves to keep using Golang by SeanLuke on Friday April 29, 2022 @01:31PM (#31208235)
> In languages with operator overloading this just isn't a concern at all because == does the obvious thing

And what is the obvious thing? It varies wildly among languages, even within C++ itself.

Re:Lies we tell ourselves to keep using Golang by delta64 on Saturday April 30, 2022 @09:11AM (#31215810)
The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...
Re:Lies we tell ourselves to keep using Golang by AnimalMuppet on Friday April 29, 2022 @01:00PM (#31207708)
== should do the obvious thing. But with operator overloading, it's not clear that it does, unless you need to read the implementation of == very carefully.
Re:Lies we tell ourselves to keep using Golang by delta64 on Saturday April 30, 2022 @09:13AM (#31215837)
How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood
Re:Lies we tell ourselves to keep using Golang by AnimalMuppet on Saturday April 30, 2022 @12:51PM (#31217333)
True. But people think about it a bit differently. People don't always expect == to be a function call.
Re:Lies we tell ourselves to keep using Golang by delta64 on Saturday April 30, 2022 @04:03PM (#31218802)
Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'