www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using ()s in property functions

reply dsimcha <dsimcha yahoo.com> writes:
Once enforcement of  property is enabled, we need to decide whether calling an
 property function using ()s should be legal.  In other words, should
 property **require** omission of ()s or just allow it?  My vote is for just
allowing omission, because I've run into the following ambiguity while
debugging std.range.  Here's a reduced test case:

struct Foo {
    uint num;

     property ref uint front() {
        return num;
    }
}

void main() {
    Foo foo;
    uint* bar = &foo.front;  // Tries to return a delegate.
}

If I can assume that  property functions can be called with explicit ()s to
forcibly disambiguate this situation, then I can fix these kinds of bugs by
simply doing a:

uint* bar = &(foo.front());

Can we finalize the idea that this will continue to be allowed now so that I
can fix the relevant bugs in Phobos and know that my fix won't be broken in a
few compiler releases?
Jun 28 2010
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 6/28/2010 20:40, dsimcha wrote:
 Once enforcement of  property is enabled, we need to decide whether calling an
  property function using ()s should be legal.
No, "we" don't. Walter does.
  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:
 
 struct Foo {
     uint num;
 
      property ref uint front() {
         return num;
     }
 }
 
 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }
Allowing parentheses also leads to ambiguity: struct Foo { uint num; property int delegate() front() { return delegate (){ return 5; }; } } void main() { Foo foo; auto bar = foo.front(); // What is the type of 'bar'? } The problem is that 'front' refers to two things: the property and its accessor function. So long as this is the case, ambiguity is unavoidable. -- Rainer Deyke - rainerd eldwood.com
Jun 28 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 00:02:32 -0400, Rainer Deyke <rainerd eldwood.com>  
wrote:

 On 6/28/2010 20:40, dsimcha wrote:
 Once enforcement of  property is enabled, we need to decide whether  
 calling an
  property function using ()s should be legal.
No, "we" don't. Walter does.
No, Walter doesn't. Walter and others wanted zero and one argument functions to be allowed to behave like properties which is entirely different from properties behaving like functions.
Jun 28 2010
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 00:02:32 -0400, Rainer Deyke <rainerd eldwood.com>  
wrote:
 On 6/28/2010 20:40, dsimcha wrote:
  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for  
 just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
     uint num;

      property ref uint front() {
         return num;
     }
 }

 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }
Allowing parentheses also leads to ambiguity: struct Foo { uint num; property int delegate() front() { return delegate (){ return 5; }; } } void main() { Foo foo; auto bar = foo.front(); // What is the type of 'bar'? } The problem is that 'front' refers to two things: the property and its accessor function. So long as this is the case, ambiguity is unavoidable.
So... If we allow properties to be called using () syntax, we have corner case ambiguities. And if we don't allow properties to be called using () syntax, we have corner case ambiguities and a minor loss of function (because one ambiguity can't be expressed). Add in Andrei's posts about the difficulty in deciding what methods should and shouldn't be properties, and the more it seems that the real world experience with properties is indicating that property is a mis-feature that should be dropped from the language.
Jun 28 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Jacques" <sandford jhu.edu> wrote in message 
news:op.ve1p6xrt26stm6 sandford.myhome.westell.com...
 On Tue, 29 Jun 2010 00:02:32 -0400, Rainer Deyke <rainerd eldwood.com> 
 wrote:
 On 6/28/2010 20:40, dsimcha wrote:
  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for 
 just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
     uint num;

      property ref uint front() {
         return num;
     }
 }

 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }
Allowing parentheses also leads to ambiguity: struct Foo { uint num; property int delegate() front() { return delegate (){ return 5; }; } } void main() { Foo foo; auto bar = foo.front(); // What is the type of 'bar'? } The problem is that 'front' refers to two things: the property and its accessor function. So long as this is the case, ambiguity is unavoidable.
So... If we allow properties to be called using () syntax, we have corner case ambiguities. And if we don't allow properties to be called using () syntax, we have corner case ambiguities and a minor loss of function (because one ambiguity can't be expressed). Add in Andrei's posts about the difficulty in deciding what methods should and shouldn't be properties, and the more it seems that the real world experience with properties is indicating that property is a mis-feature that should be dropped from the language.
Hell no. It's far better than what we had before, and far better than just simply not having properties. I wouldn't mind improvements, but as for ditching it: there's a baby in that bathwater.
Jun 28 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 01:38:45 -0400, Nick Sabalausky <a a.a> wrote:
 "Robert Jacques" <sandford jhu.edu> wrote in message
