Відео

This idea is as old as the language itself: every compiler has its language extensions. But they can't agree with each other even on something as trivial and useful as #pragma once. So it's no wonder that people are demoralized about extending C++ and start their own language ecosystems. That said, if GCC or Clang had proper extensibility mechanisms perhaps we'd see enough people who are mad enough to try but not mad enough to have their liver daily eaten by an eagle.

I'm only barenly 8 minutes in and I'm always impressed of how much practical your talks are, and yet so much about advanced C++! One of the best for sure!

Before I realized that the canceling cost of futures was too high, I had written a similar cancelable future implementation in C++ for a trading system. Solution after was to directly write hierarchical state machines.

I wish C++ had a better tooling / packaging ecosystem that could alleviate the need to put even senders and receivers into the library. If we figure out that chains are better, we don't have to carry legacy baggage around.

What is the discord being mentionned several times here? A conference one? A private one?

Thanks… Was waiting for it from a long time

So .. Eric Neibler has a quietly grumpy, super smart, code uncle .. and that guy is Sean Parent. 🙂

Epic presentation, only shame is the audio quality. I'd jump on this compiler in a heartbeat

Simply trying to sculpt Rust on top of C++ :-)

A bold new idea: Haskell language extensions that have been around for forever?

- 10:31 I appreciate the incremental approach, rather than the "rewrite it in a completely different language and different common runtime and different toolchain" mindset 🤦‍♂. - 15:46 Yeah, `3 != mask & value` was an operator precedence mistake. - 21:02 Does there need to exist a new declaration syntax if instead one just fixes the mistake of permitting parentheses in initialization in the first place? That way if you see `a b(c)`, you know it's a function call, and if you see `a b = {c}` you know it's initialization. The most vexing parse would be moot, no? - 21:03 "fn" barf, an unpronounceable devoweled word fragment. At least be consistent with the rest of C++ keywords (struct, enum, static_cast, char...) which take whole fragments. So, `func` or `fun`. - 22:27 It's an interesting illustration that newer languages can be mostly a subset of Circle. - 27:02 More often than `[no_implicit_enum_to_underlying]`, I actually wish I had the *opposite* for `enum class` bitflags, that you *could* implicitly to cast to the underlying type. - 33:19 `match` is a matching keyword actually makes sense, not `inspect`.

👍 A Windows Circle Version would be optimal😺

Edit: This is addressed at 55:26 -Some of these are great ideas (ignoring that we're still using C++ and not doing this on a simpler, objectively easier to write/maintain/debug/read/use language like C), but it will lead to fragmentation. Is that a bad thing? Neutral? Maybe it's just like it is now with companies enforcing their bike shed style policies like variable name styling, forcing namespaces, line length, etc. But it seems like a totally different `switch` semantic between companies could take getting used to? I guess companies could rename and brand their personal "version" of Circle. "Here at Twitter, er, X!, we use Dunning-Kruger Circle. Make sure you know we're not writing in C++ anymore, but DKC!"-

38:18 - This is really encouraging, because it means I can do something similar in C, with 1/4 the effort!, by skipping the horrible OOP mistake of the 1980s that we still haven't outgrown for some reason...

25:37 - Wait, isn't cppfront an evolver language? It allows for old C++, and lets anyone opt in to new features. What is the distinction here?

Excellent talk which talks about the elephant in the room whenever people are taking about a language to replace C++. It would really benefit to use those principles whenever we're having a programming language discussion. I'm going to start using the terms "C++ successor" vs "C++ alternative" every time I get a chance going forward. Many new languages which came up in the last decade are at best only alternatives. Very few seem to qualify as successor.

Constructive criticism: Audio is a bit low. Hard to hear. Pump up the volume in future recordings! Thank-you for providing access to such interesting topics!

Thank-you!

Brilliant & Exciting!