<div dir="ltr">On Tue, Nov 12, 2013 at 5:06 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Nov 12, 2013, at 7:53 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>

<br>
> On Tue, Nov 12, 2013 at 4:11 PM, Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>> wrote:<br>
> On Nov 12, 2013, at 6:56 PM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>> wrote:<br>
><br>
> >> bad_optional_access should be in namespace std::experimental, not in namespace std.<br>
> ><br>
> > I went back and forth about that. I agree - it _should_ be there.<br>
> ><br>
> > However:<br>
> >       The destructor for bad_optional_access lives in libc++.dylib. (due to a peculiarity in the Itanium ABI).<br>
> >       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.<br>
><br>
> 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.<br>

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

<br>
</div></div>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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.</blockquote>
</div></div></div>