[snip]
 So... If we allow properties to be called using () syntax, we have  
 corner
 case ambiguities. And if we don't allow properties to be called using ()
 syntax, we have corner case ambiguities and a minor loss of function
 (because one ambiguity can't be expressed). Add in Andrei's posts about
 the difficulty in deciding what methods should and shouldn't be
 properties, and the more it seems that the real world experience with
 properties is indicating that  property is a mis-feature that should be
 dropped from the language.
Hell no. It's far better than what we had before, and far better than just simply not having properties. I wouldn't mind improvements, but as for ditching it: there's a baby in that bathwater.
What baby? property was introduced solely to clarify the ambiguity of the corner case of returning a zero-argument delegate from a method. That's it. Methods-as-properties existed long before the property was proposed. (I'm not suggesting in any way that methods-as-properties should be thrown out, because that really would be throwing the baby out with the bath water.) P.S. The other reason for introducing the property was to allow a library writer to force certain coding standards on the library users. Some like this, some hate this. My count had a con from every pro, but not a pro for every con. However, the pro-less cons were mostly mitigated by leaving in methods-as-properties, making the final verdict one of those agree to disagree compromises.
Jun 28 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:i0bme6$2phb$1 digitalmars.com...
 Once enforcement of  property is enabled, we need to decide whether 
 calling an
  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for 
 just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
    uint num;

     property ref uint front() {
        return num;
    }
 }

 void main() {
    Foo foo;
    uint* bar = &foo.front;  // Tries to return a delegate.
 }

 If I can assume that  property functions can be called with explicit ()s 
 to
 forcibly disambiguate this situation, then I can fix these kinds of bugs 
 by
 simply doing a:

 uint* bar = &(foo.front());

 Can we finalize the idea that this will continue to be allowed now so that 
 I
 can fix the relevant bugs in Phobos and know that my fix won't be broken 
 in a
 few compiler releases?
Crazy idea: The whole point of properties is to simulate a member that's *not* a function. With that in mind, does it even make sense to allow the use of unary "&" to get a delegate to a property at all? On the off-chance that you really do need a delegate to a setter/getter you can just make a lambda - and that works exactly the same even if it's a real member variable instead of a property. And inlining could take care of any performance issues. Somewhat related question: What normally happens when you try to get a delegate to an overloaded function?
Jun 28 2010
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 01:53:05 -0400, Nick Sabalausky <a a.a> wrote:

 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:i0bme6$2phb$1 digitalmars.com...
 Once enforcement of  property is enabled, we need to decide whether
 calling an
  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for
 just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
    uint num;

     property ref uint front() {
        return num;
    }
 }

 void main() {
    Foo foo;
    uint* bar = &foo.front;  // Tries to return a delegate.
 }

 If I can assume that  property functions can be called with explicit ()s
 to
 forcibly disambiguate this situation, then I can fix these kinds of bugs
 by
 simply doing a:

 uint* bar = &(foo.front());

 Can we finalize the idea that this will continue to be allowed now so  
 that
 I
 can fix the relevant bugs in Phobos and know that my fix won't be broken
 in a
 few compiler releases?
Crazy idea: The whole point of properties is to simulate a member that's *not* a function. With that in mind, does it even make sense to allow the use of unary "&" to get a delegate to a property at all? On the off-chance that you really do need a delegate to a setter/getter you can just make a lambda - and that works exactly the same even if it's a real member variable instead of a property. And inlining could take care of any performance issues.
1. You'd get a closure, not a lambda, which generally would require a heap allocation. 2. The idea's not too crazy, I've been having similar thoughts. However, 3. D's a system's programming language and not being able to get a function pointer to a function seems wrong. 4. There's actually valid use cases where getting the address of a property makes sense. One of the intents of properties is to allow a library to upgrade a variable to a set of methods without breaking third party user code. And in the new version of your library, taking the address might make sense or be needed due to new functionality.
 Somewhat related question: What normally happens when you try to get a
 delegate to an overloaded function?
