C++ Core Coroutines Proposal [pdf]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1063r0.pdf

144 116 8 years ago

cjhanks2• 8 years ago

The rapid change in C++ syntax may destabilize it.

For example; `auto OpenFile(const string& filename) using future_coroutine<File> [filename]`. Okay, I get it. Or the operator `[<-]`.

But as the idioms find their way into production code - an entire important segment of the C++ developer base is going to no longer be capable of reading the language. And that might be worse than not having features.

snarfy• 8 years ago

They are adding more syntax to reduce syntax. Have you seen the spaceship operator? C++ has jumped the shark. I just want an ABI. Can we get an ABI already?

maxxxxx• 8 years ago

Yes, an ABI would be great. I am always amazed how easy it is to use libraries in C# or Java whereas C++ is just a PITA.

pjmlp13• 8 years ago

It is called COM/UWP on Windows.

A C++ ABI requires an OS written in C++, likewise there is no such thing as C ABI per se, rather UNIX ABI, Win32 ABI and so forth.

hfdgiutdryg3• 8 years ago

Pardon the dumb question, but is the term ABI new (or experiencing a recent increase in usage)? I've seen it twice in the last 24 hours, and never before in my life. And that's despite being entirely too familiar with COM.

01100011• 8 years ago

If I understand things correctly, the C++ people are attempting to modernize the language and add a bunch of new stuff with the intention of deprecating the old stuff. They're constrained by legacy cruft so the new features end up with rather ugly syntax. I applaud their efforts but frankly I'd rather see a new language done right.

I'm currently trying to modernize my C++ skills and while I love some of the new features I think they're creating an inconsistent, ugly, beast of a language.

wvenable• 8 years ago

C++ will always have a place because it's a language that literally has (or will have) everything. I've used features of C++ that have no analogy in other languages. If I designed a language tomorrow, I wouldn't put that feature in. Too obscure. But I needed this random feature for a project on a constrained device to do C callback trampolines to C++ object methods.

When it comes to C++, there is no magic alternative that is "done right". I think that Rust may be the closest C++ alternative that will get in our lifetime and it's syntax isn't exactly non-ugly either.

Gibbon12• 8 years ago

I applaud their efforts but frankly I'd rather see a new language done right.

Opinion of mine is what's needed is robust and performant inter-op, and only then a new dialect that fixes some of the deep legacy problems with the language. At least that would provide a clean migration path.

pjmlp13• 8 years ago

Beautiful languages don't get adopted unless there is an OS vendor stating "It is my way or go elsewhere".

The languages with higher success rate are the ones that build on existing code and practices.

Every language with major market adoption is an inconsistent unless one does a language reboot Perl 6/Python 3 style and is willing to push it forward.

hfdgiutdryg3• 8 years ago

I spent a decade watching C++ painfully slowly add more advanced template support and... well, that's about it. After a million iterations of "for (mylisttype::const_iterator i ..." they finally added ranged for loops.

The rate of change seems to be increasing. This is initially a bit shocking until I remember that every single job I had was like using a completely different language because, even ten years ago, every shop used a different subset of C++ and STL!

Add all you want to the language, it's all going to devolve into code-review infighting the same way it did in 2008.

pjmlp13• 8 years ago

This is a common complaint about C++, as if the other languages were any better in this regard.

Java 11, C# 8, Python 3.7, Fortran 2018, F# 4.5,.... try to write in a way that everyone will agree with, or do language quiz to see what which one gets right.

Sure there is C that looks so simple, who gets right all the ISO C changes between C89, C90, C11, C17, UB and compiler specific extensions/issues without having to look into the books?

eecc• 8 years ago

Hah, those code reviews must be fun. At least as much as a Scala one ;)

gpderetta4• 8 years ago

I spent a decade watching C++ painfully slowly add more advanced template support and... well, that's about it. After a million iterations of "for (mylisttype::const_iterator i ..." they finally added ranged for loops.

C++ was first standardized in '98. Nothing happened for more 10 year (in particular no new advanced template support) unless you count the very minor bug fixes in C++03. The next revision, C++11, added ranged for loops.

cjhanks2• 8 years ago

Haha, you're too crusty to be listened to!

Yeah, you're right. In some respects, things haven't changed.

