www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property (again)

reply Manu <turkeyman gmail.com> writes:
It would be nice to have a commitment on  property.
Currently, () is optional on all functions, and  property means nothing.
I personally think () should not be optional, and  property should require
that () is not present (ie,  property has meaning).

This is annoying:
  alias F = function();

   property F myProperty() { return f; }

  Then we have this confusing situation:
    myProperty(); // am I calling the property, or am I calling the
function the property returns?

This comes up all the time, and it really grates my nerves.
Suggest; remove  property, or make it do what it's supposed to do.
Nov 20 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
 I personally think () should not be optional
No.
   Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling 
 the function the property returns?
Yes, this case is the whole reason property was added in the first place! How many years has it been now with the half-assed implementation? We can and should fix this without any other arguments about optional parenthesis.
Nov 20 2013
parent reply Manu <turkeyman gmail.com> writes:
On 21 November 2013 13:27, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:

 I personally think () should not be optional
No.
How is it ever an advantage to syntactically allow visual confusion between a function call and a variable? Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling the
 function the property returns?
Yes, this case is the whole reason property was added in the first place! How many years has it been now with the half-assed implementation? We can and should fix this without any other arguments about optional parenthesis.
Nov 20 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 21 November 2013 at 03:37:19 UTC, Manu wrote:
 On 21 November 2013 13:27, Adam D. Ruppe 
 <destructionator gmail.com> wrote:

 On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:

 I personally think () should not be optional
No.
How is it ever an advantage to syntactically allow visual confusion between a function call and a variable?
I'm going to reiterate Adam's final statement. We need to fix the second case you claim, shut up about the optional parens so it does get fixed an we stop preventing the one thing from getting fixed because of the other. Everyone agrees property should work, not everyone agrees about op() so drop the op() issue so property is fixed :)
Nov 20 2013
parent luka8088 <luka8088 owave.net> writes:
On 21.11.2013. 6:59, Jesse Phillips wrote:
 On Thursday, 21 November 2013 at 03:37:19 UTC, Manu wrote:
 On 21 November 2013 13:27, Adam D. Ruppe <destructionator gmail.com>
 wrote:

 On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:

 I personally think () should not be optional
No.
I'm going to reiterate Adam's final statement. We need to fix the second case you claim, shut up about the optional parens so it does get fixed an we stop preventing the one thing from getting fixed because of the other.
Amen to that.
Nov 20 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means 
 nothing.
 I personally think () should not be optional, and  property 
 should require
 that () is not present (ie,  property has meaning).

 This is annoying:
   alias F = function();

    property F myProperty() { return f; }

   Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling 
 the
 function the property returns?

 This comes up all the time, and it really grates my nerves.
 Suggest; remove  property, or make it do what it's supposed to 
 do.
Amen.
Nov 20 2013
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means 
 nothing.
 I personally think () should not be optional, and  property 
 should require
 that () is not present (ie,  property has meaning).

 This is annoying:
   alias F = function();

    property F myProperty() { return f; }

   Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling 
 the
 function the property returns?

 This comes up all the time, and it really grates my nerves.
 Suggest; remove  property, or make it do what it's supposed to 
 do.
It looks like Kenji's been doing something on that front. https://github.com/D-Programming-Language/dmd/pull/2305
Nov 20 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2013 7:14 PM, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means nothing.
 I personally think () should not be optional, and  property should require that
 () is not present (ie,  property has meaning).
The next release is going to be about bug fixes, not introducing regressions from new features(!). It's a short release cycle, anyway.
Nov 20 2013
next sibling parent Manu <turkeyman gmail.com> writes:
I wouldn't call  property a 'new' feature... it's been in there for years!
;)


On 21 November 2013 16:06, Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/20/2013 7:14 PM, Manu wrote:

 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means nothing.
 I personally think () should not be optional, and  property should
 require that
 () is not present (ie,  property has meaning).
The next release is going to be about bug fixes, not introducing regressions from new features(!). It's a short release cycle, anyway.
Nov 20 2013
prev sibling next sibling parent luka8088 <luka8088 owave.net> writes:
On 21.11.2013. 7:06, Walter Bright wrote:
 On 11/20/2013 7:14 PM, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means nothing.
 I personally think () should not be optional, and  property should
 require that
 () is not present (ie,  property has meaning).
