Sepples 2017: Who needs Rust or Swift?

TL;DR - Bignums, Concepts, Coroutines, Modules, Nested Namespace Definitions and more

So you already know about Concepts, it's essentially like Haskell's type system for C++ templates [1]. There's a lot of interest in coroutines, with a few different proposals [2]. There are two competing proposals for the Module System, one by Microsoft [3] and another by a small team of Clang developers at Google. Microsoft has released their proposal, and Google will be releasing theirs in the next couple of months. Nested namespace definitions [4] removes that ugly wart that has plagued Sepples code forever (now you can do namespace A::B::C { ... }). And then all of the TS libraries that just got standardized last week or will be standardized in a few months will likely be merged into the main language: filesystem library, networking library, parallel containers library, transactional memory library [5]. There are new libraries up for proposal: runtime reflection library, cairo graphics library, etc. There's also an update to the numerics library, with arbitrary precision arithmetic and decimal floating-point, among other things [6][7].

This is why Sepples will still be around 30 years, and languages like Rust and Swift won't stand the test of time.

It's because Sepples already has market capture and the standard's committee is not afraid to adopt competing programming idioms, albeit as slow as they sometimes are. But in the end, it's not about how quickly the language changes, but rather the momentum.

[1] http://www.researchgate.net/profile/Patrik_Jansson/publication/221241323_A_comparison_of_c_concepts_and_haskell_type_classes/links/004635190ab5d29e6b000000.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4465
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html
[5] https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
[6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4038.html
[7] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html

>>15
I'm not on the ISO committee, ask them for the reasons they've been declining modules, concepts and the rest for years.

When a module is imported (e.g., by an #include of one of the module’s headers), the compiler will spawn a second instance of itself [3], with a fresh preprocessing context [4], to parse just the headers in that module. The resulting Abstract Syntax Tree (AST) is then persisted into the binary representation of the module that is then loaded into translation unit where the module import was encountered.

Enjoy your added complexity and incompatibility, as if C++ doesn't have enough already.