One thing I am interested to hear from ones who think allowing no-parens calls is fine is the following snippet:

http://dpaste.1azy.net/cd2f759e

------------------------------------------------------------
import std.stdio;

alias Delegate1 = int delegate();
alias Delegate2 = Delegate1 delegate();

Delegate2 func()
{
	writeln("Function");
	return (){
		writeln("First delegate");
		return (){
			writeln("Second delegate");
			return 42;
		};
	};
}

int call(alias func)()
{
	return func;
}

void main()
{
	writeln("Case 1");
	func;
	writeln("Case 2");
	func();
	writeln("Case 3");
	func()();
	writeln("Case 4");
	auto tmp = func();
	// tmp; // Error: var has no effect in expression (tmp)
}
------------------------------------------------------------

Upon any design choice questions should asked:
1) How this should behave to be consistent?
2) Should this error be an error?
3) How much special casing are you ready to throw in?

Also I really like an addition with prohibiting to use @property functions _with_ parens. Add this to prohibiting no-parens calls for normal ones and you will get my ideal solution, strict and clear.

And I still don't see why it won't fly. Yes, it will break user code. No, this is not an issue. At this point it is clear some design mistakes need to be corrected without stockpiling workarounds and one of major goals for new release process was to allow breaking changes with least possible user inconvenience. If it is not the case, then new release process has failed as much as @property.

Am Thu, 24 Jan 2013 12:51:32 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> 
> No. The complications come from the fact that (a) nobody could agree what should be a @property and what shouldn't;

There are only 2 kinds of programmers: Those who read the C# guidelines for properties and those who didn't. Seriously, I never found it difficult to decide if something should be a property, the C#/.NET folks have pretty clear rules.

> (b) @property adds
> noise for everybody for the sake of a corner case (functions
> returning delegates);

Partially true, although the real question is whether the additional () are really noise or actually useful. A hardcore C programmer (wants to see every function call) and a ruby developer could probably have a long discussion about that.

>(c) the @property discipline failed to align
> itself in any way with better code quality.

It's hard to verify if code quality changed if the feature isn't properly implemented. Even if it was properly implemented comparing code quality probably isn't easy.

On 1/24/13 1:35 PM, mist wrote:
> You see, contrary to UFCS chaining this is not habit or syntax issue. It
> is semantic one - I am loosing an ability to distinct data access from
> function call by simply looking at code.

This is the case with any property implementation.

Andrei

On 1/24/13 1:37 PM, Adam D. Ruppe wrote:
> Thinking about it, this isn't quite a full circle. It does improve a bit.

Yes, I was about to write an email to destroy :o).

> If we aren't going dip21, how about:
>
> ===
>
> Everything stays the way it is now, except:
>
> * if a @property is called with parens, they always apply to the return
> value
>
> * -property hopefully dies.
>
> ===
>
>
> I don't really like it, it leaves a number of problems behind... but
> that would be an improvement on the status quo. I don't hate it.

Interesting, thanks.


Andrei

On Thursday, 24 January 2013 at 20:00:18 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 1:35 PM, mist wrote:
>> You see, contrary to UFCS chaining this is not habit or syntax issue. It
>> is semantic one - I am loosing an ability to distinct data access from
>> function call by simply looking at code.
>
> This is the case with any property implementation.
>
> Andrei

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.

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

On 1/24/13 2:03 PM, Artur Skawina wrote:
> On 01/24/13 19:05, Andrei Alexandrescu wrote:
>> On 1/24/13 9:47 AM, Artur Skawina wrote:
>>> Having ()-less function calls is just insane; if it isn't obvious to you why,
>>> you just haven't read enough code that (ab)uses them.
>>
>> You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.
>
> You're more than welcome to produce counterevidence, or ignore the arguments,
> for whatever reasons. Ad hominems won't work, not only because I don't take this
> personally, but because I'm probably the person most willing/likely to discuss any
> relevant issues around here (I wish there was more like us (ie me)).

Good quality discussion is always welcome. I have specifically opposed a specific rhetoric, not a person, so "ad hominem" is inappropriate here.

> Trying to make arguments you don't like go away and silencing the messenger
> is your MO.

Now that's what's called "ad hominem".

> Please don't do that anymore.

I will always protest the rhetoric mentioned, sorry.

> Not because I ask you to, but because it
> does harm the language, and the "community".  Trying to at least understand the
> other point of view and reflecting a bit can be very enlightening. Who knows, you
> might even learn something new.

Sarcasm is always appreciated :o). On a serious note, it's a bit assuming to conclude that disagreeing with something must be caused by not understanding it. This is not rocket science. The points involved are understood. That doesn't entail agreement.

> Having said that, I'll elaborate on the sentence you quoted above. See for example
> Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in the
> tree-walker.

How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.


Andrei

On 1/24/13 2:14 PM, Jonathan M Davis wrote:
> On Thursday, January 24, 2013 18:54:00 David Nadlinger wrote:
>> On Thursday, 24 January 2013 at 17:51:32 UTC, Andrei Alexandrescu
>>
>> wrote:
>>> No. The complications come from the fact that (a) nobody could
>>> agree what should be a @property and what shouldn't; (b)
>>> @property adds noise for everybody for the sake of a corner
>>> case (functions returning delegates); (c) the @property
>>> discipline failed to align itself in any way with better code
>>> quality.
>>
>> The simple(r) explanation is: The current *implementation* is
>> broken.
>
> Exactly. Most of the problems with @property stem from the fact that it's not
> implemented properly, particularly with regards to the -property flag.

That is because it's not well defined.

Andrei

On 1/24/2013 8:29 AM, Andrei Alexandrescu wrote:
>> What do you mean by: "overloads for ()"?
>
> That means there must be two overloads of f exactly:
>
> T f();
> f(T);

There could also be f(U), f(V), etc., just that the are all 0 or 1 arg.

On 1/24/2013 8:43 AM, deadalnix wrote:
> On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
>> Yes.
>>
>> a = foo; // fetch the delegate
>> b = foo(); // fetch and invoke the delegate
>>
>
> I generic code, bugs I predict !

I would also count:

   f(some tuple)

as requiring () even if "some tuple" expands to zero arguments. This should resolve issues with generic code.

On 1/24/2013 10:17 AM, Andrei Alexandrescu wrote:
> On 1/24/13 12:15 PM, Peter Alexander wrote:
>> On Thursday, 24 January 2013 at 16:29:07 UTC, Andrei Alexandrescu wrote:
>>> On 1/24/13 3:57 AM, Jacob Carlborg wrote:
>>>> void delegate () foo ();
>>>>
>>>> foo() // would call the delegate ?
>>>
>>> Yes.
>>>
>>> a = foo; // fetch the delegate
>>> b = foo(); // fetch and invoke the delegate
>>
>> How about generic code?
>>
>> void callFunc(alias f, Args...)(Args args)
>> {
>> f(args);
>> }
>>
>> void delegate() foo();
>> void delegate(int) bar(int x);
>>
>> callFunc!foo(); // calls delegate?
>> callFunc!bar(0); // calls bar?
>>
>> Seems like a recipe for disaster.
>
> Agreed. This is a good litmus test. One option we had in mind was to still keep
> @property for disambiguating such cases.

Another option is f(args) always requires parens, even if args expands to 0 args.