property syntax strawman

[Robert Jacques]

On Mon, 03 Aug 2009 21:32:25 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:
> On Mon, 03 Aug 2009 11:42:51 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
>
>> On 2009-08-03 10:06:23 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>>
>>> On Mon, 03 Aug 2009 00:27:45 -0400, Nick Sabalausky <a at a.a> wrote:
>>>
>>>> "Robert Jacques" <sandford at jhu.edu> wrote in message
>>>> news:op.ux2gvcvi26stm6 at sandford.myhome.westell.com...
>>>>>  I agree 1) is an issue, but I view it as a corner case. (I use  
>>>>> zero/one
>>>>> arg functions all the time and make use of the 'property' syntax left
>>>>> right and center, but I've never run into the opCall problem) It  
>>>>> would  be
>>>>> nice if it were fixed, but we may be cutting off the nose to spite  
>>>>> the
>>>>> face, as it were. (Or alternatively, taking the scientific instead of
>>>>> engineering approach)
>>>>>
>>>>  It'll become a major PITA when D gets used for heavy  
>>>> functional-style  stuff.
>>>  Maybe. But how often will people return zero-argument opCalls  
>>> (function  pointers/delegates/structs) from zero-argument functions?  
>>> (i.e. how often  do you run into this today?)
>>
>> The compiler isn't as smart as you think. This doesn't compile, it  
>> requires an empty pair of parenthesis:
>>
>> 	void delegate(int) func();
>>
>> 	func(1);
>>
>> And I somewhat doubt it should be smart enough for this, because if you  
>> then add a overloaded function "func" that takes an int you're silently  
>> chaning the meaning of the code.
>>
>> Solve this for fun:
>>
>> 	void delegate() func(int);
>> 	void delegate(int) func();
>>
>> 	func(1); // which one?
>>
>
> Ah. Thank you for the informative post. That is a fairly big deficiency.  
> However, isn't that really a bug? There's a similar one with ref return  
> properties. According to the spec, there's nothing (I think) preventing  
> DMD from doing the right thing.
>
> As for your example, 'void delegate() func(int);' would end up being  
> called. But it's pretty obvious 'void delegate(int) func();' was meant.  
> This particular example looks very pathological, if both funcs are part  
> of the same module. Ultimately, this is just another form of function  
> hijacking. Detecting this would require all combinations of call  
> variations to enter into the lookup tree, but from there it's trivial to  
> detect a collision, and issue an error. That would work for both out of  
> module and in module double definitions. I don't know how difficult that  
> is for the compiler, but it sounds fairly straight-forward.

I just found the related bugs in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=2409
http://d.puremagic.com/issues/show_bug.cgi?id=2152
http://d.puremagic.com/issues/show_bug.cgi?id=2159