It grabs the first overload, IIRC.
Jun 28 2010
parent "Nick Sabalausky" <a a.a> writes:
"Robert Jacques" <sandford jhu.edu> wrote in message 
news:op.ve1us1xj26stm6 sandford.myhome.westell.com...
 On Tue, 29 Jun 2010 01:53:05 -0400, Nick Sabalausky <a a.a> wrote:

 Crazy idea:

 The whole point of properties is to simulate a member that's *not* a
 function. With that in mind, does it even make sense to allow the use of
 unary "&" to get a delegate to a property at all? On the off-chance that 
 you
 really do need a delegate to a setter/getter you can just make a lambda -
 and that works exactly the same even if it's a real member variable 
 instead
 of a property. And inlining could take care of any performance issues.
1. You'd get a closure, not a lambda, which generally would require a heap allocation. 2. The idea's not too crazy, I've been having similar thoughts. However, 3. D's a system's programming language and not being able to get a function pointer to a function seems wrong. 4. There's actually valid use cases where getting the address of a property makes sense. One of the intents of properties is to allow a library to upgrade a variable to a set of methods without breaking third party user code. And in the new version of your library, taking the address might make sense or be needed due to new functionality.
 Somewhat related question: What normally happens when you try to get a
 delegate to an overloaded function?
It grabs the first overload, IIRC.
Then maybe what we need is a way to specify what overload of a function you want to get a reference to. Something along these lines (disregard the exact syntax, I'm looking more at the semantics): main() { auto a = &foo; // Either same behavior as now, or disallowed for overloaded funcs, or a collection of delegates } Then, that would open the door for this: class Foo { property ref uint foo() {/*...*/} } main() { auto f = new Foo(); auto a = &f.foo; // Address of returned value auto b = &f.foo(void); // Delegate to getter //auto c = &f.foo(uint); // If exists, delegate to setter }
Jun 29 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 01:53:05 -0400, Nick Sabalausky <a a.a> wrote:

 "dsimcha" <dsimcha yahoo.com> wrote in message
 news:i0bme6$2phb$1 digitalmars.com...
 Once enforcement of  property is enabled, we need to decide whether
 calling an
  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for
 just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
    uint num;

     property ref uint front() {
        return num;
    }
 }

 void main() {
    Foo foo;
    uint* bar = &foo.front;  // Tries to return a delegate.
 }

 If I can assume that  property functions can be called with explicit ()s
 to
 forcibly disambiguate this situation, then I can fix these kinds of bugs
 by
 simply doing a:

 uint* bar = &(foo.front());

 Can we finalize the idea that this will continue to be allowed now so  
 that
 I
 can fix the relevant bugs in Phobos and know that my fix won't be broken
 in a
 few compiler releases?
Crazy idea: The whole point of properties is to simulate a member that's *not* a function. With that in mind, does it even make sense to allow the use of unary "&" to get a delegate to a property at all? On the off-chance that you really do need a delegate to a setter/getter you can just make a lambda - and that works exactly the same even if it's a real member variable instead of a property. And inlining could take care of any performance issues.
I don't think a delegate to a property is a common need. Besides, you would almost expect something that accesses both read/write properties. I'm sure someone can come up with a way to do this in a type-agnostic way (a "property delegate" if you will...) If one truly needs a delegate to a property, why not use __traits/meta to do it? meta.delegateOf(foo.front); This could actually solve the issue of how to get a specific delegate: struct S { void foo(int x); void foo(string s); } S s; auto d1 = meta.delegateOf(s.foo, int); auto d2 = meta.delegateOf(s.foo, string); -Steve
Jun 29 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Jun 2010 22:40:06 -0400, dsimcha <dsimcha yahoo.com> wrote:

 Once enforcement of  property is enabled, we need to decide whether  
 calling an
  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?
Require it. Otherwise, we are left with the same situation as before. We already had optional parentheses for properties, and it was/is an ambiguity disaster. It's the whole reason for introducing property in the first place.
  My vote is for just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:

 struct Foo {
     uint num;

      property ref uint front() {
         return num;
     }
 }

 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }

 If I can assume that  property functions can be called with explicit ()s  
 to
 forcibly disambiguate this situation, then I can fix these kinds of bugs  
 by
 simply doing a:

 uint* bar = &(foo.front());

 Can we finalize the idea that this will continue to be allowed now so  
 that I
 can fix the relevant bugs in Phobos and know that my fix won't be broken  
 in a
 few compiler releases?
