EricWF added inline comments.
================ Comment at: include/__functional_base:396 + !is_same<__uncvref_t<_Up>, reference_wrapper>::value + >::type, bool _IsNothrow = noexcept(__bind(_VSTD::declval<_Up>()))> + _LIBCPP_INLINE_VISIBILITY reference_wrapper(_Up&& __u) _NOEXCEPT_(_IsNothrow) ---------------- tcanens wrote: > EricWF wrote: > > tcanens wrote: > > > Is it safe to do this when we are using `_NOEXCEPT_` in the next line? > > It should be. The noexcept condition should only be evaluated *as needed* > > for functions selected by overload resolution. i.e. The noexcept condition > > is only considered on well-formed functions. And this function is only > > well-formed if `_IsNothrow` is well formed. > > > > If `IsNothrow` is ill-formed, it will prevent the functions noexcept > > specifier from ever being evaluated. > My point is that the use of macro-ized `_NOEXCEPT_` suggests that we are > supporting compilers that doesn't have noexcept-specifications. Given that, > can we then use the `noexcept` operator here? Ah, I see! The `_NOEXCEPT_` macro is a holdover from the C++03/C++11 era. This code expects a C++11 conformant compiler, and hence expects `noexcept` to work as a non-buggy feature-complete C++11 construct. Much in the same way the current (and previous) code expects C++11 template aliases, default function template arguments, `decltype`, ect. to work. https://reviews.llvm.org/D40259 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
