Re: Invalid code in <limits>

[Phil Edwards <phil at jaj dot com>]

On Tue, Jan 28, 2003 at 09:34:42PM -0800, Mark Mitchell wrote:
> Syntactically, a function call cannot appear in a constant-expression,
> which is what is required for a static member initializer.  

Oh crumbs.

I'm almost finished with implementing type traits in the compiler and
library:

    http://www.devphil.com/~pme/reflection.html

The guiding principle behind this particular implementation is to add as
few magic keywords to the grammar as possible; the secondary (resultant)
principle is to do the rest of the compiler magic as __builtin_xxx functions,
and large parts in userland code in the library.

Right now I have /one/ additional magic keyword.  And lots of integral-
constant-expressions containing a __builtin_foo() call.


> Theoretically, we could try to exempt built-ins, but it is going to
> get very complicated to try to get that right in the presence of
> templates/dependent names/two-phase name lookup.  We really don't want
> to go there.

At one point, when adding another __builtin, I forgot to add the code to
recognize and expand (collapse?) it to an integral expression.  And the
compiler already stopped and diagnosed it (trying to instantiate a template
with a non-i.c.e. as a parameter).  For a static member initializer we're
probably not diagnosing it, since you said you were going to add code to
do this.

Perhaps we should try to evaluate and fold the expression before diagnosing
the presence of a function call?

Perhaps all __builtin_xxx functions which are capable of being in an
i.c.e. should simply have a certain attribute on them?  The compiler sees

    const static int foo = ......  fn() ...

and checks for the attribute on fn; if not there, it's an error.


Adding many magic keywords scares me.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002