property syntax strawman

[Robert Jacques]

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.