Is there a possibility of the string equality operator (==) being fixed?
Brian Goetz
brian.goetz at oracle.com
Tue Oct 31 14:05:36 UTC 2023
>
> Can I propose a Solution C?
>
> Solution C: Introduce the === and !== operators for value comparison
> (equivalent to Object::equals()).
As will not be surprising, this is not a new suggestion either.
JavaScript had good success with ===, but they started out in a very
different position; == was so catastrophically difficult to reason about
that it was reasonable to tell users to basically forget about ==.
Moving to === was virtually a forced move for them. We don't have that
problem; == has a firm, and learnable foundation in Java. But, it gets
worse.
Inventing === as a synonym for == is purely a syntactic hack; there are
no useful new semantics here. And because both == and === will be valid
on all types, people will still make mistakes that are going to be hard
to catch -- arguably harder, because they look so much alike.
But here's the killer for this idea; .equals() is asymmetric; calling
a.equals(b) can invoke different code than b.equals(a), if they have
different implementation classes and both refine equals(). Which means
`===` is not commutative, and which you put on the left matters. But
this is not how we expect equality comparison operators to work.
More information about the amber-dev
mailing list