<div dir="ltr">Hello Project Amber team, <div><br></div><div>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). </div><div><br></div><div>If there's prior relevant material, I'd appreciate a pointer; Dr. Google hasn't uncovered anything of note.<div><br></div><div>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.<div>---</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>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."</div><div><br></div><div>Appreciate thoughts.</div><div><br></div><div>Thank you,</div><div>Subrahmanyam</div><div><br></div></div></div></div>