> I have a laundry list of stuff that I want a fly-on-the-wall perspective. > > First is the discussion of the standardization support macros (so we > don't have to maintain crummy stuff like mfbt/Compiler.h), although that > meeting may have already passed.
The latest proposal for these macros can be found here [1]. The Evolution Working Group (the subgroup of the committee that deals with new language features) accepted the recommendations in that proposal as-is. A minor procedural blemish arose, which is that some C++14 features for which the proposal contained macros have since been removed from C++14, making the proposal technically out of date. As a result, the committee decided that this proposal will not be put into the standard document itself but into a separate document with its own update cadence. I don't believe this should affect whether/how compilers implement these macros. > I'm also interested in seeing proposals for standardization of more > complex attributes that we have static analysis results for--in > particular, the stack class/heap class/etc. annotations, the > must_override analysis, and expanding override/must_override to refer to > nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? > The implementation timeframe of modules is also interesting, since it > appears to be the best-proposed solution to solving various #include > problems. See my previous post about modules. In a nutshell, C++17 at the earliest. > The new threading paradigms (MS is proposing an async/await framework > that basically plays out like the |yield| keyword in JS or python) could > also prove useful for Mozilla. The latest proposal for async/await can be found here [2]. There was also a proposal to standardize the Boost.Coroutines library [3] which provides similar capabilities. Both proposals were presented and discussed in Chicago. I wasn't there for the discussion of [2], but I believe the authors were given feedback and encouraged to prepare an updated proposal. I was there for the discussion of [3], where the primary feedback was that two aspects of the proposal, the proposed communication mechanism between two execution contexts, and the proposed mechanism for launching an independently executing context and for switching contexts, be cleanly separated. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. > Finally, I'm interested in seeing what APIs are going to come out of the > networking and filesystem TS groups, particularly because trying to > track down progress on them is maddening. The latest version of the filesystem proposal can be found here [4]. I believe this is on track to be released as a Technical Specification in the 2014 timeframe. For networking, there are three proposals in the works: URIs [5], IP addresses [6], and byte order [7]. I believe URIs and IP addresses are headed towards one Technical Specification, and byte order towards another. Presumably more will follow that build on these (e.g. TCP socket communication). Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm#recs [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3722.pdf [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3708.pdf [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html [5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3720.html [6] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3603.html [7] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3646.pdf _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