The next release is going to be about bug fixes, not introducing regressions from new features(!). It's a short release cycle, anyway.
How is this not a but? It sure does not behave the same as described in http://dlang.org/property.html#classproperties . And what everyone wants (and agrees on) is that it should behave like it is described in the documentation! How does that not qualify as a bug!?
Nov 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-21 07:06, Walter Bright wrote:

 The next release is going to be about bug fixes, not introducing
 regressions from new features(!). It's a short release cycle, anyway.
You better watch what happens deep inside the pull requests then :) -- /Jacob Carlborg
Nov 20 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2013 11:51 PM, Jacob Carlborg wrote:
 On 2013-11-21 07:06, Walter Bright wrote:

 The next release is going to be about bug fixes, not introducing
 regressions from new features(!). It's a short release cycle, anyway.
You better watch what happens deep inside the pull requests then :)
One of my own recent pull requests produced a regression :-(
Nov 21 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 21, 2013 20:17:34 Walter Bright wrote:
 On 11/20/2013 11:51 PM, Jacob Carlborg wrote:
 On 2013-11-21 07:06, Walter Bright wrote:
 The next release is going to be about bug fixes, not introducing
 regressions from new features(!). It's a short release cycle, anyway.
You better watch what happens deep inside the pull requests then :)
One of my own recent pull requests produced a regression :-(
Well, that's the only way that regressions get in there in the first place, so obviously the solution is to not change anything, right? ;) On a serious note, at least we're now paying greater attention to regressions, which should be a definite boost to D's image from the standpoint of stability (and to some extent at least, I think that it already has). - Jonathan M Davis
Nov 21 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-22 05:17, Walter Bright wrote:

 One of my own recent pull requests produced a regression :-(
It seems like they wanted to merge a pull request even before 2.064 which would enforce property in some way. This one: https://github.com/D-Programming-Language/dmd/pull/2305 -- /Jacob Carlborg
Nov 22 2013
prev sibling next sibling parent luka8088 <luka8088 owave.net> writes:
On 21.11.2013. 4:14, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means nothing.
 I personally think () should not be optional, and  property should
 require that () is not present (ie,  property has meaning).
 
 This is annoying:
   alias F = function();
 
    property F myProperty() { return f; }
 
   Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling the
 function the property returns?
 
 This comes up all the time, and it really grates my nerves.
 Suggest; remove  property, or make it do what it's supposed to do.
Fix it! struct S { auto f1 () { return 1; } auto f2 () { return { return 2; }; } property auto p1 () { return 5; } property auto p2 () { return { return 6; }; } } unittest { S s1; // don't breat current function call behavior // don't deal with optional () now // (but also don't break their behavior) assert(s1.f1 == 1); assert(s1.f1() == 1); assert(s1.f2()() == 2); auto fv = s1.f2; assert(fv() == 2); // make sure propery works as described // in http://dlang.org/property.html#classproperties assert(s1.p1 == 5); static assert(!__traits(compiles, s1.p1() == 5)); assert(s1.p2() == 6); static assert(!__traits(compiles, s1.p2()() == 6)); auto pv1 = s1.p1; assert(pv1 == 5); auto pv2 = s1.p2(); assert(pv2 == 6); } This test is according to the documentation and as far as I remember everyone agrees that this is how property should behave.
Nov 20 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
I think,  property should be removed. Requiring to mark 
properties with an annotation to make them work unambiguously is 
bug-prone, because you can forget to do so and nothing will warn 
you.
Nov 21 2013
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property means 
 nothing.
 I personally think () should not be optional, and  property 
 should require
 that () is not present (ie,  property has meaning).

 This is annoying:
   alias F = function();

    property F myProperty() { return f; }

   Then we have this confusing situation:
     myProperty(); // am I calling the property, or am I calling 
 the
 function the property returns?
The latter. Property should be enforced properly.
 This comes up all the time, and it really grates my nerves.
 Suggest; remove  property, or make it do what it's supposed to 
 do.
If you combine: 1) enforced property syntax, no parens allowed 2) & always applies to a parenthesis-less function, not it's result 3) properties decay to normal functions when they have their address taken 4) For template params: pass function symbol if possible, otherwise evaluate and pass the result. then we have a solved problem, while allowing people to keep their nice pretty ()-less UFCS chains, no?
Nov 21 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/21/2013 02:04 PM, John Colvin wrote:
 3) properties decay to normal functions when they have their address taken
