Consider optimizing .equals() operations

[CeylonMigrationBot]

[@emmanuelbernard] One use case for identity comparison in Java is to optimize .equals() implementations. If two instances are identical identity wise, they must be equal.

The compiler could enforce that automatically so that this use case for Ceylon's === is no longer needed.

Ceylon a == b would become in Java (a==b) || a.equals(b)

[Migrated from ceylon/ceylon-compiler#455]

[CeylonMigrationBot]

[@quintesse] Just to document a couple of remarks from the Skype discussion:

1. The spec would have to change to indicate this. Because it would become impossible to write an equals function that always returns false for example.
2. Passing equals() as a method reference or as a higher order function would suddenly use a slower code-path

[CeylonMigrationBot]

[@emmanuelbernard] Not sure why 2. would be the case. the optimization would be an implementation of equals(), no?

[CeylonMigrationBot]

[@quintesse] Well that's because this:

Ceylon `a == b` would become in Java `(a==b) || a.equals(b)`

suggests that it's the test that changes, not the implementation of equals, although I guess that could be done as well, Wrapping the code inside the equals in an if (a== b) { return true; } else { /* wrapped code here */ }

[CeylonMigrationBot]

[@FroMage] If we put that optimisation as inserted code at the beginning of each equals() method we don't have to use a let on every call-site and method references to equals will still be optimised.

[CeylonMigrationBot]

[@FroMage] Will wait for M4.

[CeylonMigrationBot]

[@FroMage] Optims for M5.

[CeylonMigrationBot]

[@FroMage] Moving to M6

[CeylonMigrationBot]

[@FroMage] Moving to 1.2