On Wed, Feb 11, 2015 at 3:45 PM, Louis Dionne <[email protected]> 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/ > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
