Hacker News
points by rerdavies 4 days ago | 0 comments
I think the wumpus that's being chased is that contracts COULD evolve into a compile time check. I'd be much happier if they actually caught the wumpus before they start polluting the language with yet another baroquely complicated feature that gets abandoned before it actually becomes useful (e.g. coroutines, and modules). Or just keep it simple and give us a C++-sensible replacement for assert(), and avoid the rest of it. i.e. contract_assert without the word "contract" in it. That would be a nice feature.
[–] bluGill 4 days ago
Today the compiler is allowed to fail to compile any code that will break a contract. However the details of what this means is very complex, and the ability of compilers to detect things that break the contract at still evolving. Thus forcing anything on a compiler would force an easy subset on the compilers while shutting down innovation in what we can do in the future.
[–] MFHava 4 days ago
Funny how often I read online that Coroutines are abandoned/useless, yet we ship products based on them and their application in our codebases grows continuously...
[–] rerdavies 3 days ago
Sure. But you would have had to use either a 3rd party coroutine library, or have written one yourselves to use coroutines.

C++20 provides the language feature only, and none of the libraries to use the feature. You can write your own library to use the C++20 feature, but the standard APIs are raw and brutally complex. There are 3rd party libraries to use coroutines, but they are not part of the C++20 standard.

C++23 provides a std::generator, which is indeed a great feature.

Finally, C++26 provides std::execution, and std::task, which finally makes the feature usable with only standard C++ feature, and provides facilities for executing coroutines on thread pools, or message pumps. Significant features and problems have been deferred to C++29.

I guess it's a fair point that coroutines have not been abandoned. But it's alarming that it will now take the better part of a decade for the feature to reach a sensible state (depending on how C++26 gets handled).

[–] MFHava 2 days ago
> You can write your own library to use the C++20 feature, but the standard APIs are raw and brutally complex.

I wouldn't put it that way, but I've written several coroutine wrapper types at this point, so my perspective is certainly not objective here.

> Finally, C++26 provides std::execution, and std::task, which finally makes the feature usable with only standard C++ feature, and provides facilities for executing coroutines on thread pools, or message pumps. Significant features and problems have been deferred to C++29.

I remain unconvinced mere mortals will use std::execution.

It's a marvellous example of proving what is possible with TMP without needing language support.

Naturally, it's template hell - heck, the main designer even wrote a Visual Studio Extension to understand the cryptic error messages it can generate.

Apart from that: it interacts badly with Coroutines. Even though the author of std::execution::task reached quite a good design (there are some warts, some of which could only be fixed by delaying to C++29 as it needed a change to the language feature), std::execution has poor support for it - which is unsurprising as key features of coroutines (like symmetric transfer) are not even discussed in P2300...

[–] rerdavies 2 days ago
That's disappointing. :-( Fwiw, as I remember it, the message pump implementation was easy enough. presumably because it doesn't require symmetric transfers. The thread pool implementation was hell.
[–] MFHava 2 days ago
Maybe I'm too pessimistic.

WG21 could realistically fix some issues as DRs before S/R is even implemented (and marked stable) anywhere (they have done so before for other features - notably std::format).

Thanks to the C++29 fix you could even remove hacks like `co_yield execution::with_error` as a non-exception-based abort-mechanism inside task.

But ... the problem with symmetric transfer is deeply rooted in the design of std::execution and would require large surgery ...