[PATCH] Move optional into the experimental namespace (first bit of the TSes)

[Howard Hinnant]

On Nov 12, 2013, at 7:53 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, Nov 12, 2013 at 4:11 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> On Nov 12, 2013, at 6:56 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
> >> bad_optional_access should be in namespace std::experimental, not in namespace std.
> >
> > I went back and forth about that. I agree - it _should_ be there.
> >
> > However:
> >       The destructor for bad_optional_access lives in libc++.dylib. (due to a peculiarity in the Itanium ABI).
> >       If I put bad_optional_access in namespace std, then users do not need a new dylib when optional moves from std::experimental to std.
> 
> I vote std::experimental.  We don't want to commit a symbol to the permanent std:: abi until the committee says so.  But if someone is depending on a std::experimental symbol, we can more easily yank it.  It is unfortunate that if/when bad_optional_access is standardized that it won't be supported previous to a certain libc++ version.  But that seems like the least of the two evils.
> 
> There's a third evil we could consider: keep bad_optional_access in std::experimental and add a using declaration for it in namespace std. But I guess we don't need to think about this until optional gets standardized.

The issue here is really about the mangling of the bad_optional_access symbols, especially the type_info.  In order to have the *potential* to interoperate with other std::libs, or with future libc++ incompatible ABI versions, the ABI/mangling of the bad_optional_access type_info needs to be both stable and predictable.  By interoperate I mean: the ability to throw this exception across dylib boundaries where the dylibs may link to different std::libs.  That means that the "key function" of std::bad_optional_access must be defined in namespace std.  An inline, or using declaration will only fix the API, not the ABI.

So there will be a definite ABI breakage between std::experimental::bad_optional_access and std::bad_optional_access for this reason alone.  But that's why we call it experimental. :-)  That being said, libc++ has a policy that all std-defined exceptions types have a forever-stable ABI, and that ABI is defined by gcc-4.2.  std::experimental-defined exception types are exempt from this policy.

Howard