@property Incorrectly Implemented?

[Kagamin via Digitalmars-d]

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.