• 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...

"cal" <callumenator gmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"cal" <callumenator gmail.com> writes:

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.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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 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.

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 Davis