> I don't think these issues can nor should be figured out later on: they > are low-level conceptual issues IMHO.
I don't agree. Initialization would for example 100% work, I only removed it from the proposal at the end because we'll have more freedom to add new language behaviour until we find a much more useful use-case for default values of "write-once" properties than what we currently have. Speaking about cloning: I didn't want to propose a "workaround" in this proposal (as I wrote in the RFC) because tackling that problem in the same time would make the RFC much more complex. And since we can divide the whole problem into two smaller ones (because you can also create a new instance instead of cloning), I chose this approach. I proposed an alternative behavior that removes all the issues. I think it > needs to be discussed more in-depth: > https://externals.io/message/108675#108753 I'd like to reiterate my answer then: I think your idea and my proposal doesn't try to solve the same problem. My goal is to make sure that a property can't be messed with. No matter the scope, no matter if it's some exotic use-case (like calling the constructor twice) or a mistake of the author herself/himself. Your idea would however add a property-accessor-like feature: public readonly $foo => read access from the public scope, write access from everywhere else protected readonly $foo => read access from the public and protected scopes, write access from the private scope It seems to me that it's basically a convention-over-configuration based property-accessor variant where one can't give for example read access to the public scope and write access to only the private scope. And I'm saying that you try to solve a different problem because we have already discussed that property accessors and "write-once" properties are not closely related to each other: While "write-once properties" would solve a problem that is currently not possible to do (immutability of properties), I consider property accessors to be only a syntactic sugar to separate read and write access to a property without using getters and setters - at least it's true for the version you proposed. Of course, not everyone considers property immutability a problem to be worth to bother about (which I can not relate, but can totally understand), it's also totally ok not to like the special rules I added or the implementation itself, but please don't promote your idea as a better version of "write-once" properties that removes all its issues - simply because it's not an answer to the same problem and in turn has other issues. Máté