No, why?
Nov 21 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
 On 11/21/2013 02:04 PM, John Colvin wrote:
 3) properties decay to normal functions when they have their 
 address taken
No, why?
Sorry, I forgot to add: 5) parenthesis are enforced for all calls on all callables other than functions, including function pointers and delegates. In combination with 3 this prevents any ambiguity when dealing with addresses of functions. Otherwise they become impossible to manipulate as they would evaluate to their result anywhere they're mentioned in code. Some examples of things working how I suggest: property auto f() { return 3; } auto p = &f; auto q = p; //q is address of f auto r = q(); //r is 3 auto g() { return &f; } auto a = g(); //a is address of f auto b = g; assert(a is b); property auto z() { return &f; } auto c = z; //c is address of f
Nov 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 21 November 2013 at 14:11:54 UTC, John Colvin wrote:
 On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
 On 11/21/2013 02:04 PM, John Colvin wrote:
 3) properties decay to normal functions when they have their 
 address taken
No, why?
Sorry, I forgot to add: 5) parenthesis are enforced for all calls on all callables other than functions, including function pointers and delegates.
Why do we make the distinction between a first class function and a function in the first place ? C and C++ and PHP are the only languages I know that do that. That is quite telling on how good the idea is.
Nov 21 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/13 3:18 PM, deadalnix wrote:
 Why do we make the distinction between a first class function and a
 function in the first place ?

 C and C++ and PHP are the only languages I know that do that. That is
 quite telling on how good the idea is.
All three wildly successful :o). Andrei
Nov 21 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 21 November 2013 at 23:31:18 UTC, Andrei 
Alexandrescu wrote:
 On 11/21/13 3:18 PM, deadalnix wrote:
 Why do we make the distinction between a first class function 
 and a
 function in the first place ?

 C and C++ and PHP are the only languages I know that do that. 
 That is
 quite telling on how good the idea is.
All three wildly successful :o). Andrei
And recognized for their great design.
Nov 21 2013
prev sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
2013/11/22 deadalnix <deadalnix gmail.com>
 Why do we make the distinction between a first class function and a
 function in the first place ?
