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 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.

Right. But they will be most likely part of the standard.  They are
already under TR.  We can't indefinitely pretend that they don't
exist.  I can't believe believe we'll put in infrastructure eluding
the solution, saying that they won't extsit.

| (2) Functions that take a type as an argument aren't functions; they're
|     operators.

Agreed.

|  They'll probably have to be handled roughly like sizeof,

That is what I'm saying.

|     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 will look into the approach you are suggesting with front-end builtins;
| it may be viable.  

I would be more than glad to work with you sort out any issues you
will raise.

| It is, however, syntactically bizarre.  A logical
| extension of your suggestion would be to accept:
| 
|   int fact (unsigned int i) __attribute__((const)) {
|     if (i == 0) return 1;
|     return i * fact(i - 1);
|   }

No, this does not follow.

|   int a[fact(7)];
| 
| That is something we could evaluate at compile-time, but ISO C++ does
| not even allow:
| 
|   int a[false ? f() : 3];

And I'm *not* suggesting to accept that.

| ==
| 
| It is plenty challenging building a correct C++ front end and we are
| nowhere near that yet, despite the massive amounts of effort that we
| have put in over the past several years.

I fully understand your concern (I share them) and I really appreciate
the great work you have done with the new parser.  

That I don't agree with you on this particular issue that does not
mean I don't understand the pains and the points.

[...]

| You can make that harder for me or you can make it easier.

The intent is not to make your work harder.  I offered to sort this
out with you.

| Using, say, CPP macros to implement limits would let us get there
| easily.  We already *do* use CPP macros in <limits> (like
| __FLT_MIN_EXP__); adding a few more is no big deal.

We have been through this before, it proved not to work very well.
Until RTH kindly offered help.

| 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.  (For example, your suggestion
| about how to mangle these things is opposite the philosophy of the
| mangling scheme, which is entirely based on tokenization.)

Maybe part of the misunderstanding comes from the fact you thiing I'm
suggesting to treat everything with __builtin_ as a fonction.  No, that
is not the case.  The BUILT_IN_NORMAL are functions. Those expanded by
the front-end to constant-expressions are constant expressions.

| I would appreciate it if you would drop your objection so that I can
| move forward without controversy.  If, later, you want to reopen the
| question of __builtins in constant-expressions, I will treat your
| suggestion with respect.

I take this to be a sincere deal.  

-- Gaby