Deal with equality and identity about dora HOT 2 CLOSED

With #29 and #31 done, I think it makes sense to think whether it's possible to increase the consistency of === and ==:

The problem I see is that === can be used everywhere, including in generic contexts, while == requires Equals.

I am concerned that this (slight) convenience could make users use === in cases where == would be correct.

A rather brute approach would be:

• Give === its own trait (e. g. Identity) that is implemented for every type and cannot be defined by a user.
• In addition to Equals being defined for non-reference types, automatically derive == (Equals) for all reference types according to the following rules:
  • Equality would be based on calling == on all fields of a class, similar to Scala's case classes, Kotlin's data classes, C#'s record types and Java's proposed record classes.
  • To avoid the problems immediately cropping up with sub-classing, sub-classing would be discarded altogether, leaving only traits for polymorphism.
  • If a class implements Equals explicitly, this definition will be used and no equality operation would be derived.
  • Introduce annotations to let users
    • opt out of equality, e. g. @noEquals class Foo(let x: int) {}, or
    • adjust how equality is derived, e. g. class Foo(let x: int, @ignoreForEquals let y: int) {} would only use x to derive equality
  • If a class A contains a field of type B which does not support equality (the user has annotated the class B with @noEquals) then an error is reported, which can be fixed by:
    • adding @noEquals to A
    • ignoring the field with @ignoreForEquals
• In the future if something like lambdas or function types were added, they would either:
  • not implement Equals, or
  • implement Equals in terms of Identity

What do you think, @dinfuehr?

from dora.

I think this can be closed as fixed; I'll file issues/questions that arise from e. g. value types, code generation desires, or meta programming topics when we cross that particular bridge.

from dora.