http://bugs.freepascal.org/view.php?id=26080
Reading this bug, I came to an interesting question. (Purely out of academic interest / not really interested in the final decision to the bug)
My understanding:
A property guarantees that the accessor can be changed between "direct field access" and "getter/setter method".
Code using a property should not be affected by such a change to property,.
To which extend is that statement correct?
Certainly, there is a gurantee that you can change a field property to a getter propert, and it will still compile (that is why "inc(Foo.PropBar)" does no longer compile)
Is there a guarantee, that if that getter return the same value, as the previous field access, that the behaviour of the code using the property will be kept exactly the same? (at all levels of code optimization / with the exception to cpu cycles used)?
And if there is, does it also exist (does the guarantee exist) in reverse. That is when changing a getter to field? It should, otherwise the behaviour in the former case would have been altered.
But if that is true, if a property gurantees to hide the difference between field and getter, Then the 2 properties in the bug should be the same too.
// Actual access to the field is indeed not guranteed to work
item := TRec.FItems[TRec.RegisterItem(Index)];FItems = dyn array
TRec.RegisterItem => SetLenght(FItems, ...)
But with the property?
In the bug the statement is about evaluation order. And there is no guarantee to that. But that is not what is asked for. It is about behaviour for the property being exactly as if it was a getter. (unless you can make the getter to fail too, then both will behave the same)