If I'm reading this correctly, you are saying that you want &foo.front to return a pointer to uint, not a delegate? This is what I'd expect if property forced no parentheses. That is, foo.front can be replaced with (foo.front()) always, so &foo.front always translates to &(foo.front()). What this means is that you can't get a delegate to the property function. This makes sense -- if you replaced the property with an actual field, you wouldn't be able to get a delegate anyways. A property should operate just like a field. -Steve
Jun 29 2010
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 06/29/2010 07:16 AM, Steven Schveighoffer wrote:
 If I'm reading this correctly, you are saying that you want &foo.front
 to return a pointer to uint, not a delegate?
 
 This is what I'd expect if  property forced no parentheses.  That is,
 foo.front can be replaced with (foo.front()) always, so &foo.front
 always translates to &(foo.front()).
 
 What this means is that you can't get a delegate to the property
 function.  This makes sense -- if you replaced the property with an
 actual field, you wouldn't be able to get a delegate anyways.  A
 property should operate just like a field.
 
 -Steve
That's the spirit of it. Properties are fields, except much more powerful but addressing is tricky. There is one thing that bugs me about this solution though. What if the user does this: (1) Grab the pointer. *ptr = prop; (2) assigns to it. *ptr = val; (3) expects the result to be updated in prop. assert(val == prop);
Jun 29 2010
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Whoops, made a mistake.

On 06/29/2010 08:03 AM, Chad J wrote:
 On 06/29/2010 07:16 AM, Steven Schveighoffer wrote:
 If I'm reading this correctly, you are saying that you want &foo.front
 to return a pointer to uint, not a delegate?

 This is what I'd expect if  property forced no parentheses.  That is,
 foo.front can be replaced with (foo.front()) always, so &foo.front
 always translates to &(foo.front()).

 What this means is that you can't get a delegate to the property
 function.  This makes sense -- if you replaced the property with an
 actual field, you wouldn't be able to get a delegate anyways.  A
 property should operate just like a field.

 -Steve
That's the spirit of it. Properties are fields, except much more powerful but addressing is tricky. There is one thing that bugs me about this solution though. What if the user does this: (1) Grab the pointer. *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
 (2) assigns to it.  *ptr = val;
 (3) expects the result to be updated in prop.  assert(val == prop);
Jun 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 08:05:04 -0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Whoops, made a mistake.

 On 06/29/2010 08:03 AM, Chad J wrote:
 On 06/29/2010 07:16 AM, Steven Schveighoffer wrote:
 If I'm reading this correctly, you are saying that you want &foo.front
 to return a pointer to uint, not a delegate?

 This is what I'd expect if  property forced no parentheses.  That is,
 foo.front can be replaced with (foo.front()) always, so &foo.front
 always translates to &(foo.front()).

 What this means is that you can't get a delegate to the property
 function.  This makes sense -- if you replaced the property with an
 actual field, you wouldn't be able to get a delegate anyways.  A
 property should operate just like a field.

 -Steve
