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

[Richard Smith]

On Tue, Nov 12, 2013 at 5:06 PM, Howard Hinnant <howard.hinnant at gmail.com>wrote:

> 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.
>

By using a using-declaration in std, and keeping the symbols in namespace
'std::experimental', there is no ABI break from old libc++ to new libc++;
the ABI does not change. Interoperating with other standard libraries will
require cross-vendor agreement on where the symbol goes; if they are also
shipping TSs, they will have the exact same ABI breakage issue, and the
same approach will work for them too.

I think the question is, do we want to have the wrong symbol (and the wrong
containing namespace) in the longer term? (Also, if so, is this a valid
implementation technique for the standard library? It's detectable by (for
instance) ADL.)

But I don't think this is something we need to worry about for now,
especially if we're happy to have a minor ABI break if/when optional
becomes part of the standard.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131112/5335da8c/attachment.html>