pcwalton4• 8 years ago

It seems that the main issue that the authors of this proposal have with the current coroutines proposal in the committee is that that proposal effectively requires allocation for all coroutines, while offering promises that the optimizer will be able to avoid the allocation in common cases. This competing proposal makes allocation opt-in for various reasons, not the least of which is skepticism about how well the optimization will perform. (See "Implicit allocation violates the zero-overhead principle" in this document [1]).

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p097...

RcouF1uZ4gsC• 8 years ago

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p098...

The people that actually implement coroutines in the compilers actually think that eliding the allocation is very doable.

pcwalton4• 8 years ago

Richard Smith, quoted in the document I linked as saying "I do not have any confidence this optimization would ever become reliable in the way that, say, certain forms of NRVO are," is the code owner of the clang frontend.

DannyBee• 8 years ago

This is definitely wrong :)

Besides Richard, who is the code owner of the clang frontend , chandler is the #5 contributor to LLVM (see here https://github.com/llvm-mirror/llvm/graphs/contributors), and a quick trip to llvm-dev will tell you how much time he spends working on optimizations :)

FWIW: The GCC folks i pinged were similarly unenamored with the idea of trying to elide allocation all the time.

Personally, i've seen a bunch of these "required optimizations" over the years, and they rarely pan out without significant help. (IE required tail call optimization usually requires special marking/calling convention change, etc).

Full disclosure: Chandler, Geoff, and Richard are in my org, and i am theoretically their boss's boss. I say theoretically because it's pretty meaningless - i'm not going to tell Richard how to do C++.

AndyKelley3• 8 years ago

This is the main issue that zig has with LLVM's coroutines implementation, as well as:

* buggy - we currently have to disable all optimizations in coroutine functions because mem2reg reverts correct coroutine frame spills back to invalid parameter references

* compilation speed - llvm's coroutine splitting code is extraordinarily slow.

I had a chat with Eddy B about how coroutines work in rust, and I think it's a much better approach. Rust does its own splitting in the frontend, and avoids LLVM coroutines in the IR.

But yeah, non-guaranteed memory allocation elision is just not going to cut it. Especially if we need guaranteed memory allocation elision in debug builds where we don't have time to run any optimizers.

0xFFC• 8 years ago

I don't understand the point of co_*. Why should you have something as ugly as this? Just use std::coroutine?

palotasb• 8 years ago

They are supposed to be keywords like return or throw. Those cannot be namespaced either.

quickben• 8 years ago

[<-] "Our proposed spelling is intended to suggest unwrapping"

I'd argue co_unwrap() has spelling that suggests unwrapping.

dmoreno• 8 years ago

I still have to read it through, but why does it require new syntax and not just new standard library additions like boost::coroutine?

I just fell in love with boost::fiber so i hope there will be also something like it in the future std.

mattbierner• 8 years ago

This could be completely off-base but:

- Clarity and establishing convention. Boost coroutine2 uses a lot of boostyness to make using coroutines in c++ less painful, but they still require boilerplate and can be quite difficult to write. Understanding code that uses coroutine2 also requires understanding how the coroutine2 library works and how it uses normal c++ syntax in unique ways.

Having a dedicated operator like [<-] arguably produces more familiar looking and clearer user code. (Take a look at the generator example in the appendix of this proposal; the implementation of the 'generator' type is horrific but the 'Traverse' function is pretty easy to read.)

- Generalization. Boost::coroutine2 targets coroutines. This proposal tries to generalize aspects of the coroutines proposal such as the unwrap operator [<-] to support use cases like linear monads.

kbwt2• 8 years ago

And yet this proposal still doesn't let you implement zero-overhead objects-as-coroutines. I'd like to be able to create a coroutine that initializes some state ("constructor"), yields back to the caller, and lets you call alternate re-entry points ("member functions") that manipulate the state and yield back, or the final entry point that cleans up the state ("destructor"). If the initialization fails for whatever reason, the yield will simply be skipped. Crucially, I want to be able to do all of this without indirect jumps other than returns.

AndyKelley3• 8 years ago

Serious question, what's the difference between this and a class?

BeeOnRope4• 8 years ago

I guess when you call an entry point the second time it restores the existing context at the point of the previous yield. So you have mix of shared state (class members) and local state between the various entry point. Just a guess though.

