digitalmars.D.learn - property returning a reference vs returning a value
- cal (19/19) Jun 19 2012 This doesn't compile, because the assignment matches both
- Jonathan M Davis (13/33) Jun 19 2012 You can't overload on return type. The parameters need to be different, ...
- cal (6/8) Jun 20 2012 Ah, that explains it, thanks. I find ref properties useful for
- Jonathan M Davis (6/16) Jun 20 2012 You know when it's gotten, but you don't know when it's set (just that i...
This doesn't compile, because the assignment matches both property functions in S: struct S { property int a() { return _a; } property ref int a() { return _a; } int _a; } int main() { S s; s.a = 5; } But I would like to be able to do different things when I pass out a reference to _a compared to when I just pass out the value. I also don't want to require an argument to the ref property function. Is there a way to do this? Thanks, cal
Jun 19 2012
On Wednesday, June 20, 2012 05:42:25 cal wrote:This doesn't compile, because the assignment matches both property functions in S: struct S { property int a() { return _a; } property ref int a() { return _a; } int _a; } int main() { S s; s.a = 5; } But I would like to be able to do different things when I pass out a reference to _a compared to when I just pass out the value. I also don't want to require an argument to the ref property function. Is there a way to do this?You can't overload on return type. The parameters need to be different, or the functions are going to conflict. The fact that you're dealing with a property is irrelevant (other than the fact that that means that you can't actually have differing parameters save for the this parameter by making the function mutable, const, immutable, or shared). So no, you can't have two of the same property where one returns ref and one doesn't. But properties which return ref are generally pretty pointless anyway (unless it's const ref). As soon as you return non-const ref, the getter is also a setter, and you have no control over the setting, because it happens via the ref rather than a function. You might as well just use a public member variable. - Jonathan M Davis
Jun 19 2012
On Wednesday, 20 June 2012 at 06:34:06 UTC, Jonathan M Davis wrote:You can't overload on return type. The parameters need to be different, or the functions are going to conflict.Ah, that explains it, thanks. I find ref properties useful for making a member variable behave like it is public, but allowing the struct to be aware when it's being accessed, at least that's what I use it for.
Jun 20 2012
On Wednesday, June 20, 2012 09:03:44 cal wrote:On Wednesday, 20 June 2012 at 06:34:06 UTC, Jonathan M Davis wrote:You know when it's gotten, but you don't know when it's set (just that it was gotten when they set it). If that's useful to you, then fine, but be aware that you lose control of the setting that way. Personally, I'd just declare a setter rather than return ref from a getter. - Jonathan M DavisYou can't overload on return type. The parameters need to be different, or the functions are going to conflict.Ah, that explains it, thanks. I find ref properties useful for making a member variable behave like it is public, but allowing the struct to be aware when it's being accessed, at least that's what I use it for.
Jun 20 2012