@Norman Palardy I dont expect anything will occur about this since there are ways to achieve read only properties with other existing language constructs
I do expect, not soon, but because the current design is an outdated design that needs fixing/update. A property usually must have a Type (Int, String, etc) an optional init value ( 123, "asdf", set before the initializers and the constructor()), a scope (public, private, ...), a mutability declaration: read write/read only (also called mutable or not), and optionals initializer code (can be optionally lazy, it means, called after other non lazy inits, so you can use other non lazy values for calcs in lazy ones), getter code (overrides the system access to the stored value) and setter code (overrides the system attribution to the stored value, not present in immutables). An immutable property does not have a setter, a myProp=v gives you a compiler error.
We should not need a "back property" to store the current property values. Inside the class code, we could have some expression or operator to access the direct stored value, like myProp.Value, or some operator like Prop myProp = v; when you say just myProp, you call its setter/getter codes, but myProp.Value (or some operator to direct access myProp only accessible inside its Class) we bypass the getter/setter codes and go directly to its stored value. No need to have 2 properties, theProp (to handle code) and mTheProp (to store) anymore.