On Thu, 25 Nov 2021 at 10:03, Andrew Haley <aph-open@littlepinkcloud.com> wrote:
Quick question, out of curiosity: how would it behave with respect to inheritance? Can a @Immutable class inherit from an non immutable one?
And: does @Immutable mean deeply immutable? IMO it really should, but that's harder to check, and we'd have to think about what this means for binary compatibility.
As cited in the original email,
and the programmer could, for example, annotate a new record object with @Immutable only if all its fields are annotated with @Immutable.
I would infer from this that it would mean deeply immutable. To clarify further, the following record `Wrapper` would be legal only because `A` has `@Immutable` on its _type_: @Immutable class A {} @Immutable record Wrapper(A a) {} while this would not be legal: class A {} @Immutable record Wrapper(A a) {} because `A` is not `@Immutable`. This could however borrow from the Rust concept of "auto-traits" (read: automatically apply certain traits or capabilities depending on how the type is defined), and infer `@Immutable` if it is deeply immutable, but that would raise the question of API & binary compatibility again. It would also not be legal with this: @Immutable class A { private int value; public void value(int value) { this.value = value; } } because `value` is _not_ immutable. Moving on from your question, this then poses the question of memoizing potentially very expensive optimisations, such as the following, currently found in the JDK: https://github.com/openjdk/jdk/blob/f0136ec94539d0e30ec11d44f8143196da1f7125... Code above from `java.base/java.lang.String`: public int hashCode() { // [snip large comment] int h = hash; // [hash is a property on the type] if (h == 0 && !hashIsZero) { // [hashIsZero is a property on the type] h = isLatin1() ? StringLatin1.hashCode(value) : StringUTF16.hashCode(value); if (h == 0) { hashIsZero = true; } else { hash = h; } } return h; } If the compiler / JRE were to infer the immutability from setters, it would again pose a new question of how to detect such. It could be possible that adding a new keyword or annotation to ignore mutable fields would be necessary (say `private mutable int hashCode;` as an example of my thoughts). At that point, however, what is the difference to not having this feature at all? This is definitely an idea I like as a user of the language, but it's something that would require a bit of work, assuming it can be boiled down to something feasible at all. -- *Mariell Hoversholm *(she/her) Software Developer @ <https://aboutpaf.com>