@property - take it behind the woodshed and shoot it?

[Adam Wilson]

On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara <k.hara.pg at gmail.com> wrote:

> 2013/1/25 Adam Wilson <flyboynw at gmail.com>
>
>> On Thu, 24 Jan 2013 15:04:20 -0800, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>  On 01/24/2013 10:24 PM, Adam Wilson wrote:
>>>
>>>> ...
>>>>
>>>> All I can say is that in this case even with UFCS C# enforces parens
>>>> because it's syntactically clear. Yes, it might be slightly annoying  
>>>> to
>>>> have to type the (), but that's how you define a function in every  
>>>> other
>>>> language. A shortcut with side-effects isn't a short-cut, it's a bug
>>>> factory.
>>>>
>>>
>>> It is not a shortcut, it is a formatting option, and using it does not
>>> have side effects.
>>>
>>>  And to be honest, once the language spec settles down tools
>>>> like ReSharper/VisualAssist/etc. can take care of the extra parens.
>>>>
>>>
>>> Tools will be configurable to highlight certain constructs anyway.
>>>
>>>  I hand type a small fraction of the parens that actually appear in my  
>>> C#
>>>> code.
>>>>
>>>>
>>> It is about reading, not typing.
>>>
>>>
>>>
>> *sigh* ideally yes, it's just a formating option. The problem is that
>> right now, it's NOT.
>>
>> Consider:
>>
>> module main;
>>
>> import std.stdio;
>>
>>
>> struct Thing {
>>         int foo() { return 0; } // method
>>         int bar; // data field
>>         @property int baz() { return 0; } // data field
>> }
>>
>> int main(string[] argv)
>> {
>>         writeln("Hello D-World!");
>>         return 0;
>>
>>         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(); // is this a function or a property? oops have to go  
>> look
>> at the code.
>> }
>>
>> But what happens if t.baz returns a delegate?
>>
>> Because properties, which conceptually have nothing to do with  
>> functions,
>> are implemented as functions they have the same optional parens rules as
>> functions. The problem is that they aren't intended to be used as  
>> functions
>> so in the case of delegate, you get massive explosions in the compiler.  
>> For
>> something that should be straight-forward. If t.baz is a delegate than
>> t.baz() should call the DELEGATE, but it doesn't...
>>
>> Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs.
>
>
> 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

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