<p dir="ltr">For cases like the base library that do require that kind of absolute compatibility maybe the best solution is to just not include any of the experimental features. If I understand David correctly the one in ports could include the experimental features for the users that want it.</p>
<div class="gmail_quote">On Jul 22, 2015 8:40 PM, "Marshall Clow" <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span>On Wed, Jul 22, 2015 at 1:55 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Marshall,<br><br>For some background: We ship libc++ in both the base system and in ports.  Some things use the version in ports, but we expect it to be a drop-in replacement (i.e. if something links libc++ and works with the one in base, then it must also work with the one in ports).  Mostly the one in ports is used by things that require C++14 on systems that ship a libc++ that’s C++11-only.<br></blockquote><div><br></div></span><div>OK - thanks for the background.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If we’re going to ship them in the FreeBSD base system at all, then we need to be able to guarantee ABI (and API) compatibility over the lifetime of a FreeBSD release (5 years).  This means that we’d want to make sure, at the very least, they they’re in versioned namespaces and that people can opt in to newer ones if they want, but still have the older ones available.<br></blockquote><div><br></div></span><div>Yeah, I can't do that for the TSes.</div><div><br></div><div>They're "experimental". That means that they can (and will) change - and the changes are not under my control. </div><div><br></div><div>I (and the others who work on libc++) try very hard to maintain ABI compatibility for the things in the standard; and I think we do a pretty good job. But it's a fair amount of work, and I don't want to take on the burden of doing that for stuff that the committee has declared as "not final".<br></div><div><br></div><div>That's one of the reasons that I started this email thread - to figure out a good way to hand this.</div><div><div><img src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><span><font color="#888888"><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">-- Marshall</div><div><br></div></font></span></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div>