Brno Ballot Demonstration

Background: The C++ community has debated const placement for decades. "East const" places const after the type (int const x), reading right-to-left consistently. "West const" places const before the type (const int x), matching English word order.

Background: C++20 introduced co_await, co_return, and co_yield as language keywords. Production codebases have used coroutines for asynchronous programming since 2020. The programmer writes sequential code with co_await before async operations.

For: Coroutines suspend and resume sequential code at await points. This is the textbook definition of an async programming model. Every major compiler implements them. Production deployments span six years.

Against: Coroutines are a language mechanism, not a model. They provide suspension/resumption but define no completion protocol, no error channel, and no composition algebra. A model requires more than keywords.

Background: std::execution was adopted into the C++26 working draft at St. Louis in July 2024. It defines senders, receivers, schedulers, and approximately 30 composition algorithms (then, when_all, let_value, etc.) for expressing asynchronous work.

For: std::execution defines a complete computation model with a composition algebra, structured concurrency guarantees, and a three-channel completion protocol. It is explicitly designed for asynchronous programming.

Against: std::execution is a library framework within C++, not a separate "model." Calling it a separate model implies fragmentation. It is the standard's async facility - the model, not a model.

Background: P3552R3 "Add a Coroutine Task Type" defines std::execution::task in Section 9.4.1: "The task class template represents a sender that can be used as the return type of coroutines." The type is implemented using the C++20 coroutine machinery (co_await, promise_type, coroutine_handle) and satisfies the sender concept from std::execution.

For: The specification says so. The implementation uses coroutine keywords. The type satisfies the sender concept. It is, by definition, both.

Against: task is a sender that uses coroutines as an implementation technique. Calling it "both" implies two independent identities rather than one type with one purpose that happens to use coroutine syntax.

Background: C++26 ships both C++20 coroutines (co_await, co_return, co_yield) and std::execution (senders, receivers, schedulers, ~30 algorithms). In 2021, the committee polled "We believe we need one grand unified model for asynchronous execution" and did not achieve consensus (SF:4 / WF:9 / N:5 / WA:5 / SA:1).

For: The working draft contains two distinct mechanisms for async programming: coroutine keywords and sender algorithms. std::execution::task bridges them, proving they are two things that need bridging. The committee's own 2021 poll failed to achieve consensus on one model.

Against: There is one async model (std::execution) that uses coroutines as a syntactic convenience. Coroutines are an implementation mechanism, not a competing model. Claiming "two models" creates artificial division and harms teachability.