Boost logo

Boost :

From: Juan Carlos Arevalo-Baeza (jcab.lists_at_[hidden])
Date: 2002-02-23 03:21:40

On Sat, 23 Feb 2002 01:38:03 +0800, joel de guzman wrote:

>Bottom line is: expressiveness matters!

   That is _exactly_ what we're talking about. Expressivity is an important thing to keep in mind when programming libraries. That would be, for example, one reason for allowing named template parameter assignment, which would allow users of a library to specify individual policies separately. Expressivity.

   Now, the problem with added expressivity would be when it introduces ambiguity. Excess of ambiguity is really bad, even if it's resolved in documentation. But I don't see the problem with "auto". As long as a new language construct can be translated by the compiler into simpler forms (the "kernel" of the language, so to speak), it won't introduce any new ambiguities.

   For example, the "auto" variable definitions discussed here can be translated as in:

auto <var> = <expression>;


typeof(<expression>) <var> = <expression>;

   Then, if you define "typeof" as doing the same type deductions that you'd get in a function parameter, you could see "auto" as syntactic sugar for the language, which is what expressivity is all about. Otherwise, you'd force programmers to either replicate the expression (as in the substitution above) or use less efficient constructs, like it happens in Spirit.

   If you see it this way, too, compiler support becomes easy: they can just first do the substitutions on the AST, and then compile the result.

   BTW: I've reading the discussions about the problems with using the "auto" keyword, or any of the other storage specifiers. Leaving aside the question of wether overloading keywords like this is good or bad, hasn't anybody thought of "default", "new" or "typename"? All those would be completely non-ambiguous when parsed as:

<keyword> <ident> "=" <expression> ";"

   I'd choose "default" myself.

email: jcab_at_[hidden]
ICQ: 10913692 @WORK: 101728263

Boost list run by bdawes at, gregod at, cpdaniel at, john at