Thoughts on opt-in mutability?

[Subra V]

Hello Project Amber team,

What are the current thoughts on providing source level mechanisms for
opting-in to mutability rather than the current opt-out? For example, a
notion of immutable class (not a record) can obviate specifying "private
final" for fields. Opt-in mutability would perhaps also jive with two
recent themes in language evolution: 1. Functional style 2. More cognition,
less ceremony (switch statement, pattern matching to name a few).

If there's prior relevant material, I'd appreciate a pointer; Dr. Google
hasn't uncovered anything of note.

I realize that this question has red flags of "proposing a solution" to "my
specific problem". So, let me clarify that (1) I only write because I
believe there's a reasonable chance that opt-in mutability is of fairly
broad interest. (2) I am not proposing obviating the need for 'private
final' as a solution; instead, it is meant to be analogous to saying 'I
want String interpolation', a 'solution' from which language designers
carefully teased apart a general problem and solved it in the form of
String Templates.
---

I am certain language designers are aware of this (and plenty more), but in
the interest of intellectual honesty, let me attempt to articulate problems
with default-mutability from my default-immutable practice.

1. [Immutable style feels second class] Java has moved in a functional
direction much to my (and most practitioner's?) pleasure. For the subset of
folks who buy into this direction, Immutable classes are natural. Yet, they
feel second class in that (1) notions of "private final" aren't relevant
yet pollute (2) It requires extra work [making all fields final, binding
them in constructor] compared to the default case of mutability

2. [Cognitive Cost of Ceremony] For non-record Immutable classes, I have to
(1) Write 'private final X' and then add a constructor param and set
`this.X = X` in the constructor. (2) Read and verify `private final` on
every field to know that the class is immutable. Even though IDEs help, it
breaks the flow of thought both when reading and writing

3. [Poor Prototyping Velocity] I often find the ceremony especially
frustrating in early phases of design, especially when using immutable
classes. Imagine I have 20 concepts/fields and I am attempting to organize
them. A common occurrence is to realize 'ohh this field/method logically
belongs to that other class; let me move it there' but it is a pretty big
chore to do so (even with Intellij) given that immutability takes extra
work to achieve. Such moves also come with further transitive ripple
effects. All the busy work perhaps accounts for upwards of 30% of the
initial few hours/days of design and more importantly, constantly
interrupts thoughts. For contrast, if I just make every field public during
the initial period, it'd probably be a better experience, but then I need a
magic wand to make them all immutable after the design settles down.

A one line distillation of the above is perhaps: "Immutability is common
enough to consider a fast path at source level; the current slow path has
negative consequences for cognition and devx."

Appreciate thoughts.

Thank you,
Subrahmanyam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240118/4fd2df67/attachment.htm>