On Thu, 24 Jan 2013 17:27:52 -0800, kenji hara <k.hara.pg@gmail.com> wrote:

> 2013/1/25 Adam Wilson <flyboynw@gmail.com>
>
>> On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara <k.hara.pg@gmail.com>
>> wrote:
>>
>>>
>>> 1. Optional parentheses for normal functions should work shallowly IMO.
>>> 2. Optional parentheses for property functions should not work. Applying
>>> ()
>>> for property function name always applied to its returned value.
>>>
>>> #1 is a ratification of current behavior. It allows the combination of
>>> UFCS
>>> and removing redundant ()s.
>>> #2 is a breaking change. If we need it, community consent is required.
>>>
>>> Kenji Hara
>>>
>>
>> I can completely agree with this change. It is perfectly workable to fix
>> properties without changing optional parens. I just won't use them :-P
>
>
> I have thought an additional idea.
> If we really want a feature to disable optional parentheses for normal
> functions, we can add @function attribute to the language spec.
>
> int foo();
> @property int bar();
> @function int baz();  // new!
>
> int x1 = foo();  // ok
> int x2 = foo;  // optional parentheses, allowed
> int y1 = bar();  // disallowed, calling int is meaningless
> int y2 = bar;  // ok
> int z1 = baz();  // ok
> int z2 = baz;  // *disallowed* by @function attribute
>
> How about?
>
> Kenji Hara

Very clever Mr. Hara, I like it a lot! But good luck convincing Walter+Andrei. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Friday, January 25, 2013 10:15:09 kenji hara wrote:
> 1. Optional parentheses for normal functions should work shallowly IMO.
> 2. Optional parentheses for property functions should not work. Applying ()
> for property function name always applied to its returned value.
> 
> #1 is a ratification of current behavior. It allows the combination of UFCS
> and removing redundant ()s.
> #2 is a breaking change. If we need it, community consent is required.

I'd say that we should do both. It's ridiculous to accept parens on property functions, since the whole point is that they be used as if they were variables. They're _supposed_ to be illegal (though -property doesn't check for it right now like it's supposed to - it only checks whether parens are used on non-property functions). So, I don't think that there's any question that #2 needs to happen with @property (unless Walter's horrid plan gets put into effect and we lose @property entirely). And #1 seems reasonable enough.

- Jonathan M Davis

2013/1/25 kenji hara <k.hara.pg@gmail.com>
>
>
> I have thought an additional idea.
> If we really want a feature to disable optional parentheses for normal
> functions, we can add @function attribute to the language spec.
>
> int foo();
> @property int bar();
> @function int baz();  // new!
>
> int x1 = foo();  // ok
> int x2 = foo;  // optional parentheses, allowed
> int y1 = bar();  // disallowed, calling int is meaningless
> int y2 = bar;  // ok
> int z1 = baz();  // ok
> int z2 = baz;  // *disallowed* by @function attribute
>

I think calling a function which does not annotated with @attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses.

He runs().  // normal function call
He runs.    // optional parentheses

Kenji Hara

On Thu, 24 Jan 2013 21:06:02 +0100
"mist" <none@none.none> wrote:
> 
> Not really. Good property usage is somewhat similar to unsafe cast usage - you say to others "Yes, I know what I am doing, please do not pay attention that this data is in fact function". The very point of properties is to be used almost indistinguishable from data and if this usage pattern fails - property author has lied and this is not really a property.
> 

+1

> And because of issues like "+=" it is rather difficult (if possible) to define good properties in D now.

+1

On Thu, 24 Jan 2013 13:08:08 -0800
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> > On 1/24/13 3:45 PM, Nick Sabalausky wrote:
> >> On Thu, 24 Jan 2013 12:51:32 -0500
> >> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
> >> No, you merely came up with *some* specific cherry-picked examples
> >> that sparked *some* debate (with most of the disagreing coming from
> >> you).
> >
> > I simply mentioned three reasons that came to mind.
> >

And I simply pointed out how they are incorrect.

> 
> While I don't approve of Mr. Sabalausky's tone or attitude,

Sorry about that. I'm just frustrated at fighting another uphill D battle against those who have far, far more pull than I do, and are every bit as difficult to sway as I am ;). It's nothing personal against Andrei or Walter or anyone else.

On Friday, 25 January 2013 at 01:54:03 UTC, Nick Sabalausky wrote:
> Sorry about that. I'm just frustrated at fighting another uphill D battle against those who have far, far more pull
> than I do, and are every bit as difficult to sway as I am ;).

I literally screamed at my computer screen a couple times in this thread. This is an argument we've been having for years and I've gotta say, I'm kinda fed up with it.

But I feel like we're finding common ground this time, where we weren't able to the last several times.

On 1/24/13 7:36 PM, Adam Wilson wrote:
> Also non-logical special case rules like this make the language harder
> to learn, therefore harder to evangelize.

Definitely. But it shouldn't be forgotten that syntactic warts are also a liability.

Andrei

On 1/24/13 7:41 PM, kenji hara wrote:
> I think that the "optional parentheses" feature for normal functions
> should always work in _shallowly_. Even if a function returns some
> callable object, "optional parentheses" should not applied to the return
> object recursively.
>
> That means:
> void delegate() foo() { ... }
> void main() {
>    auto x = foo();  // typeof(x) == void delegate()
>    auto y = foo;    // typeof(y) == void delegate()
> }
>
> Kenji Hara

Interesting, so that would mean if anyone ever wants to get the delegate AND call it in one shot would need to write: foo()().

I think this proposal has merit.

Andrei

On Friday, January 25, 2013 10:37:51 kenji hara wrote:
> 2013/1/25 kenji hara <k.hara.pg@gmail.com>
> 
> > I have thought an additional idea.
> > If we really want a feature to disable optional parentheses for normal
> > functions, we can add @function attribute to the language spec.
> > 
> > int foo();
> > @property int bar();
> > @function int baz(); // new!
> > 
> > int x1 = foo(); // ok
> > int x2 = foo; // optional parentheses, allowed
> > int y1 = bar(); // disallowed, calling int is meaningless
> > int y2 = bar; // ok
> > int z1 = baz(); // ok
> > int z2 = baz; // *disallowed* by @function attribute
> 
> I think calling a function which does not annotated with @attribute without parenthesis is legal, Even if a function has some side-effects and a name looks like verb. Because native English grammar does not require parentheses.
> 
> He runs(). // normal function call
> He runs. // optional parentheses

Honestly, I don't think that English grammar has anything to do with this. Code isn't English, even if the symbol names chosen are in English. A programming language's grammar should reflect what works best for having a language which is appropriately usable and maintainable. That doesn't necessarily have anything to do with the grammar of any natural language, especially when you consider how different programming language grammars are from those of natural languages.

- Jonathan M Davis

On 1/24/13 7:44 PM, Adam D. Ruppe wrote:
> On Friday, 25 January 2013 at 00:42:09 UTC, kenji hara wrote:
>> I think that the "optional parentheses" feature for normal functions
>> should always work in _shallowly_.
>
> I agree. This is the way it makes sense (and the way it is now).

So would Kenji's proposal float your boat?

Andrei