On Fri, 31 Jul 2009 16:16:43 -0400, Andrei Alexandrescu
<[email protected]> 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. Of
course, simple conventions such as capitalized types, camel case values,
and so on, are useful and easy to follow. But as soon as complexity of
conventions becomes only a bit higher, their usefulness becomes a
downward step function.
In C++ there were two ways to define a template:
template <class T> ...
and
template <typename T> ...
The existence of "typename" as a keyword has an interesting history of
its own, but in here it was allowed for the reason that T may be any
type, not a class type. So, people thought, it would be less confusing
if people wrote "typename" for type template parameters.
So far so good. When I wrote Modern C++ Design, I decided to make a bold
move and use "typename" in code samples wherever it could have been any
type, and "class" wherever the type was indeed restricted to a class
type. I documented that convention in the introduction and off I went.
The experiment was an unqualified failure. First of all, people got
confused. Then some found actual "bugs" because I used one keyword when
I had promised to use the other. Of course I had bugs - there's plenty
of template code and no automated means to check it! If I could turn
back in time, I'd just use "class" everywhere.
There are similar cases in other communities, probably Perl being a
prime example because it allows most everything to mean something, so
conventions are very important. My reading of the experience on
espousing complex, unchecked, and unused reified conventions? Don't.
Hm... in C++, I don't think that convention is checked at all. For
example, I can do template<class T> and specify int as the T, and
everything compiles.
But in the case of properties only allowed without parens, functions
require parens, you are defining a rule for the compiler. Think of the
parentheses as an extension of the function name, like punctuation.
Like the word "so":
so!
so?
Two different meanings, same word. Analogously to our property
discussion, the compiler can know that one is an exclamation, and one is a
question, but doesn't really know the meaning of "so!" or "so?". It can
enforce that you use a question where a question is needed, and an
exclamation where an exclamation is needed.
But a person sees it immediately and understands the difference in the
implied meaning. The parens-means-function and lack-of-parens-means-field
convention is well well established (except for D) as something that
works, I don't think you would have the same confusion as your
typename/class example.
-Steve
