[libcxx][PATCH] N3672 - optional

[Richard Smith]

"::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 <hhinnant at apple.com> wrote:

> Please review, thanks.
>
> Howard
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130829/66bfd16f/attachment.html>