[cfe-dev] integer constant expression oh my!

[Eli Friedman]

On Mon, Nov 17, 2008 at 12:43 PM, Doug Gregor <doug.gregor at gmail.com> wrote:
> On Mon, Nov 17, 2008 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Nov 17, 2008 at 10:47 AM, Doug Gregor <doug.gregor at gmail.com> wrote:
>>> We have to instantiate the correct template *declaration* as part of
>>> type-checking. We don't have to instantiation the template
>>> *definition* until we try to evaluate the value of the expression.
>>
>> Right... but I'm pretty sure we're still going to instantiate it
>> before we try to evaluate the value of the expression.  Take the
>> following program:
>>
>> template <int i> int f(int (*a)[-i]) {
>>  int b[i]; return 2;
>> }
>> int b() {return 0 ? f<-1>(0) : 0;}
>>
>> I'm pretty sure we're still supposed to emit a diagnostic (at the very
>> least, g++ does).
>
> Yes, it emits a diagnostic. However, the diagnostic actually comes
> later on, since GCC (like many compilers) delays the instantiation of
> function templates until the end of the translation unit. (Or later,
> if one is using a prelinker-based approach like the one EDG supports).
>
>>  In -fsyntax-only mode, there isn't anything after
>> Sema; therefore, Sema has to force the instantiation of the definition
>> at some point.  The only reasonable place to force the instantiation
>> of the definition is when Sema processes the call to f<-1>.  This is
>> before the call exists in the AST, so the template will be
>> instantiated before we might want to evaluate it.
>
> If you add a bit of bogus code that doesn't involve templates to the
> end of your example and run it through GCC, you'll see that the error
> message for the problem inside f<-1> comes *after* the error messages
> for that bogus code. That's the delay in performing the instantiation.
> It can be helpful: for one, it means that error messages due to failed
> instantiations of function templates don't come from inside the bodies
> of other functions that just happen to use the broken template.

Hmmm, interesting.

Actually, it looks like C++0x is making some significant changes to
the definitions of constant expressions. I think we'll just have to
wait until C++0x stabilizes a bit more, then figure out what's going
on... the current draft looks convenient to implement, but it seems
like they didn't think through the effect of the changes on
floating-point arithmetic, and I'm not sure it leaves constexpr as
usable as they might want.

>> I don't really want to attempt to drag this out before we actually
>> have a plan for how we're going to implement templates, but if there
>> really is an architectural issue here, I would prefer to solve it
>> sooner rather than later.
>
> I don't think it's a major architectural issue, I just think that
> we'll eventually have to move the evaluation code to Sema to deal with
> constexpr function templates.

I guess we'll just have to wait until we get there... C++ is a
horribly complicated language, and it's not getting better in that
respect.

-Eli