(This is just my recognition, so might be not same with true history. But I think there's not so big mistake.) Historically, mixing function themselves and function addresses had introduced huge confusion for non-expert C programers. Not to repeat the mistake, D completely distinguished the two at the syntax level - func and &func. Fortunately it has introduced a good feature in D - when we use the name 'func' without & operator, it could be interpreted as a parenthesis-less function call without ambiguity. In D1, the feature was widely used. However, the feature has a corner-case issue. If func returns a callable object, function pointer or delegate, does 'func()' mean either "call of 'func'" or "call the callable object which returned by calling 'func'"? That was particularly important problem for the Range.front API design in D2. To fix the issue, property attribute has been introduced. At least to me, your argument is just to return to the C era. I think it will introduce huge 'regression'. Kenji Hara
Nov 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 01:33:44 UTC, Kenji Hara wrote:
 2013/11/22 deadalnix <deadalnix gmail.com>
 Why do we make the distinction between a first class function 
 and a
 function in the first place ?
(This is just my recognition, so might be not same with true history. But I think there's not so big mistake.) Historically, mixing function themselves and function addresses had introduced huge confusion for non-expert C programers. Not to repeat the mistake, D completely distinguished the two at the syntax level - func and &func.
The best way to solve the confusion is to get rid of one of the two concept altogether.
 Fortunately it has introduced a good feature in D - when we use 
 the name
 'func' without & operator, it could be interpreted as a 
 parenthesis-less
 function call without ambiguity.
 In D1, the feature was widely used.
It was indeed a really good feature in D1. It is however clashing with functional style quite badly.
 At least to me, your argument is just to return to the C era. I 
 think it
 will introduce huge 'regression'.
This is an important misunderstanding of my position. The C era is bad, the D era is kind of better, but the exact same problem still exist. It is simply less visible. The concept of function as you call it is useless and is both the source of the confusion you mention in C and the tricky cases you mention in D.
Nov 21 2013
parent reply Kenji Hara <k.hara.pg gmail.com> writes:
2013/11/22 deadalnix <deadalnix gmail.com>

 On Friday, 22 November 2013 at 01:33:44 UTC, Kenji Hara wrote:

 At least to me, your argument is just to return to the C era. I think it
 will introduce huge 'regression'.
This is an important misunderstanding of my position. The C era is bad, the D era is kind of better, but the exact same problem still exist. It is simply less visible. The concept of function as you call it is useless and is both the source of the confusion you mention in C and the tricky cases you mention in D.
After removing 'function' concept, 'func' always means function pointer or delegate. So we cannot call functions without parenthesis anymore. It is unacceptable change to me, and many D programmers would probably argue same thing. Kenji Hara
Nov 21 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:
 After removing 'function' concept, 'func' always means function 
 pointer or
 delegate. So we cannot call functions without parenthesis 
 anymore. It is
 unacceptable change to me, and many D programmers would 
 probably argue same
 thing.
It removes all ambiguities. Optional parentheses are still an option when they aren't ambiguous. void foo() {} foo; // Can still call foo if we want to.
Nov 21 2013
next sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
2013/11/22 deadalnix <deadalnix gmail.com>

 On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:

 After removing 'function' concept, 'func' always means function pointer or
 delegate. So we cannot call functions without parenthesis anymore. It is
 unacceptable change to me, and many D programmers would probably argue
 same
 thing.
It removes all ambiguities. Optional parentheses are still an option when they aren't ambiguous. void foo() {} foo; // Can still call foo if we want to.
It will introduce a new ambiguity. See below example. int foo(); void test(int function() fp); void test(int num); void main() { test(foo); // which test is called? } Kenji Hara
Nov 21 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 07:37:11 UTC, Kenji Hara wrote:
 2013/11/22 deadalnix <deadalnix gmail.com>

 On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:

 After removing 'function' concept, 'func' always means 
 function pointer or
 delegate. So we cannot call functions without parenthesis 
 anymore. It is
 unacceptable change to me, and many D programmers would 
 probably argue
 same
 thing.
It removes all ambiguities. Optional parentheses are still an option when they aren't ambiguous. void foo() {} foo; // Can still call foo if we want to.
It will introduce a new ambiguity. See below example. int foo(); void test(int function() fp); void test(int num); void main() { test(foo); // which test is called? } Kenji Hara
The first one.
Nov 21 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 07:37:11 UTC, Kenji Hara wrote:
 2013/11/22 deadalnix <deadalnix gmail.com>

 On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:

 After removing 'function' concept, 'func' always means 
 function pointer or
 delegate. So we cannot call functions without parenthesis 
 anymore. It is
 unacceptable change to me, and many D programmers would 
 probably argue
 same
 thing.
It removes all ambiguities. Optional parentheses are still an option when they aren't ambiguous. void foo() {} foo; // Can still call foo if we want to.
It will introduce a new ambiguity. See below example. int foo(); void test(int function() fp); void test(int num); void main() { test(foo); // which test is called? } Kenji Hara
The first one. Note that optional () is ambiguous by definition - the word optional convey this very idea. The ambiguity introduced by optional () must not be conflated by the one introduced by the existence of non first class function. You stated that the existence of function is necessary for optional parentheses to exist, and I showed you that it is false. Nothing more, nothing less.
Nov 21 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-22 08:01, deadalnix wrote:

 It removes all ambiguities.

 Optional parentheses are still an option when they aren't ambiguous.

 void foo() {}

 foo; // Can still call foo if we want to.
int bar (); typeof(bar); What will the typeof resolve to, "int" or "int function ()"? -- /Jacob Carlborg
Nov 22 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 10:14:54 UTC, Jacob Carlborg wrote:
 On 2013-11-22 08:01, deadalnix wrote:

 It removes all ambiguities.

 Optional parentheses are still an option when they aren't 
 ambiguous.

 void foo() {}

 foo; // Can still call foo if we want to.
int bar (); typeof(bar); What will the typeof resolve to, "int" or "int function ()"?
You know that this is the exact same problem as Kenji's packages in another way ?
Nov 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-22 11:21, deadalnix wrote:

 You know that this is the exact same problem as Kenji's packages in
 another way ?
I guess so. -- /Jacob Carlborg
Nov 22 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 November 2013 at 12:40:17 UTC, Jacob Carlborg wrote:
 On 2013-11-22 11:21, deadalnix wrote:

 You know that this is the exact same problem as Kenji's 
 packages in
 another way ?
I guess so.
Short answer, foo is ambiguous with foo() when you enable optional parenthesis. That is the whole point of the feature. It doesn't require the concept of function as presented before, and is doomed to be a mess.
Nov 22 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
 On 11/21/2013 02:04 PM, John Colvin wrote:
 3) properties decay to normal functions when they have their 
 address taken
No, why?
properties should be just "variables without address". that is, taking the address of a property should be forbidden. if one needs to take the address, then the programmer should not implement it as a property. if one programmer tries to convert an existing variable to a property, then he/she should remove addresses where required. why so much hassle to think "variable" when speaking about "property"?
Nov 21 2013
parent "eles" <eles eles.com> writes:
On Thursday, 21 November 2013 at 15:25:21 UTC, eles wrote:
 On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
 On 11/21/2013 02:04 PM, John Colvin wrote:
 3) properties decay to normal functions when they have their 
 address taken
No, why?
properties should be just "variables without address".
and without shortcut operators such as ++ and += let's implement this simple model first. you could build latter on it whatever you want, but at least let's give some layer of consistency paint to tis issue.
Nov 21 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
 On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
 It would be nice to have a commitment on  property.
 Currently, () is optional on all functions, and  property 
 means nothing.
 I personally think () should not be optional, and  property 
 should require
 that () is not present (ie,  property has meaning).

 This is annoying:
  alias F = function();

   property F myProperty() { return f; }

  Then we have this confusing situation:
    myProperty(); // am I calling the property, or am I calling 
 the
 function the property returns?
The latter. Property should be enforced properly.
 This comes up all the time, and it really grates my nerves.
 Suggest; remove  property, or make it do what it's supposed to 
 do.
If you combine: 1) enforced property syntax, no parens allowed 2) & always applies to a parenthesis-less function, not it's result 3) properties decay to normal functions when they have their address taken 4) For template params: pass function symbol if possible, otherwise evaluate and pass the result. then we have a solved problem, while allowing people to keep their nice pretty ()-less UFCS chains, no?
I forgot to add: 5) parenthesis are enforced for all calls on all callables other than functions, including function pointers and delegates.
Nov 21 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
 3) properties decay to normal functions when they have their 
 address taken
