Right, because Smalltalk doesn't conflate the use of public and internal members. Properties are second class citizens on .Net, since you can't pass them as ref or out arguments, but we can't use fields which are first class citizens because they have inadequate permissions control.
Then properties exist, but also don't really exist at the reflection level, where you have to search for getters and setters by mangled name if they're private. It's a total frickin mess.
> No because you cannot ensure their invariants, specially if more than one field needs to change at the same time
Properties don't help with changing more than one field either, so I'm not what your point is.
And you can ensure invariants with field permissions, which is what I suggested. Publicly read-only but privately writable is all you need, then the values change via method invocations. Most use of properties just add permissions to field access anyway.
Read/write with default const/init-only fields should have been the default. Then you can't pass read-only fields as ref or out arguments due to permissions, not because they're second class citizens.
There is nothing at IL level that prevents it, they can eventually lift the restriction if they feel like it.
> Properties don't help with changing more than one field either, so I'm not what your point is.
The setter can do a cascade set of changes while keeping the invariants.
While theoretically true, it will never happen. The whole point of ref/out parameters is efficient, direct pointer access to a member. This can never be made efficient for properties. The CLR GC is carefully tuned to handle internal pointers like this, so quite a bit of engineering has gone into making this efficient and safe, which means efficiency is important.
Furthermore, properties are entirely redundant with the simple change I suggested. They literally serve no purpose once you have permissions on fields, since methods cover the remaining use cases.
> The setter can do a cascade set of changes while keeping the invariants.
And so can methods. If you have mutating this much state, you should be invoking a method anyway. Properties are not the place for sophisticated behaviour.
Properties go all the way back to Smalltalk, which doesn't expose class internal data.
> Read/write fields should just be part of interface specifications. There is little value beyond that.
No because you cannot ensure their invariants, specially if more than one field needs to change at the same time.