[PATCH] D6762: [libcxx] Add <experimental/any> v2.

[Marshall Clow]

mclow.lists added inline comments.

================
Comment at: src/any.cpp:18
@@ +17,3 @@
+}
+
+_LIBCPP_END_NAMESPACE_LFTS
----------------
EricWF wrote:
> EricWF wrote:
> > mclow.lists wrote:
> > > Because of arcane packaging issues, we put the exception classes in an unversioned namespace and the destructors in the the dylib as well.   See <optional> implementation.
> > > 
> > >       _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL
> > >       const char* bad_any_cast::what() const _NOEXCEPT
> > >       {
> > >           return "bad any cast";
> > >       }
> > > 
> > >       bad_any_cast::~ bad_any_cast() _NOEXCEPT {}
> > >       _LIBCPP_END_NAMESPACE_EXPERIMENTAL
> > > 
> > > This will require a change in the header file as well
> > I don't think this makes sense for things in the LFTS. Unlike `std::__1` which is an implementation detail, the LFTS explicitly puts the exceptions in the inline namespace and putting `bad_any_cast` in `std::experimental` is non-conforming.
> > 
> > AFAIK there are two reasons we generally put exceptions in namespace `std` directly and not `std::__1` 
> > 
> > 1. ABI stability. When `std::__1` changes to `std::__2` the exception types are still compatible.
> > 2. libstdc++ compatibility. libc++'s exceptions should be ABI compatible with GCC's when possible.
> > 
> > ABI stability doesn't really make sense when thinking about TS's because they are not meant to be stable.
> > 
> > Also If we put `bad_any_cast` outside of `fundamentals_v1` we lose exception compatibility with libstdc++.
> > 
> > @mclow.lists: Do you still want to make this change?
> libstdc++ actually puts `bad_any_cast` in `std::experimental::fundamentals_v1::__7` so we aren't going to get libstdc++ compatibility regardless.
> 
so libstdc++ compatibility doesn't matter. 

I guess I'm mildly in favor of putting it into namespace `std::experimental` - but it's not a deal-breaker for me.  I'm more interested in consistency;  we should make sure that `bad_optional_access` and `bad_any_cast` are in the same namespace.


http://reviews.llvm.org/D6762