That's the spirit of it. Properties are fields, except much more powerful but addressing is tricky. There is one thing that bugs me about this solution though. What if the user does this: (1) Grab the pointer. *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
 (2) assigns to it.  *ptr = val;
 (3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref, then you set through that ref. What you did is no different, you just delayed the assignment for a bit. You can reduce your test case to: (1) assign to the property. prop = val; (2) expects the result to be updated in prop. assert(val == prop); -Steve
Jun 29 2010
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
 then you
 set through that ref.  What you did is no different, you just
 delayed the assignment for a bit.
 
 You can reduce your test case to:
 
 (1) assign to the property.   prop = val;
Is not the same at all! prop = val will call the setter function, *ptr = val will not! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ¿Qué será lo que hace que una brújula siempre marque el norte? - Ser aguja, nada más, y cumplir su misión. -- Ricardo Vaporeso
Jun 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella <luca llucax.com.ar>  
wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What if  
the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
 then you
 set through that ref.  What you did is no different, you just
 delayed the assignment for a bit.

 You can reduce your test case to:

 (1) assign to the property.   prop = val;
Is not the same at all! prop = val will call the setter function, *ptr = val will not!
Maybe you are thinking of something different, here is the code we're discussing: struct Foo { uint num; property ref uint front() { return num; } } -Steve
Jun 29 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella 
 <luca llucax.com.ar> wrote:
 
 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What 
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Jun 29 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella  
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What  
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control.
Yes, my point was simply, for anything that returns ref: auto ptr = &foo(); *ptr = x; is equivalent to foo() = x;
 I agree with the view that a  property returning ref should be virtually  
 indistinguishable from a field. Currently that's not the case, e.g. if  
 you want to assign to such a property you must add parens:

 struct A { int x;  property ref y() { return x; } }

 unittest
 {
      A a;
      a.y = 5; // fails
      a.y() = 5; // works
 }
http://d.puremagic.com/issues/show_bug.cgi?id=3511 -Steve
Jun 29 2010
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
On 29/06/2010 17:44, Andrei Alexandrescu wrote:
 struct A { int x;  property ref y() { return x; } }
should be : struct A { int x; property ref int y() { return x; } } or am I wrong ? bjoern
Jun 29 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 12:03:38 -0400, BLS <windevguy hotmail.de> wrote:

 On 29/06/2010 17:44, Andrei Alexandrescu wrote:
 struct A { int x;  property ref y() { return x; } }
should be : struct A { int x; property ref int y() { return x; } } or am I wrong ? bjoern
You're forgetting type inference.
Jun 29 2010
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella  
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What  
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
Jun 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella 
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What 
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
Jun 29 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday 29 June 2010 20:41:48 Andrei Alexandrescu wrote:
 
 I don't think you should be able to even take the address of a non-ref
 property.
 
 Andrei
In order to have a properly reference a non-ref property, you would have to have an abstraction which wrapped the object along with its getter and/or setter and treated it exactly like a reference to a public member variable (including dealing with the fact that it could be read-only or write-only). On top of that, that same abstraction would have to be used for references to actual member variables. That way, they could be treated identically be user code, and that code would not have to care whether it was dealing with property functions or a naked member variable. And while I'm sure that such an abstraction is technically feasible, it would likely be an expensive one (particularly for a systems language), and by the time you're talking addresses of things, you're way too low-level to even consider it. Properties are definitely a useful abstraction, but they are by their nature a bit broken - particularly when you get to the low-level stuff - because while they may act like member variables, they _aren't_ member variables. A ref property is giving you essentially what a naked member variable would give you, so it makes some sense to allow you to take its address. However, if it's a non-ref property, I don't think that it really makes sense anymore. What would you take the address of? You'd need one (possibly two) functions and the object that has the property. With a ref, you have the variable itself. It's nowhere near that simple with a non-ref property functions - there may not even _be_ a variable to reference. So, I'd have to agree that it doesn't make sense to take the address of a non-ref property. properties where you can't really treat them quite the same as public member variables, so it's not like it's without precedent. If we really wanted to fix it, we'd need a higher-level reference abstraction than we currently have, it there's a good chance that the abstraction would cost far too much to make sense - particularly for a systems lanuage. - Jonathan M Davis
Jun 29 2010
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
.
 Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella  
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What  
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val ==  
prop);

 Why would this assert fail?  If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
I agree with you from a under-the-hood perspective, but I wasn't asking about that. I was asking about the leak in the property abstraction. Not being able to pass non-ref properties to functions by ref is a fairly serious (i.e. common) break/leak in the property abstraction: that properties should be "virtually indistinguishable from a field".
Jun 29 2010
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 06/30/2010 12:33 AM, Robert Jacques wrote:
 On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 .
 Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though. 
What if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val ==
prop);

 Why would this assert fail?  If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
I agree with you from a under-the-hood perspective, but I wasn't asking about that. I was asking about the leak in the property abstraction. Not being able to pass non-ref properties to functions by ref is a fairly serious (i.e. common) break/leak in the property abstraction: that properties should be "virtually indistinguishable from a field".
ref parameters are easily handled by property expression rewriting: void foo( ref bar ) { ... } foo(prop) becomes auto t = prop() foo(t) prop(t) I would handle "out" parameters similarly, but without calling the getter. They are essentially a different way of writing an assignment. Taking the /address/ is a bit different, since there may be no well-defined line of code at which the pointer holding the address dies. The ref parameter, on the other hand, WILL expire when the function returns.
Jun 29 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 30 Jun 2010 01:00:53 -0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 On 06/30/2010 12:33 AM, Robert Jacques wrote:
 On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 .
 Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.
