Re: Invalid code in <limits>

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| --On Wednesday, January 29, 2003 09:29:14 AM +0100 Gabriel Dos Reis
| <gdr@integrable-solutions.net> wrote:
| 
| >
| > We alreay do the same thing for static_cast<>, dynamic_casst<>,
| > reinterpret_cast<> and such.  There is no additional inherent complexity.
| 
| Well, I did write the code and I have spent a fair amount of time thinking
| about it, and I beg to differ. :-)

Well, I also did spend some time coding support for compile-time
reflection (Phil also did a similar work) taking at least both
approaches. In the end, the __builtin_ framework is much more
scalable. 

| You're suggesting treating bulitin functions as keywords, not as functions.

Not all built-ins: Just some.  Specifically, only those marked as being
expanded by the front-end.  There is no conceptual difference between
sizeof(T) and __builtin_constant(T).

| (That's your analogy with static_cast and sizeof.  Those constructs are
| not parsed as function calls at all.)

Only the builtins marked as expanded-by-fronted are treated like
values.  The rest follows the usual function rules treatment.

| If we do that, things will work -- but then we might as well have
| builtin *values* -- rather than builtin *functions*.

Except that you would have myriad of magic keywords, as if we were
to write sizeof_int, sizeof_double, sizeof_xxx.  A much more scalable
framework is to make the "xxx" variant a parameter of sizeof.

| That's what I'm suggesting.

What I'm saying is that we have several instances of the same problem
spread out through the compiler.  Multiplying magic keyword does not
scale. On the long run, it just makes maintance and evolution un-easy.
Rather, we should set a scalable framework from the outset.
If, for example, we decide to support "long lond double", we don't
need to put in another magic keyword in the grammar.  We just need to
accept the type-id in the constant-folder.

-- Gaby