<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 12, 2013, at 3:33 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>I assume the intent is to implement this paper:</div><div><br></div><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html</a><br>
<div><br></div><div>So, assuming that include/experimental/optional was copied from include/optional (the diff doesn't say where the 'old' lines come from here)…</div></div></blockquote><div><br></div>Yes.</div><div><br><blockquote type="cite"><div dir="ltr"><div><div>You included the inline namespace in the library synopsis comment; it shouldn't be there.</div></div></div></blockquote><div><br></div>Ok.</div><div><br><blockquote type="cite"><div dir="ltr"><div>
<div>bad_optional_access should be in namespace std::experimental, not in namespace std.</div></div></div></blockquote><div><br></div>I went back and forth about that. I agree - it _should_ be there.</div><div><br></div><div>However:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>The destructor for bad_optional_access lives in libc++.dylib. (due to a peculiarity in the Itanium ABI).</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div><div>For headers in include/support, the source files are in src/support. Should optional.cpp be moved to src/experimental/optional.cpp?</div></div></div></blockquote><div><br></div><div>Good question. </div><div>Header folder structure is an interface.</div><div>Source folder structure is not.</div><div><br></div><div>I don't see that this is necessary; but if other people really want it, I have no objection to changing it.</div><br><blockquote type="cite"><div dir="ltr"><div>
</div><div>Bikeshedding on the name __TSLibraryFundamentals:</div><div> * Should this contain a version number? We may want an ABI break at some point, and it might be nicer to have always had the version number in the name.</div></div></blockquote><div><br></div>Yes! Crap - there was supposed to be a _v1 on the end of that.</div><div><br><blockquote type="cite"><div dir="ltr">
<div> * Other library-internal names in libc++ seem to use __lower_case_names</div><div>Maybe __library_fundamentals_1?</div></div></blockquote><div><br></div>That's fine - I can live with either one.</div><div><br><blockquote type="cite"><div dir="ltr"><div>Somewhat related to versioning, do we want to provide some way for people to opt into/out of individual TSes? For instance, I might want to test that my code compiles as standard C++14 (with no TSes), or to use the fundamentals TS but not the filesystem TS, since the latter has security issues.</div></div></blockquote><div><br></div>The easy answer is not to include <filesystem></div><div>The other answer is that's why I created the __TSLibraryFundamentals namespace.</div><div>People can hoist just one TS worth of names with "using namespace std::experimental:: __TSLibraryFundamentals;" (or whatever)</div><div><br><blockquote type="cite"><div dir="ltr">
<div>How will we handle TSes that affect existing headers, rather than adding new ones? (Do we have any of those yet?) </div></div></blockquote><div><br></div><div><div>Jeffrey should weigh in here, but I think that current plan is to not change existing headers.</div><div><br></div></div><blockquote type="cite"><div dir="ltr"><div>How will we handle TSes that need both frontend and library changes, such as the array extensions TS? It might be nice to have a single flag to the compiler ("-fsomething" or "-std=c++14+fundamentals+arrays" or something) to enable TSes for language and library as appropriate. Any ideas?</div></div></blockquote><div><br></div><div>No more than you've just said.</div><div>For library-only TSes (Library Fundamentals, Networking, Filesystem), I don't think there needs to be anything done for the compiler.</div><div>For Arrays, I think a "-f ArrayTS" or something like that would work, (that flag should only work if -std=c++1y or later).</div><div><br></div></div><div>Thanks!</div><div><br></div><div>-- Marshall</div><div><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 12, 2013 at 1:48 PM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</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">Along with C++14, the standard committee is working on several "Technical Specifications", designed to bring features that for one reason or another weren't able to be in C++14 to people before the next version of the standard (C++17??). Those of you who remember TR1 (from about 2005) - this is a similar process under a new name.<br>
<br>
There are several being worked on:<br>
* Library Fundamentals<br>
* Arrays of Runtime Bound<br>
* Networking<br>
* Concepts<br>
* Filesystem<br>
<br>
This patch takes the implementation of <optional> that Howard wrote and committed into libc++ (before the committee removed the feature from C++14), and moves it into the new "experimental" area, which is where these TSes will live until they are enshrined in a future version of the standard.<br>
<br>
That area can be described as:<br>
namespace std::experimental (feel free to alias this to something shorter in your code)<br>
files live in the "experimental/" directory.<br>
<br>
If you're already using the <optional> in libc++, you'll have to change your code to:<br>
#include <experimental/optional><br>
and<br>
std::experimental::optional<T><br>
<br>
It's a big patch, but it's just renaming things; if I actually changed some code, then I did it wrong.<br>
<br>
-- Marshall<br>
<br>
Marshall Clow Idio Software <mailto:<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>><br>
<br>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br>
-- Yu Suzuki<br>
<br>
<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; ">-- Marshall<br><br>Marshall Clow Idio Software <<a href="mailto:mclow.lists@gmail.com">mailto:mclow.lists@gmail.com</a>><br><br>A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br> -- Yu Suzuki</span>
</div>
<br></body></html>