What if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val ==
prop);

 Why would this assert fail?  If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
I agree with you from a under-the-hood perspective, but I wasn't asking about that. I was asking about the leak in the property abstraction. Not being able to pass non-ref properties to functions by ref is a fairly serious (i.e. common) break/leak in the property abstraction: that properties should be "virtually indistinguishable from a field".
ref parameters are easily handled by property expression rewriting: void foo( ref bar ) { ... } foo(prop) becomes auto t = prop() foo(t) prop(t) I would handle "out" parameters similarly, but without calling the getter. They are essentially a different way of writing an assignment. Taking the /address/ is a bit different, since there may be no well-defined line of code at which the pointer holding the address dies. The ref parameter, on the other hand, WILL expire when the function returns.
Nope. That's a data race. Consider the case where foo has access to prop's object. Essentially, t is stale, so this breaks the concept of reference semantics.
Jun 29 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 On 06/30/2010 12:33 AM, Robert Jacques wrote:
 On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 .
 Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
 There is one thing that bugs me about this solution though. 
What if the
 user does this:
 (1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
 (2) assigns to it.  *ptr = val;
 (3) expects the result to be updated in prop.  assert(val ==
prop); Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
I agree with you from a under-the-hood perspective, but I wasn't asking about that. I was asking about the leak in the property abstraction. Not being able to pass non-ref properties to functions by ref is a fairly serious (i.e. common) break/leak in the property abstraction: that properties should be "virtually indistinguishable from a field".
ref parameters are easily handled by property expression rewriting: void foo( ref bar ) { ... } foo(prop) becomes auto t = prop() foo(t) prop(t)
I think that would be very error-prone. Andrei
Jun 29 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 ..
 Robert Jacques wrote:
 On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella 
 <luca llucax.com.ar> wrote:

 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  
What if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == 
prop);

 Why would this assert fail?  If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
