new DIP5: Properties 2

[Steven Schveighoffer]

On Fri, 31 Jul 2009 16:16:43 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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