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.

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.

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.
>

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.

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

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

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.

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.
>
>

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.

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!?