On Wed, Sep 25, 2019 at 10:12 PM Jefferson Carpenter via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I should have followed my own advice: never write things right before
you go to sleep.

FWIW, I thought your manifesto was well-written, accurate, and needed. I wish more programmers would speak up about C++! My only nitpick is that you got a tiny bit hyperbolic in the last sentence. ;)

In their closing keynote of the Back-to-Basics track at CppCon 2019, "What is C++?" Chandler Carruth and Titus Winters make a similar point about the relative complexities of C (well, C89) and C++ — that essentially any expert C programmer could write a C89 compiler given funding and time, but essentially no expert C++ programmers today can write a C++ compiler. (If this wasn't true of C++03, it's certainly true of C++11 constexpr; and it's far-and-away true of C++2a concepts and coroutines!)

–Arthur

 
On 9/26/2019 2:02 AM, Jefferson Carpenter wrote:
> As tempting as it is to add new and powerful features to the language,
> for various reasons from simplifying existing code to 'keeping up' with
> other languages out in the field, it's a dangerous and bloody art to do so.
>
> The C++ spec may define the syntax and evaluation semantics of the
> language, but what breathes life into it is the compiler.  The more
> complicated the spec is, the more complicated the compiler must become.
> We're fortunate to have a diverse set of c++ compilers from the
> proprietary to the open source, but the more features get added, the
> higher the initial cost to creating a new viable c++ compiler project.
>
> Slow and steady wins the race.  There does not exist a language feature
> (except maybe value semantics) that will not, at some point in the near
> or far future, become invalidated by cleaner ways of doing the same
> thing.  Adding too many features kills languages.  Optimally, the rate
> at which features are added should be equal to the rate at which they
> are deprecated and removed, over long time spans.  This ensures that
> compiler writers will not have to do too much up-front work to learn to
> maintain a compiler or to write a new one.
>
> To pick on coroutines (although they certainly can be useful), co_await,
> co_yield, and co_return can be implemented as library functions
> abstracting and making platform-independent the existing functions
> setjmp and longjmp, with only the overhead of keeping a reference to
> some state holding the continuation in the calling code and the
> continuation in the coroutine.  Additionally, while coroutines make
> serial asynchronous operations easier to write, they cannot do the same
> for parallel asynchronous operations without potentially pessimizing
> performance.  In "x = co_await y; x2 = co_await y2;" x2 cannot be
> assigned before x has been assigned - even if y2 completes before y -
> unless the compiler can come up with a proof that such re-ordering does
> not change the visible behavior of the program.  Instruction reordering
> and the as-if rule already indicate that the semantics of C++ place too
> much emphasis on the sequencing of operations over the dependency graph
> of data.
>
> As excited as I am for new C++20 features including concepts and
> coroutines, I'm more excited for the deprecation of most of volatile.  I
> want the language to be well understood as-is so that it can be reasoned
> about, the real pain points identified, and the spec slowly changed to
> meet new needs with the patience of a community that deserves to
> continue to beat until the last program is written and the last rock is
> dust.
>
> Peace,
> Jefferson