This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.

Perhaps we should revert to a simple set of rules.

1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.

2. the:
   f = g
rewrite to:
   f(g)
only happens if f is a function that only has overloads for () and (one argument). No variadics.

3. Parens are required for calling delegates or function pointers.

4. No more @property.

On 2013-01-24 09:34, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return
> value taking (), the () go on the return value.
>
> 2. the:
>     f = g
> rewrite to:
>     f(g)
> only happens if f is a function that only has overloads for () and (one
> argument). No variadics.

What do you mean by: "overloads for ()"?

> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

So:

void delegate () foo ();

foo() // would call the delegate ?

-- 
/Jacob Carlborg

On 1/24/2013 12:57 AM, Jacob Carlborg wrote:
>> only happens if f is a function that only has overloads for () and (one
>> argument). No variadics.
>
> What do you mean by: "overloads for ()"?

I mean there are no f(...) and f(U,T) overloads.

>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>
> So:
>
> void delegate () foo ();
>
> foo() // would call the delegate ?


Yes.

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
[...]
> 4. No more @property.

You went half the way and now you're tired. Going back will be just as painful as going all the way.
I say, keep @property and fix it.

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.

I agree, the cure seems to be ten times worse than the disease. It's consumed far more resources than it is worth.

In my experience one of the main reasons that projects fail, is that nobody had the courage and humility to say, "this idea is a failure, we need to throw it away and do something completely different".

> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.

An example would make this easier to understand.

>
> 2. the:
>    f = g
> rewrite to:
>    f(g)
> only happens if f is a function that only has overloads for () and (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

On 1/24/2013 1:11 AM, Don wrote:
>> 1. Empty parens are optional. If there is an ambiguity with the return value
>> taking (), the () go on the return value.
>
> An example would make this easier to understand.

Jacob's should do.

f = g; where it means f(g) is really ugly. I wouldn't like to see this.

Also:

void printSomeStuff()
{
  //...
}

We are going to see code like this:
printSomeStuff; // i think that's ugly.

I suggested make parentheses optional only for UFC syntax.
Also isn't it possible to allow @property for functions that belong in a class/struct only?

On Thursday, 24 January 2013 at 10:22:00 UTC, Minas Mina wrote:
> f = g; where it means f(g) is really ugly. I wouldn't like to see this.
>
> Also:
>
> void printSomeStuff()
> {
>   //...
> }
>
> We are going to see code like this:
> printSomeStuff; // i think that's ugly.
>
> I suggested make parentheses optional only for UFC syntax.
> Also isn't it possible to allow @property for functions that belong in a class/struct only?

@property also makes sense for global functions that need to emulate a run-time initialized static variable.

On 1/24/2013 2:21 AM, Minas Mina wrote:
> We are going to see code like this:
> printSomeStuff; // i think that's ugly.

Eeeyup. As for it being 'ugly', yes, it is a bit unsettling to us old time C programmers, but I think we can get used to it in short order. You can still add the () if you prefer.

> I suggested make parentheses optional only for UFC syntax.

The simpler the rules are, the more likely they are to work.

> Also isn't it possible to allow @property for functions that belong in a
> class/struct only?

I want to get rid of @property. It's an eyesore.

Walter Bright wrote:

> 4. No more @property.

yippee!
-manfred