Is there some reason why we _need_ to be able to take the address of properties? I've yet to see a good argument in favour of it, and I've seen several against. I think that whole idea is a misfeature that won't be missed. -Wyatt
Nov 21 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
 On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin 
 wrote:
 3) properties decay to normal functions when they have their 
 address taken
Is there some reason why we _need_ to be able to take the address of properties? I've yet to see a good argument in favour of it, and I've seen several against. I think that whole idea is a misfeature that won't be missed. -Wyatt
Are there any arguments against it within the context of the proposal i'm making? At the very least the obvious problems disappear. If the consensus was that the address of a property was an unnecessary concept then it could be disallowed and point 3) of my list disregarded. The rest stands separate from this issue.
Nov 21 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/21/2013 03:26 PM, John Colvin wrote:
 On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
 On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
 3) properties decay to normal functions when they have their address
 taken
Is there some reason why we _need_ to be able to take the address of properties? I've yet to see a good argument in favour of it, and I've seen several against. I think that whole idea is a misfeature that won't be missed. -Wyatt
Are there any arguments against it within the context of the proposal i'm making?
There is always this: ref int foo(){ return b?x:y; } &foo (i.e. return values can have addresses as well.) http://wiki.dlang.org/DIP24 See 'basic design' for my take on it. &__traits(propertyAccessors, foo) would get the address of the underlying function. IMO one could just encourage usage of ()ref=>foo, (int x)=>foo=x and allow/require the compiler to perform η-reduction though.
 At the very least the obvious problems disappear.

 If the consensus was that the address of a property was an unnecessary
 concept then it could be disallowed and point 3) of my list disregarded.
 The rest stands separate from this issue.
It is not unnecessary, but making unary '&' get a function pointer to the accessor is not really behaviour consistent with the point of the property annotation.
Nov 21 2013
prev sibling parent "eles" <eles eles.com> writes:
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
 On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin 
 wrote:
 3) properties decay to normal functions when they have their 
 address taken
Is there some reason why we _need_ to be able to take the address of properties? I've yet to see a good argument in favour of it, and I've seen several against. I think that whole idea is a misfeature that won't be missed. -Wyatt
++1++ it only brings trouble, as well as this discussion about decaying.
Nov 21 2013