On Mon, 03 Aug 2009 21:32:25 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Mon, 03 Aug 2009 11:42:51 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2009-08-03 10:06:23 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
On Mon, 03 Aug 2009 00:27:45 -0400, Nick Sabalausky <a...@a.a> wrote:
"Robert Jacques" <sandf...@jhu.edu> wrote in message
news:op.ux2gvcvi26s...@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
