On Wednesday, 7 September 2016 at 09:34:12 UTC, Jonathan M Davis
wrote:
But if you return the value by ref, then you pretty much
circumvent all of that, because then someone can do something
like take the address of the return value and procede to mutate
it whenever they want without hitting your breakpoint or log
messages or any of that. You can do a few things that can't be
done with a public member variable, but on the whole, returning
by ref defeats the purpose of having a property function.
No, manipulation of the value can be only done after accessing it
through the property, thus its mission is fulfilled.
So, while some @property functions may return by ref, most
won't, and it's arguably a bad idea in general.
It's good when it allows easy refactoring.
Stuff like assignment can be made to work, but something as
simple as passing by ref falls simply cannot be done except in
the case where the @property function returns by ref
True.
And for a large percentage of property functions, you don't
want it to be the case that taking the address of the property
function gives you a pointer to a member variable.
It depends.
Anything that would require an actual variable with an actual
memory location isn't going to work unless the @property
function returns by ref, and making taking the address of that
kind of @property function give you the address of the variable
would then not be consistent with any other @property function,
which would create a different set of problems.
Properties are meant to be inconsistent, i.e. to have different
implementations.
It's nice that we can have property syntax rather than having
to have functions that start with get and set, but it really
doesn't work to fully emulate variables.
What you said is more like your preference to not pass values by
ref. If you don't want it, don't do it, no problem.