On Sunday, December 02, 2012 01:16:40 Andrej Mitrovic wrote: > On 11/20/12, Jonathan M Davis <[email protected]> wrote: > > I suspect that the > > best that we can hope for at this point is for lax property enforcement - > > that is that it's enforced that @property functions are used as properties > > but there is no enforcement that non-@property functions be called with > > parens. > Here's a good reason why the latter isn't the best idea: > http://d.puremagic.com/issues/show_bug.cgi?id=2159 > > The reporter made the mistake of issuing a function call instead of > taking an address of a function, which in turn invoked a different > function overload with the temporary result.
I'd _love_ to make it illegal to call non-property functions without parens, and there are definitely folks around here who agree with me, including some on the Phobos dev team (e.g. Steven has always agreed with me when this has come up), but there are enough folks around here here who like to call functions without parens - especially with UFCS and templated functions like map or filter - that I don't think that that's going to fly at this point. Maybe if Andrei agreed it could happen, but he's hated the idea of @property practically from the get-go, and when you combine that with the facts that strengthening @property enforcement as originally intended would break a lot of code at this point and that Walter absolutely hates breaking people's code for pratically any reason whatsoever, I expect that Walter would be against it too. And with both of them against it, it just wouldn't happen. The workaround for the bug in question is to not overload functions that take function pointers with an overload that takes something other than a function pointer or delegate. Even that's not perfect, because a function could return a function pointer or delegate, but at this point, I just don't see Andrei and Walter agreeing to the level of property enforcement required to stop it, even if they had agreed to it in the past. UFCS seems to be the feature that puts the nail in the coffin of that idea, because people don't want to do stuff like range.filter!(a => a.func() < 2)() but would rather do range.filter!(a => a.func() < 2). - Jonathan M Davis
