On Thursday, 24 January 2013 at 21:40:01 UTC, Adam Wilson wrote:
> Remove Optional Parens.

This has absolutely nothing to do with properties because properties are data fields, NOT functions.

http://forum.dlang.org/post/fpbvfpvnjtgqbganqece@forum.dlang.org

On Thu, 24 Jan 2013 13:34:45 -0800, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 24 January 2013 at 21:20:01 UTC, Jonathan M Davis wrote:
>> We wouldn't have all of these problems if we'd just
>> gone with a C#-esque property design
>
> http://msdn.microsoft.com/en-us/library/w86s7x04(v=VS.80).aspx
>
> "To the user of an object, a property appears to be a field, accessing the property requires exactly the same syntax."
>
>
> Say it with me: properties are DATA FIELDS. Function syntax has NOTHING to do with them!
>
> We could change function syntax to require you to draw out some ASCII art of a running cat.... and it shouldn't affect properties one bit.
>
> Optional parens is a matter of function syntax. Properties are data fields, so function syntax doesn't matter to them.

The problem is that optional parens introduce ambiguity in relation to what is a property versus a function from the compilers prospective. So they are a matter of functional call syntax in that they are non-trivial for the compiler to deduce between the two.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thu, 24 Jan 2013 13:41:55 -0800, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 24 January 2013 at 21:40:01 UTC, Adam Wilson wrote:
>> Remove Optional Parens.
>
> This has absolutely nothing to do with properties because properties are data fields, NOT functions.
>
> http://forum.dlang.org/post/fpbvfpvnjtgqbganqece@forum.dlang.org
>

From the compilers standpoint they are functions. It must be so. That's how they're implemented.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, 24 January 2013 at 21:41:58 UTC, Adam Wilson wrote:
> The problem is that optional parens introduce ambiguity in relation to what is a property versus a function from the compilers prospective.

No, it doesn't.

struct Thing {
   int foo() { return 0; } // method
   int bar; // data field
   @property int baz() { return 0; } // data field
}

Thing t;
t.bar = 10; // this is a data field because it is
    // declared as "int bar" above,
    // not because I didn't use parens down here

t.foo; // this is a function call because t.foo is a function

t.baz; // this is a data field because i declared
       // "@property int" above, not because I left off parens here

t.bar(); // error, type int has no call method

t.baz(); // error, type int has no call method

On Jan 24, 2013, at 1:40 PM, Nathan M. Swan <nathanmswan@gmail.com> wrote:

> 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.
>> 
>> 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.
> 
> What about code that's always ignored @property?
> 
> 
>    int delegate() _del;
> 
>    int delegate() getDelegate() {
>        return _del;
>    }
> 
>    auto del = getDelegate(); // does _del get called?

I think a clarification of rule 1 is that parens will be right-associative.  So in your example, _del would be called.

On Thursday, January 24, 2013 22:24:58 Adam D. Ruppe wrote:
> On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:
> > The problem with @property isn't @property, it's D's insistence on optional parens.
> 
> No, this isn't a problem; function call syntax has nothing whatsoever to do with @property because a property is NOT logically a function!

D's insistance on optional parens _does_ cause problems with functions that return delegates, but @property itself isn't really affected by optional parens save for the visual ambiguity caused by optional parens.

> This is so important: a property is supposed to be indistinguishable from a data member. That's the fundamental definition. It should be fully interchangeable for a plain data member.
> 
> In other words, as far as the user is concerned, a property *is* a data member, NOT a function!
> 
> If functions have optional parens, that changes nothing about how you access data members.... and since properties are data members, it changes absolutely nothing about them either.
> 
> If we required data to be accessed with foo->bar and methods to be called [foo:bar].... a property would be accessed foo->bar. The method syntax is irrelevant.
> 
> That the property is implemented with a function call should not be known to the user code.