kbwt2• 8 years ago

If you try to implement a class in C, you always end up with duplicated cleanup code between your "constructor" and your "destructor". Being able to jump from the constructor to the corresponding part of the destructor when the construction of a subobject fails would get rid of this often buggy/untested secondary code path.

Some idioms have been developed over time, such as first initializing in a failsafe manner all the object's fields to a value that prevents deinitialization, but they add complexity to the code where it is not needed.

kristiandupont• 8 years ago

It seems there's a weird fetish in C++ land where non-letter characters seem more "pure" than words. I remember suffering from it myself, implementing atrocities like a subtraction opeartor on a path class which would give you the relative path between two paths. It made me feel very clever but I feel sorry for anyone who would have to look at my code now and try to figure out what the hell was going on.

Sharlin• 8 years ago

Often the reason is not wanting to introduce new keywords for backwards compatibility reasons. And when keywords are introduced, often they have to be awkward (like `co_await`) to minimize conflicts with existing code. Context-sensitive keywords are one solution but can make parsing even more complicated in places where arbitrary lookahead might be needed.

stochastic_monk• 8 years ago

That’s also why the sizeof... operator was chosen. It’s an abuse of notation, because it returns a count of elements rather than the sum of sizeof applied to each, but ... and sizeof were already reserved.

pjmlp13• 8 years ago

C++ land is actually quite conservative.

You should try Lisp, ML, Haskell Julia lands regarding that matter.

Developers with math background on languages with symbols as identifiers can get quite creative.

lallysingh• 8 years ago

At least with Haskell (I can't speak for the others), you don't redefine existing operators, you add new ones. Which is less confusing in some ways

pcwalton4• 8 years ago

It's because defining "customization points" as operators make it easier to write templates, essentially. See "C++ doesn’t know how to do customization points that aren’t operators": https://quuxplusone.github.io/blog/2018/08/23/customization-...

This is one of the downsides of not having typeclasses that is often forgotten about.

cheez• 8 years ago

That's why I cannot wait for concepts

aaaaaaaaaab4• 8 years ago

Wouldn’t uniform call syntax (like in D) solve most of the issues outlined above? I.e. it always boils down to “primitive types can’t have methods”; but uniform call syntax would let us call any function like a method on its first argument...

Aardwolf• 8 years ago

It's weird how opposite the core language and the std library of C++ are, and even more so in the recent revisions! The core language seems to go for being as code-golfy as possible, while the std library goes for super-verbose without any convenient shortcuts

The core language adds ascii character notations optimized for brevity.

The library instead makes things that should require 1 argument take 2 or 3 arguments (which ranges will hopefully fix), makes value to string conversions as verbose as possible, etc...

bluGill• 8 years ago

The core language is much harder to work with than the library, thus the difference.

The library can be posted as code and thus we can test it thoroughly, and discuss it based on a real implementation.

Contrast that to the language. It isn't code, it is standardize. It is written by and for lawyers in the negative sense of the word lawyers. Anything you do in the core language is hard because there are too many ways to accidentally (or intentionally) slip something evil past everybody.

C++ takes backward compatibility seriously. If I didn't have a 20 year old code base of working code to deal with I'd be working in Rust, D, Go, Java, C#, or whatever the language of the day is. (Note that because of the amount of users and time C++ often has better optimization, but if that fraction of a percent better matters you can invest in optimizer work for your chosen language and solve the problem)

Waterluvian• 8 years ago

That's pretty idiomatic in Python and often is fine. But surely can be abused. Pathlib let's you use / to append paths. You're not dividing anything but it's still quite intuitive.

And python sets let you subtract to get a difference, similar to your clever trick. I think it helps when these things are core to the language and broadly known. Otherwise you're scratching your head at what - will do.

beojan• 8 years ago

This doesn't seem to be a coroutines proposal so much as an attempt to sneak (Haskell's) `do` notation into C++.

Which I applaud, it's a brilliant feature.

anqurvanillapy• 8 years ago

Bikeshedding alert: If a linear monad use case is considered and a do-notation-like syntax is proposed, why isn’t a left-bind =<< operator introduced by nature.

C++ Core Coroutines Proposal [pdf]

Related Stories