digitalmars.D - property (again)

Manu (12/12) Nov 20 2013 It would be nice to have a commitment on @property.

Adam D. Ruppe (7/11) Nov 20 2013 Yes, this case is the whole reason @property was added in the

Manu (4/15) Nov 20 2013 How is it ever an advantage to syntactically allow visual confusion betw...

Jesse Phillips (7/18) Nov 20 2013 I'm going to reiterate Adam's final statement. We need to fix the

luka8088 (2/18) Nov 20 2013 Amen to that.

deadalnix (2/18) Nov 20 2013 Amen.
Meta (3/19) Nov 20 2013 It looks like Kenji's been doing something on that front.
Walter Bright (3/7) Nov 20 2013 The next release is going to be about bug fixes, not introducing regress...

Manu (3/12) Nov 20 2013 I wouldn't call @property a 'new' feature... it's been in there for year...
luka8088 (7/17) Nov 20 2013 How is this not a but?
Jacob Carlborg (4/6) Nov 20 2013 You better watch what happens deep inside the pull requests then :)

Walter Bright (2/6) Nov 21 2013 One of my own recent pull requests produced a regression :-(

Jonathan M Davis (7/15) Nov 21 2013 Well, that's the only way that regressions get in there in the first pla...
Jacob Carlborg (6/7) Nov 22 2013 It seems like they wanted to merge a pull request even before 2.064

luka8088 (31/47) Nov 20 2013 Fix it!
Kagamin (4/4) Nov 21 2013 I think, @property should be removed. Requiring to mark
John Colvin (12/28) Nov 21 2013 If you combine:

Timon Gehr (2/3) Nov 21 2013 No, why?

John Colvin (19/25) Nov 21 2013 Sorry, I forgot to add:

deadalnix (5/16) Nov 21 2013 Why do we make the distinction between a first class function and

Andrei Alexandrescu (3/7) Nov 21 2013 All three wildly successful :o).

deadalnix (3/13) Nov 21 2013 And recognized for their great design.

Kenji Hara (21/23) Nov 21 2013 (This is just my recognition, so might be not same with true history. Bu...

deadalnix (11/35) Nov 21 2013 The best way to solve the confusion is to get rid of one of the

Kenji Hara (6/16) Nov 21 2013 After removing 'function' concept, 'func' always means function pointer ...

deadalnix (6/13) Nov 21 2013 It removes all ambiguities.

Kenji Hara (9/21) Nov 21 2013 It will introduce a new ambiguity. See below example.

deadalnix (2/32) Nov 21 2013 The first one.
deadalnix (9/39) Nov 21 2013 The first one.

Jacob Carlborg (6/10) Nov 22 2013 int bar ();

deadalnix (3/15) Nov 22 2013 You know that this is the exact same problem as Kenji's packages

Jacob Carlborg (4/6) Nov 22 2013 I guess so.

deadalnix (5/10) Nov 22 2013 Short answer, foo is ambiguous with foo() when you enable

eles (9/15) Nov 21 2013 properties should be just "variables without address". that is,

eles (6/15) Nov 21 2013 and without shortcut operators such as ++ and +=

John Colvin (4/35) Nov 21 2013 I forgot to add:
Wyatt (6/8) Nov 21 2013 Is there some reason why we _need_ to be able to take the address

John Colvin (7/17) Nov 21 2013 Are there any arguments against it within the context of the

Timon Gehr (13/30) Nov 21 2013 There is always this:

eles (3/13) Nov 21 2013 ++1++

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

"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

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

"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

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

"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

"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

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

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

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

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

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

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

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

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

"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

"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

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

"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

"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

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

"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

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

"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

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

"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

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

"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

"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

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

"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

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

"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

"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

"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

"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

"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

"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

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

"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

D Programming

C/C++ Programming

Other

digitalmars.D - property (again)