On Fri, Jul 31, 2009 at 10:09 PM, Andrei Alexandrescu<seewebsiteforem...@erdani.org> wrote: > Benji Smith wrote: >> >> Andrei Alexandrescu wrote: >>> >>> Steven Schveighoffer wrote: >>>> >>>> So to sum up, with this feature lack of parentheses would imply no >>>> action, but would not be enforced. However, it would be considered >>>> incorrect logic if the rule was not followed, similar to naming your >>>> functions something other than what they do. >>> >>> I am leery of such a feature. It essentially introduces a way to define >>> conventions that are in no way useful to, or checked by, language rules. In >>> my experience this has been a bad idea more often than not. >> >> Like it or not, that's exactly the situation we have now, with the >> (sometimes)-optional parentheses. Some people are using a convention of >> never using the optional parens. Other people use the parens only when a >> function an action, and avoiding them otherwise. And some other people (like >> me) always use the parens. >> >> So the clusterfuck of unenforceable and useless conventions is already >> here. Here's my suggestions: if you think putting parentheses on a no-arg >> function is stupid, then it should be a syntax error for them to exist. That >> wouldn't be my first choice, but it'd be a thousand times better than the >> situation with optional parens. >> >> --benji > > I agree that it's not good to have two ways of doing the same thing. Now > think of it for a second: a full-blown language feature has been proposed to > not fix that, but reify it.
Not quite right. We *already* have a language feature that reifies it. The proposal is to adjust that feature to *remove* the arbitrary choice from the caller and give the choice to the API designer, which is a much more sensible place for it to reside. The logical conclusion if you stick by that argument is that we should remove the optional () rule and go back to the simpler C/C++ rule. --bb
