<div dir="ltr"><div>There's a lot of changes coming to the standard library. The standards committee is looking at (and in several cases, approved) proposals for networking, ranges, concurrency, parallelism, transactional memory, file-system, and concepts. Each of these will require changes to the standard library.</div><div><br></div><div>Some (most) of them are "Technical Specifications", which means that they are not officially part of the standard. The goal for then TS-es is to give implementors and users experience with the features, so that the standards committee can get feedback about when (and if) they should be adopted into the standard.</div><div><br></div><div>The other part of this is that the TS-es *change*. People give feedback, and the committee updates the proposals, and the code changes. There's a reason that most of them live in the namespace "std::experimental".</div><div><br></div><div>Some of these proposals can be implemented as templates that live in a header file, and require no new functionality from the dynamic library libc++.dylib. Most of them, however, have a separately compiled part, and that is the purpose of this email.</div><div><br></div><div>How should these parts be delivered? </div><div><br></div><div>The choices, I see, are:</div><div>* As part of the libc++ dynamic library.</div><div>* As a set of statically linkable object libraries.</div><div>* As a set of dynamic libraries.</div><div>* Something else</div><div><br></div><div>The first option, it seems to me, is a non-starter. There are some systems (FreeSBD, Mac OS X) that ship libc++ as the system runtime library, and replacing that library (on the fly) is a easy way to render your system inoperative. </div><div><br></div><div>On the other hand, having the vendors ship updated libraries a few times/year (or less) is a great way to slow down the entire process.</div><div><br></div><div>So, I'm asking - what do people want?  (and why)</div><div><br></div><div>-- Marshall</div><div><br></div></div>