Invalid code in <limits>

[Phil Edwards]

On Wed, Jan 29, 2003 at 09:43:30AM -0800, Mark Mitchell wrote:
> --On Wednesday, January 29, 2003 06:23:04 PM +0100 Gabriel Dos Reis 
> <gdr@integrable-solutions.net> wrote:
> 
> >How would you implement compiler support for type-traits?  Surely, you
> >won't propose a new keyword for each new type-id.
> 
> (1) type-traits isn't yet part of the standard.

No, but I'm about done implementing it.  WG21 (correctly) doesn't want to
accept these proposals without more experience with existing implementations.
So another existing implementation is what I want to offer.

And all over the place I'm instantiating things like

    template <bool b>
    struct a_certain_template { ...};

    ...

    a_certain_template < __builtin_foo(x) == __a_value >


> (2) Functions that take a type as an argument aren't functions; they're
>    operators.  They'll probably have to be handled roughly like sizeof,
>    but that's not what we're dealing with in limits.  I have no idea
>    why we'd need a new keyword for each type-id; there's a perfect good
>    syntax for type-ids already.

I think, when Gaby spoke of "a new keyword for each new type-id," he might
have been referring to each of the new reflection types, e.g., is_POD,
is_const, and so forth.  And I think we can all agree that implementing
them with

    template <typename T>
    struct is_foo
    {
        static const bool value = __builtin_is_foo(T);
    };

for each property/trait 'foo' would be a Bad Way To Go.  That's a /lot/
of additional builtin keyword/operators.


> I will look into the approach you are suggesting with front-end builtins;
> it may be viable.  It is, however, syntactically bizarre.

I'm using BUILT_IN_NORMAL, not BUILT_IN_FRONTEND, to do this.  (Because the
NORMAL ones get expanded in expand_tree_builtin.  The others, including the
front-end builtins, have to expand to rtl, not trees.  Type traits and other
reflection machinery has to take place long before we get to rtl generation.)


> If someone wants to support builtins in the constant-expressions,
> fine -- but I would much rather we do that later and separately.  We
> don't need to do it now, and, like any extension, it's one that needs
> to be thought through very carefully.

The only extension of this nature that we need is what's already in the
existing framework; nothing extra in this regard is being requested.
(At least, not yet, and not by me.)  If you remove it from the trunk,
we can simply keep it in the cxx-reflection-branch for the time being.


> (For example, your suggestion
> about how to mangle these things is opposite the philosophy of the
> mangling scheme, which is entirely based on tokenization.)

Possibly I'm missing something completely; if so, it's something which
hasn't yet shown up /at all/ in my reflection work:  why do we need to
mangle any kind of expression which /must/ be collapsed into an i.c.e.
for theprogram to be correct?  None of these names appear in output assembly;
if they do, that's a serious error.


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