On 1/24/2013 5:15 PM, 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.

There is a way to do #2 without breaking existing code.

Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.

On Friday, 25 January 2013 at 01:28:05 UTC, kenji hara 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

I dunno, but for me the line above is a function pointer that is stored into an integer for later retrieval and use.

On Friday, January 25, 2013 00:19:28 Walter Bright wrote:
> On 1/24/2013 5:15 PM, 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.
> 
> There is a way to do #2 without breaking existing code.
> 
> Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.

Considering that it's always been the plan that @property would be enforced such that any use of it would be illegal with parens (it's explicitly among the things tha TDPL says about @property), the expectation of pretty much every D programmer is that that's how @property functions are to be used, and it shouldn't come as any surprise when that's enforced. As such, I really don't think that it's a big deal if we simply start enforcing that @property functions be called without parens. And if you're really concerned about breakage, then we could start with making it a warning rather than an error. But I wager that in almost all cases, any such warning or error would be triggered by a mistake rather than someone intentially using parens with an @property function.

- Jonathan M Davis

On Friday, 25 January 2013 at 08:19:28 UTC, Walter Bright wrote:
> On 1/24/2013 5:15 PM, 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.
>
> There is a way to do #2 without breaking existing code.
>
> Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.

Yes, or maybe we should adopt a sane release process . . .

On Friday, January 25, 2013 00:29:52 Jonathan M Davis wrote:
> On Friday, January 25, 2013 00:19:28 Walter Bright wrote:
> > On 1/24/2013 5:15 PM, 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.
> > 
> > There is a way to do #2 without breaking existing code.
> > 
> > Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.
> 
> Considering that it's always been the plan that @property would be enforced such that any use of it would be illegal with parens (it's explicitly among the things tha TDPL says about @property), the expectation of pretty much every D programmer is that that's how @property functions are to be used, and it shouldn't come as any surprise when that's enforced. As such, I really don't think that it's a big deal if we simply start enforcing that @property functions be called without parens. And if you're really concerned about breakage, then we could start with making it a warning rather than an error. But I wager that in almost all cases, any such warning or error would be triggered by a mistake rather than someone intentially using parens with an @property function.

In fact, I'd argue that making @property enforce that a function be called without parens would be on par with things like starting to enforce that final switch has cases for all of the values in an enum. Yes, it can break code, but it only breaks code because the feature wasn't enforcing what it was supposed to enforce per the spec. And we've made those sorts of changes before. It's really just a bug fix, albeit one that risks having a larger impact than many. Code which follows the spec won't be broken by the change.

- Jonathan M Davis

2013/1/25 Walter Bright <newshound2@digitalmars.com>

> On 1/24/2013 5:15 PM, 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.
>>
>
> There is a way to do #2 without breaking existing code.
>
> Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.
>

Instead, we can simply change the semantic behavior, when -property switch
is specified.
Because -property switch should have been used for enabling "experimental
feature".

In phobos, we need to care the semantic change by adding `static if`
branches.
By the following code we can detect whether the -property switch is really
specified or not.

enum enforceProperty = !__traits(compiles, {
    int prop(){ return 1; }
    int n = prop;
});

Kenji Hara

On Friday, 25 January 2013 at 07:14:19 UTC, Jonathan M Davis wrote:
> On Friday, January 25, 2013 07:47:27 eles wrote:
>> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis
> However, even if we're stuck with parenless function calls being legal, we can
> still have @property function like it does in C# and require that it be used
> without parens.

I think the root reason of this fight over what properties are and how are used/usable boils down to the way they are deined in D over C#:

1. in D they are defined as functions (or very similarily to those), so many people are perceiving them as FUNCTIONS to which one tries to stick some variable-like calls

2. in C# they are deined as VARIABLES WITH ACCESSORS, so many people tend to see those as some variables with some extra.

IMHO the chosen syntax for defining properties matters in the first place.

I do not dear to suggest implementing a more variable-like syntax (like the one in C#), but at least decide once for all which side of the barricade we wand D's properties to be.

On Friday, 25 January 2013 at 08:19:28 UTC, Walter Bright wrote:
> On 1/24/2013 5:15 PM, kenji hara wrote:
> Create a new property attribute, say, @prop. Imbue it with the new behavior. Leave the old @property as it is, and let it cycle through the usual warning, deprecation, removal process.

I think the way picked to do the change is, now, of secondary importance. Prioritary is to decide what is the aim of that change.

OTOH, I reallyy do not like "@prop" (proposal? proposition? property? proponent?), maybe a better name is needed.

Tooo bad, I feel like the best word for that, namely "@property" was wasted.

On Friday, January 25, 2013 09:49:00 eles wrote:
> On Friday, 25 January 2013 at 07:14:19 UTC, Jonathan M Davis
> 
> wrote:
> > On Friday, January 25, 2013 07:47:27 eles wrote:
> >> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis
> > 
> > However, even if we're stuck with parenless function calls
> > being legal, we can
> > still have @property function like it does in C# and require
> > that it be used
> > without parens.
> 
> I think the root reason of this fight over what properties are and how are used/usable boils down to the way they are deined in D over C#:
> 
> 1. in D they are defined as functions (or very similarily to those), so many people are perceiving them as FUNCTIONS to which one tries to stick some variable-like calls
> 
> 2. in C# they are deined as VARIABLES WITH ACCESSORS, so many people tend to see those as some variables with some extra.
> 
> IMHO the chosen syntax for defining properties matters in the first place.
> 
> I do not dear to suggest implementing a more variable-like syntax (like the one in C#), but at least decide once for all which side of the barricade we wand D's properties to be.

I think that C#'s syntax (or something close to it) probably would have been better, but it's too late now. But a lot of the problem stems from the fact that the original way that properties were implemented in D was essentially what Walter is proposing now, and I believe that the fact that that worked originally was at least partially by accident. So, it's pretty much always been the case in D that properties were implemented via functions, and any change to a syntax similar to C#'s would have been a big change (much as it probably would have been a good idea).

- Jonathan M Davis

On Friday, January 25, 2013 09:54:02 eles wrote:
> Tooo bad, I feel like the best word for that, namely "@property" was wasted.

I dispute that we can't just use @property since it was its design from the get-go that it would require that there be no parens (it's even discussed in TDPL). It's just that it hasn't been properly enforced. Making it so that it's enforced would be like when we fixed it so that the compiler enforced that final switch statements had cases for all of an enum's values. Code which followed the spec was unaffected, and for any code that _was_ affected, the new enforcement was catching a bug.

- Jonathan M Davis