"::new(&__null_state_) value_type(...)" seems a bit strange (and I'm concerned that it would probably lead to undefined behavior, if we actually had comprehensible rules for unions...). Maybe "::new(addressof(__val_)) value_type(...)"?
Do you need the (in_place_t, initializer_list, Args...) constructor in __optional_storage? The (in_place_t, Args...) constructor looks like it would appropriately handle initializer_list construction, since the optional constructor will have already selected the right argument type. Oh god, there's overload sets for operator->(), operator*(), value(), and value_or(), where one is constexpr and the other isn't. That's awful (and unnecessary in C++14). =( Is there an LWG issue on that? (You can also use __builtin_addressof in recent versions of Clang to make these constexpr whether or not there is an overloaded operator&, but I don't think the current standard actually allows you to do that...) __has_operator_addressof_imp is not robust against operator&() returning a type with an overloaded operator,(), and will trigger the instantiation of the return type of operator&() (which might fail) when looking for such an operator,(). I suggest following the pattern in __is_constructible_test: static auto __test(_Up* __u) -> typename __select_2nd<decltype(__u->operator&()), true_type>::type; Looks like __is_assignable_test has the same bug, FWIW. On Thu, Aug 29, 2013 at 2:17 PM, Howard Hinnant <[email protected]> wrote: > Please review, thanks. > > Howard > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
