[PATCH] [libc++] Try and prevent evaluation of `is_default_constructible` on tuples default constructor if it is not needed.

[Richard Smith]

On Wed, Feb 11, 2015 at 3:45 PM, Louis Dionne <ldionne.2 at gmail.com> wrote:

> The faulty code was mine. With the `pair` example, it is clear that all
> those `is_default_constructible<T>` are instantiated even when the default
> constructor is not. I think my intention when writing `Dummy &&
> is_default_constructible<_Tp>::value` was to delay the instantiation of
> `is_default_constructible<_Tp>` as a compile-time optimization (which it
> fails to do), but not for correctness purposes.
>
> However, looking at
> http://en.cppreference.com/w/cpp/types/is_default_constructible and then
> http://en.cppreference.com/w/cpp/concept/DefaultConstructible, I am
> unsure whether instantiating `is_default_constructible<_Tp>` should cause a
> hard error at all. If instantiating the default constructor in the
> expression
>
>
>   _Tp x{}
>
> causes a compile-time error, should `is_default_constructible<_Tp>::value`
> be false or trigger a compile-time error?
>
> Summary: At a glance, the fix seems correct in that it will properly delay
> the instantiation of the `is_default_constructible<_Tp>`s. However, is
> there a bug in `is_default_constructible`?
>

The issue is that it results in instantiation of decltype( _Tp()), and
because the selected constructor is constexpr, it is eagerly instantiated
(and that instantiation fails) even though it is not actually invoked here.
(That in turn is necessary to support ridiculous things like
"decltype(char{_Tp().n})" whose validity depends on whether the result of
constant-evaluating _Tp().n gives a value that fits within a 'char'.)

It's not yet completely clear whether Clang's (and GCC's) behavior is right
here; there's an active core issue on how to handle this case.


> http://reviews.llvm.org/D7569
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150211/5ec5990a/attachment.html>