equivariant functions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Oct 13 17:47:29 PDT 2008


Robert Fraser wrote:
> Just read this paper by Herb Sutter last night:
> 
> http://www.gotw.ca/publications/C++CLIRationale.pdf
> 
> In particular, the Bjarne Stroustrup quote is quite poignant:
> 
> ""
> My experience is that people are addicted to keywords for introducing 
> concepts to the point where a concept  that doesn’t  have its own 
> keyword is surprisingly  hard to  teach. This effect is more important 
> and deep-rooted  than  people’s  vocally expressed  dislike for new 
> keywords.  Given a choice and time to consider, people invariably choose 
> the new keyword over a clever workaround.
>       — B. Stroustrup (D&E, p. 119)
> ""

I agree. I'd also add that that could backfire as well. "class" being 
essentially the same deal as "struct" with a different hat has wasted a 
perfect opportunity to create a really useful distinct concept. Right 
now it's no more than a source of embarrassment. "typename" is a shame 
begotten by another shame, the angle brackets. "explicit" is an 
expensive fix for a minor problem, bringing along with it new oddities 
and corner-case behaviors that had to be defined.

> And Herb himself:
> 
> ""
> When a language feature is necessary, programmers strongly
> prefer keywords. Normally, all C++ keywords  are also re-
> served words, and taking a new one would break code that
> is already using that word as an identifier (e.g., as a type or
> variable name).
> 
> C++/CLI avoids adding reserved words so as to preserve the
> goal of having pure extensions, but it also recognizes that
> programmers expect keywords. C++/CLI balances  these re-
> quirements by adding keywords where most are not reserved
> words and so do not conflict with user identifiers.
> ""

I agree. When considering keyword addition, I think we all should think 
more about adding contextual keywords, which in the grand D tradition 
are usually defined as keyword(contextual_keyword).


Andrei



More information about the Digitalmars-d mailing list