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

https://www.youtube.com/watch?v=ND-TuW0KIgg

C++ is the Common Lisp of our time.

why the fuck would anyone do anything in C++ ever, fuck off

It's not lisp, so it's shit.

That's great but, can sepples remove most of the shit in the language for the next release

BIG NUMBERS, BRO, BIG NUMBERS!

>>5
Clojure is not a LISP.

Dead dogs don't have a lisp.

>>9
You can't teach dead dogs dumb jokes.

OP, they won't approve any of this stuff for the same reason they didn't approve any of it before: they've got decades and gigalines of code worth of backwards compatibility stifling their every move.

That's why we need new languages, not old shit-monsters like C++ (which must and will die). Not that Rust or Swift are any good, of course.

Nim is the better Rust:

http://hookrace.net/blog/what-is-special-about-nim/

Lol, Rust actually takes longer to compile than Haskell.

>>11
The C++ WG isn't known for its restraint.

Modules are about 20 years overdue at this point, however; I would happily of the pointless library additions that have been proposed recently to be rid of preprocessed headers. I'm not familiar with the Microsoft proposal but the Clang developers at least put some thought into preserving interoperability with conventional headers.

>>13

Modules are about 20 years overdue at this point

Couldn't add them before - won't add them now. Concepts have been discussed back before C++11, too. Never will happen.

>>14

Couldn't add them before - won't add them now.

Any particular reason for that? Clang has a working implementation now:

http://clang.llvm.org/docs/Modules.html

Microsoft I expect to oppose this, since it is totally platform specific and reeks of Apple, but I see no reason why a more generalized form of it couldn't be added to the language standard.

>>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.

>>12
One word: The forced indentation of the types

thread over

Bignums

Use a library.

Concepts

Pointless.

Coroutines

It's always been possible with Asm. Are they also going to reinvent multilevel return sometime in the future? ;-)

Modules

Object files have been around for decades.

Nested Namespace Definitions

Useful syntax change.

>>16
That's an implementation detail. All the programmer needs to know is that modules aren't subject to the preprocessing context of code that uses them, and that's a good thing.

>>18
Don't be obtuse. Object files don't contain any type information that the compiler needs.

To bad it won't be implemented until 2069. MS never even got around to implementing C99 in their shitpiler, and GNU picks the lowest hanging fruit for what they do in the next ten years. Maybe with Clang lighting a fire under their asses, they will hurry the fuck up.

>>20
Microsoft is pretty quick about implementing new C++ features. They are the dominant force in the WG for that language. It's only C that they ignore.

>>20,21
Microsoft is giving up on their compiler front end because of how complex the code base is, and all of the shit they need to support for C++/CLI, C++/CX, various MS extensions etc.

They're working on integrating Clang for Windows/WinPhone/XBox One development into Visual Studio (they already support it for iOS and Android development in MSVS 2015). This will bring full C11, C99, OpenCL, and leading edge C++14/C++17 support to Windows finally. The plan is for a CTP release later this year.

http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx

>>19
No, that's not a good thing. The programmer also needs to know how much slower it'll make the compiler, and what it does to the optimiser.

>>20
All you need is C89.

>>23

The programmer also needs to know how much slower it'll make the compiler

Why would it make compiles slower? Preprocessing is one of the slowest things the compiler needs to do; with this everything behaves as if a precompiled header were used.

and what it does to the optimiser.

Absolutely nothing?

>>23
all u need is x86 ass

>>23
may I see your (x86) ass, by the way?

>>23
I most certainly do need more than C89. We can't all be twats who fail to actually do anything. Also, are you shilling for M$ now? Intel wouldn't pay for HRT, I guess?

No variant (sum) types. No algebraic types. STILL no parametric polymorphism. No constructor pattern matching, even without unification.
No way to mark functions as observably pure, which is pretty fucking practical in enterprise-level software design and development.
Exception specifies are useless, even harmful at times. The reason that some stl operations require "noexcept" is that the language is so shitty the compiler cannot reliably figure this shit out by itself.
The goal is to give you as much control as possible, but the only things you can actually control are useless.

Argument passing is a joke. "Smart pointers" could have rid us of the two shitty ways of passing arguments, but no, they had to add a third one.

Fuck supples, I ducking hate it.