2013/1/25 Jonathan M Davis <jmdavisProg@gmx.com>

> I know, and I agree with it. But Andrei is pushing for removing @property entirely and looking for arguments to keep it. And IMHO, the issue of how setters are handled is an extremely good reason to keep @property.


I'd like to argue that we should keep @property attribute.

Kenji Hara

On Friday, 25 January 2013 at 01:38:01 UTC, 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
>
> Kenji Hara

English grammar don't have any functional style enable. It is not possible to return runs itself.

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

@function seems like an extra complication. Ambiguity between setter and getter for @properties when UFCS come into play are not solved. Functional style is impaired as you can't pass regular function around, just @function . You'll still find trap in generic code around the behavior of regular functions.

On Friday, 25 January 2013 at 02:24:06 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 9:11 PM, Jonathan M Davis wrote:
>> I believe that that's what we have now. The problem is when you want a
>> property which returns a delegate. And for that, we need @property. Getting
>> rid of @property makes it a problem, whereas with @property, it can work - as
>> can property functions which return delegates.
>
> Well how about we just renounce those for the sake of simplification.
>

I don't understand. We want to drop feature that work in other languages and bring benefit, but it is actually impossible to drop a feature that bring many ambiguities for a small syntactic sugar ?

On Friday, 25 January 2013 at 03:52:36 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 9:54 PM, Adam Wilson wrote:
>> On Thu, 24 Jan 2013 18:00:06 -0800, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> 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
>>
>> I would argue that given how common they already are, cost of the wart
>> is far smaller than the benefit of not having the unique-to-D special
>> case that makes the language that much harder to learn.
>
> Again, the question needs asking: is it a given that we need to allow optional parentheses? Otherwise we'll keep on rehashing this over and over again.
>

It is NOT and workaround have been proposed to solve the UFCS () invasion case, which is probably the only one that don't boil down to lazyness when digging a little.

On 01/24/2013 07:34 PM, Jesse Phillips wrote:
> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> 1. Empty parens are optional. If there is an ambiguity with the return
>> value taking (), the () go on the return value.
>
> As mentioned, this seems dangerous. I'd suggest requiring when there is
> ambiguity. It still has generic problems, but it will never be silent.
>
>> 4. No more @property.
>
> I'm on the side that would miss optional parens if they died. In would
> be nice if @property actually made a function behave like a field.
>
> foo += bar;
>
> It seems there are lots of complications around this? So yes kill
> @property.
>

This has nothing to do with @property.  It has to do with defining what += /does/ to a property.

I think that what you want is semantic property rewriting.

See this:
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties

> On another note,
>
> To properly correct this situation we will break code. So before you get
> started be sure to try out the new feature preview release approach :)

On 01/24/2013 03:45 PM, Jonathan M Davis wrote:
> On Thursday, January 24, 2013 00:34:42 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.
>>
>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>
> Another issue to consider is enhancements such as
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8006
>
> As a property function is supposed to be an abstraction for a variable, and
> you really should be able to swap out property functions and public variables
> without breaking code, things like
>
> foo.prop += 5;
>
> and
>
> ++foo.prop;
>
> should work. Unfortunately, D's current property implementation is poor enough
> that that code doesn't currently, but that can be fixed in a backwards-
> compatible-manner.
>

I think what you want is semantic property rewriting.
Please see this:
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties

> But implementing something like that becomes more problematic without explicit
> properties (potentially even dangerous, depending on what ends up happening
> with those sorts of expressions with non-@property functions which are called
> without parens). Maybe it could be done, but it seems to me that it's the sort
> of thing that should be controlled. We don't want lots of voodoo happening
> with functions called without parens, as we risk getting some nasty bugs when
> using functions that weren't really meant to be properties. But we _do_ want
> some of that voodoo with functions that are designed to be properties.
>
> So, I really think that we need to have explicit properties, even if we allow
> paran-less function calls in some other cases.
>
> But honestly, I wish that we'd just gone with something closer to what C# did
> with properties from the get-go.
>
> - Jonathan M Davis

2013/1/25 deadalnix <deadalnix@gmail.com>
>
> @function seems like an extra complication. Ambiguity between setter and getter for @properties when UFCS come into play are not solved. Functional style is impaired as you can't pass regular function around, just @function . You'll still find trap in generic code around the behavior of regular functions.
>

That's a good point. We need to solve another ambiguity about top-level @property function which have a parameter, between top-level property setter and UFCS property getter.

module abc;
@property int foo(int n);

void main() {
  foo = 1;  // top-level property setter
  1.foo;  // property getter with UFCS
}

We cannot distinguish the two usages without adding any new features.

Kenji Hara

On Friday, January 25, 2013 14:35:08 kenji hara wrote:
> 2013/1/25 deadalnix <deadalnix@gmail.com>
> 
> > @function seems like an extra complication. Ambiguity between setter and
> > getter for @properties when UFCS come into play are not solved. Functional
> > style is impaired as you can't pass regular function around, just
> > @function
> > . You'll still find trap in generic code around the behavior of regular
> > functions.
> 
> That's a good point. We need to solve another ambiguity about top-level @property function which have a parameter, between top-level property setter and UFCS property getter.
> 
> module abc;
> @property int foo(int n);
> 
> void main() {
>   foo = 1;  // top-level property setter
>   1.foo;  // property getter with UFCS
> }
> 
> We cannot distinguish the two usages without adding any new features.

Well, better that then get rid of @property. The other big question is what to do with opDispatch, since unless we add the ability to overload on @property with opDispatch, then it can't work with both properties and non-property functions. Maybe opPropDispatch or somesuch could be introduced to solve that particular problem.

As for the top-level property problem, we could do something like @property(set) / @property(get) to distinguish. Or if we don't want the extra complication, we can just leave it. As long as you can use it as both a getter and a setter, it works, even if it still allows for weird uses. It would be nice to have a way to disambiguate it however.

- Jonathan M Davis

On Friday, 25 January 2013 at 05:51:44 UTC, Jonathan M Davis wrote:
> Well, better that then get rid of @property. The other big question is what to
> do with opDispatch, since unless we add the ability to overload on @property
> with opDispatch, then it can't work with both properties and non-property
> functions. Maybe opPropDispatch or somesuch could be introduced to solve that
> particular problem.
>

Can you explain the problem you see with opDispatch ?