This should probably be emphasized more. A property is an abstraction for a variable and how it's implemented should be irrelevant to the caller. Ideally, it would even be irrelevant whether it's a variable or a property function (though making that the case would require both implementing http://d.puremagic.com/issues/show_bug.cgi?id=8006 and providing a way to mark variables such that they're treated as rvalues rather than lvalues; otherwise, it's still possible to break code when turning a variable into a property function).

And we can (and should) implement @property in a way that deals with properties properly regardless of what we do with parenless function calls.

- Jonathan M Davis

On Thu, 24 Jan 2013 13:45:44 -0800, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 24 January 2013 at 21:41:58 UTC, Adam Wilson wrote:
>> The problem is that optional parens introduce ambiguity in relation to what is a property versus a function from the compilers prospective.
>
> No, it doesn't.
>
> struct Thing {
>     int foo() { return 0; } // method
>     int bar; // data field
>     @property int baz() { return 0; } // data field
> }
>
> Thing t;
> t.bar = 10; // this is a data field because it is
>      // declared as "int bar" above,
>      // not because I didn't use parens down here
>
> t.foo; // this is a function call because t.foo is a function
>
> t.baz; // this is a data field because i declared
>         // "@property int" above, not because I left off parens here
>
> t.bar(); // error, type int has no call method
>
> t.baz(); // error, type int has no call method

Right, this conversation is about removing @property, which invalidates your argument by turning the data into a function, which is what we want to avoid. Also you might want to run your examples before posting them. t.baz() is NOT an error, which incidentally why the ambiguities I mentioned exist and need to be quashed.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, January 24, 2013 13:48:53 Sean Kelly wrote:
> On Jan 24, 2013, at 1:40 PM, Nathan M. Swan <nathanmswan@gmail.com> wrote:
> > 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.
> >> 
> >> 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.
> > 
> > What about code that's always ignored @property?
> > 
> > int delegate() _del;
> > 
> > int delegate() getDelegate() {
> > 
> > return _del;
> > 
> > }
> > 
> > auto del = getDelegate(); // does _del get called?
> 
> I think a clarification of rule 1 is that parens will be right-associative. So in your example, _del would be called.

I'd argue for simply making it so that the parens are required when a function returns something which is callable. So, getDelegate would be illegal, getDelegate() would return the delegate, and getDelegate()() would call the delegate.

- Jonathan M Davis

On 1/24/13 4:08 PM, Adam Wilson wrote:
> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>>> On Thu, 24 Jan 2013 12:51:32 -0500
>>> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>> No, you merely came up with *some* specific cherry-picked examples that
>>> sparked *some* debate (with most of the disagreing coming from
>>> you).
>>
>> I simply mentioned three reasons that came to mind.
>>
>> Andrei
>
> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
> his argument is logically sound. The problem with @property isn't
> @property, it's D's insistence on optional parens. If paren usage was
> clearly defined then this would be a non-issue. I would like to point
> out that I can't think of another systems/general purpose language that
> has an calling syntax specification as vague and convoluted as D's. C#'s
> is brutally simple. Java's is brutally simple. In C/C++ everything is a
> function or field, so, brutally simple.
>
> Make D's calling syntax simpler, end optional parens!

Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it.

Andrei

On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/13 4:08 PM, Adam Wilson wrote:
>> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>>>> On Thu, 24 Jan 2013 12:51:32 -0500
>>>> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>> No, you merely came up with *some* specific cherry-picked examples that
>>>> sparked *some* debate (with most of the disagreing coming from
>>>> you).
>>>
>>> I simply mentioned three reasons that came to mind.
>>>
>>> Andrei
>>
>> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
>> his argument is logically sound. The problem with @property isn't
>> @property, it's D's insistence on optional parens. If paren usage was
>> clearly defined then this would be a non-issue. I would like to point
>> out that I can't think of another systems/general purpose language that
>> has an calling syntax specification as vague and convoluted as D's. C#'s
>> is brutally simple. Java's is brutally simple. In C/C++ everything is a
>> function or field, so, brutally simple.
>>
>> Make D's calling syntax simpler, end optional parens!
>
> Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it.
>
> Andrei

Then @property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/