This proposal looks really good to me. It cuts out a lot of syntax and
boilerplate for a commonly used case. However, there is one issue that
I know somebody is going to raise:
Argument: If you change the value of the property without using the
setter then get could return something that has a type mismatch with
the type-hint.
If I understand the current RFC for properties correctly, the only
place that a property can be directly written to without the accessor
is inside of the __setProperty method. This almost nullifies the
argument completely.
The only other place for possible error would be assigning a value in
the constructor that does not match the type-hint. However, because
we adding a new syntax we *could* disallow assigning a value if it
really was that problematic. I do not personally feel that would be
necessary.
I feel that this argument is not weighty enough to stop the proposal
for this improved syntax.