On Monday, May 07, 2012 23:41:33 Chris Cain wrote: > On Monday, 7 May 2012 at 21:34:29 UTC, Jonathan M Davis wrote: > > You mean the setter? > > > > Having a getter property function return by ref does allow you > > to use a > > property exactly as you would a variable, because you're > > operating on the ref > > that's returned. It also makes the property function > > nigh-on-useless, because > > then you're operating on its associated variable outside of the > > property > > function, making it so that you can no longer control access to > > it. You pretty > > much might as well make it a public variable at that point. Not > > to mention, > > even if returning by ref didn't have that problem, it would > > only work in cases > > where the property function was associated with an actual > > variable (since you > > have to return a ref to _something_), so it would still be > > impossible to > > emulate a variable with property functions which calculate the > > value from > > other variables or which grab the value from somewhere else > > (e.g. a database). > > > > - Jonathan M Davis > > And what about my idea of returning a struct by ref and using a > struct to represent all of the operations you're interested in? > As far as I can see, it should work, but admittedly, it's not as > slick as it could be.
It doesn't work unless you have a member variable which is the struct, which may or may not be acceptable (properties don't _have_ to have underlying member variables at all), and while it may work as a clever workaround, I'd definitely argue that it's something that should be fixed in the language. It seems pretty bad to me to have to create a struct which you return by ref just to get a property to fully act like a variable. - Jonathan M Davis
