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.

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.

PS: I hate the solution for the #11365

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.

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.

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

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.

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

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.

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 :-(

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