Doug Gregor wrote:
> Hi Richard,
>
> On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
>
> > A three line example exhibiting the ICE is:
> >
> > template <unsigned int> struct helper {};
> > template <class T> void check( helper<sizeof(new T)>* );
> > int main() { check<int>(0); }
> >
[...]
>
> This kind of thing came up that the last C++ committee meeting, as
> part of core issue 339:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
>
> Name mangling is part of the problem, but not all of it. There is also
> the issue of what happens when there is an error in the expression
> "new T": is it part of the Substitution Failure Is Not An Error
> (SFINAE) rule, meaning that the function would not enter the overload
> set, or does it trigger an error immediately? That's actually the more
> complicated issue.
Thanks for pointing DR 339 out to me; whilst I had read it
before, it was before the note from the Apr 2007 meeting was
added.
Although the 'compromise proposal' appears to avoid all of
these problems by making my example illegal, it would appear
that N2235 'Generalized Constant Expressions' reintroduces
many of them again. To give an example,
constexpr long foo( long l ) { return l; }
constexpr int foo( int i ) { return i; }
template <int> struct helper {};
template <class T, T I>
void check( helper<sizeof(foo(I))>* );
int main() { check<int>(0); }
In this case, I think we need to mangle the call to (the
candidate set for the unqualified name) foo before carrying
out overload resolution. (And it would be possible to
produce a similar example involving ADL of a type with a
constexpr constructor, we don't necessarily even know the
scope of foo.)
This resolution to DR 339 would remove the need to handle
the mangling of new, new[], delete, delete[], dynamic_cast
and throw, but as constructor calls (i.e. T()), and calls to
possibly-overloaded functions (including member functions
and template functions), and calls to operator() remain,
this seems like very little significant gain.
In any case, it seems hard to justify not compiling (with
-std=c++98) the example quoted at the top of this email as,
notwithstanding DR 339, it's hard to think of an
interpretation of the current standard under which it is
illegal. (Even if this was not the intention.)
Richard Smith