It's a "calculated reference", e.g. several instances could share the same value etc. Once the reference is out, clearly there's no more control. I agree with the view that a property returning ref should be virtually indistinguishable from a field. Currently that's not the case, e.g. if you want to assign to such a property you must add parens: struct A { int x; property ref y() { return x; } } unittest { A a; a.y = 5; // fails a.y() = 5; // works } Andrei
Okay, but what about non-ref properties? i.e. struct A { int x; property int y() { return x; } property int y(int v) { return x = v; } } unittest { A a; int* ptr = &a.x; // works int* ptr = &a.y; // fails } Is there a good way of patching this leak in the property abstraction?
I don't think you should be able to even take the address of a non-ref property. Andrei
I agree with you from a under-the-hood perspective, but I wasn't asking about that. I was asking about the leak in the property abstraction. Not being able to pass non-ref properties to functions by ref is a fairly serious (i.e. common) break/leak in the property abstraction: that properties should be "virtually indistinguishable from a field".
Indeed properties with separate get and set that don't expose references are quite different from fields. Those that return ref are more similar to fields. The basic goal is to bring both as close as possible to field syntax and semantics. Andrei
Jun 29 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 30 Jun 2010 00:33:54 -0400, Robert Jacques <sandford jhu.edu>  
wrote:

 I agree with you from a under-the-hood perspective, but I wasn't asking  
 about that. I was asking about the leak in the  property abstraction.  
 Not being able to pass non-ref  properties to functions by ref is a  
 fairly serious (i.e. common) break/leak in the  property abstraction:  
 that  properties should be "virtually indistinguishable from a field".
properties are not fields, they are restricted fields. That is, you can completely control access to a property, but you cannot control access to a field. With a field, you cannot control: - Who has an address to it - What the user sets it to - The action of setting or getting it. Properties allow control over those things. The drawback is you cannot use it exactly like a field. I think we would all agree that the main mode of access to a field is: container.field = x; x = container.field; Properties mimic that functionality perfectly, and that is pretty much it. The one thing I'd like to see for properties is some sort of "property delegate." This could be generated in a struct. What I don't know is how to make it as "virtual" as a real delegate. Another thing I'd like to see (brought up elsewhere in this thread) is some sort of __traits/meta means to get a delegate to a property setter or getter, since with required omission of parens, you can no longer get a delegate to the property. This solution could also be amended to solve another pet peeve of mine: struct S { property void foo(int x); property void foo(string s); } S s; auto d1 = meta.delegateOf(s.foo, int); auto d2 = meta.delegateOf(s.foo, string); -Steve
Jul 01 2010
prev sibling parent reply sclytrack <sclytrack fake.com> writes:


void doStuff( ref int a) {a++;}
doStuff(obj.NumberProperty);

//Compiler magic. Stores in local variables behind the scenes. Calls getter and
setter.
Jul 07 2010
parent sclytrack <sclytrack sorry.com> writes:
== Quote from sclytrack (sclytrack fake.com)'s article

 void doStuff( ref int a) {a++;}
 doStuff(obj.NumberProperty);
 //Compiler magic. Stores in local variables behind the scenes. Calls getter and
 setter.
Sorry about that, it does not appear to work, I should test the code before I post.
Jul 07 2010
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 06/29/2010 11:38 AM, Steven Schveighoffer wrote:
 On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella
 <luca llucax.com.ar> wrote:
 
 Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
There is one thing that bugs me about this solution though.  What
if the
user does this:
(1) Grab the pointer.  *ptr = prop;
(1) Grab the pointer. T* ptr = &prop;
(2) assigns to it.  *ptr = val;
(3) expects the result to be updated in prop.  assert(val == prop);
Why would this assert fail? If a property returns a ref
What if it doesn't? If returns a temporary calculated value?
It returns a ref. That can't be a calculated value. If it's a calculated value then T* ptr = &prop will fail to compile.
 then you
 set through that ref.  What you did is no different, you just
 delayed the assignment for a bit.

 You can reduce your test case to:

 (1) assign to the property.   prop = val;
Is not the same at all! prop = val will call the setter function, *ptr = val will not!
Maybe you are thinking of something different, here is the code we're discussing: struct Foo { uint num; property ref uint front() { return num; } } -Steve
Ah, so we're speaking only of ref-returning properties. It took me this post and some of its replies until I realized this restriction. Sorry, I was speaking about properties in general. Actually this is really cool. I hadn't thought of ref-returns as a way to escape the lack-of-addressability problem. I'm too sleepy to think of the consequences of this, but so far I like it!
Jun 29 2010
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 06/28/2010 10:40 PM, dsimcha wrote:
 Once enforcement of  property is enabled, we need to decide whether calling an
  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for just
 allowing omission, because I've run into the following ambiguity while
 debugging std.range.  Here's a reduced test case:
 
 struct Foo {
     uint num;
 
      property ref uint front() {
         return num;
     }
 }
 
 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }
 
 If I can assume that  property functions can be called with explicit ()s to
 forcibly disambiguate this situation, then I can fix these kinds of bugs by
 simply doing a:
 
 uint* bar = &(foo.front());
 
 Can we finalize the idea that this will continue to be allowed now so that I
 can fix the relevant bugs in Phobos and know that my fix won't be broken in a
 few compiler releases?
I don't think it should be possible to take the address of a property. I also think applying property to normal fields would have special behavior. The effect would be a field that can't be addressed. Ideally this would be the default, to make it more intuitive to build flexible APIs, but I think we are too late for that bit of niceness. Just having that ability to build flexible APIs at all (in this case) by using property fields would be a good start. I wouldn't mind having some way to grab the delegate, but I think it should be very explicit. "This may break your code if the library writer changes their implementation" kinda explicit.
Jun 29 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday, June 28, 2010 19:40:06 dsimcha wrote:
 Once enforcement of  property is enabled, we need to decide whether calling
 an  property function using ()s should be legal.  In other words, should
  property **require** omission of ()s or just allow it?  My vote is for
 just allowing omission, because I've run into the following ambiguity
 while debugging std.range.  Here's a reduced test case:
 
 struct Foo {
     uint num;
 
      property ref uint front() {
         return num;
     }
 }
 
 void main() {
     Foo foo;
     uint* bar = &foo.front;  // Tries to return a delegate.
 }
 
 If I can assume that  property functions can be called with explicit ()s to
 forcibly disambiguate this situation, then I can fix these kinds of bugs by
 simply doing a:
 
 uint* bar = &(foo.front());
 
 Can we finalize the idea that this will continue to be allowed now so that
 I can fix the relevant bugs in Phobos and know that my fix won't be broken
 in a few compiler releases?
FWIW, TDPL says that you can't use the parens when using a property function. - Jonathan M Davis
Jun 29 2010