C++20 What is coming to the C++ language?

Nucleus.

Concepts .

Concepts are an enhancement to the C++ template system, they are a special type of compile-time evaluable function that must return true to consider the concept true. Its function is to control the characteristics that the parameters of a template must meet. But their functionality is not limited to the scope of templates, they can also be used in other contexts.

Concepts are long-awaited C++ functionality that's been 10 years in the making (it was left out of C++11 due to lack of time, left out of C++14 as incomplete, and left out of C++17 due to lack of consensus).

Example

We can define a concept as follows:

template <typename tipo_t>
concept bool es_sumable()
{
    return requires(tipo_t a, tipo_t b)
    {
        { a + b } -> tipo_t;
    };
};

The previous concept is fulfilled if the expression a + bis possible and its type is tipo_t, then we can use the concept as a parameter:

auto suma(const es_sumable &a, const es_sumable &b) { return a + b; }

And the function sumawill only accept types that satisfy the concept es_sumable. It can also be used as a variable:

es_sumable resultado = "Hola "s + "mundo!"s;

The variable resultadowill have to match es_sumableor the code will not compile. Lastly, a template may be required to meet one or more concepts:

template <typename tipo_t>
concept bool entero() { return std::is_integral<tipo_t>::value; }

template <typename tipo_t>
concept bool de_4_bytes() { return sizeof(tipo_t) == 4; }

template <typename T>
T dobla(const T &a) requires entero<T>() && de_4_bytes<T>()
{
    return a + a;
}

In the previous function, the template parameter Tmust be a 32-bit integer, if it is not, a clear and concise error will be displayed:

auto dobla(111ull);

> note:   constraints not satisfied
T dobla(const T &a) requires entero<T>() && de_4_bytes<T>()
  ^~~~~
note: within 'template<class tipo_t> concept bool de_4_bytes() [with tipo_t = long long unsigned int]'
concept bool de_4_bytes()
             ^~~~~~~~~~
note: 'sizeof (long long unsigned int) == 4' evaluated to false

Initializers by Name in Aggregates (DT P0329R0 )

Proposal to allow names to be specified in the initialization of objects of aggregate type, as is already allowed in C (since C99).

Example

Assuming we have the following object:

struct punto { float x, y, z; };

The following initialization would be correct as of C++20:

punto p { .x{}, .y{}, .z = 100.f };

There are certain differences compared to C99 that must be taken into account:

• All members must be initialized:

    punto p { .x = .0f, .z = 100.f }; // Correcto en C, incorrecto en C++
  

• The members must be in the order of definition:

    punto p { .z = 100.f, .y = .0f, .x = .0f }; // Correcto en C, incorrecto en C++
  

• Members must not be duplicated:

    punto p { .x = 100.f, .x = .0f }; // Correcto en C, incorrecto en C++
  

• Formation initialization is not allowed:

    struct punto { float v[3]; };
    p { .v[1] = 100.f }; // Correcto en C, incorrecto en C++
  

• Nested initialization is not allowed:

    struct punto { float x, y, z; };
    struct linea { punto a, b; };
    linea l { .a.x = 100.f }; // Correcto en C, incorrecto en C++
  

Lambdas template (DT P0428R2 )

Since C++14 the language allows Generic Lambda ; but while they make C++ Lambdas more useful, Generic Lambdas don't offer as much flexibility as might be expected, to the point that in some contexts it's still more useful to use a template function rather than a Generic Lambda. This whitepaper proposes the following new syntax for Lambdas:

[captura(s)]<parámetro(s) plantilla>(parámetro(s) Lambda){ código; }

That is, angle brackets ( <and >) are added to the Lambda in order to handle template parameters.

Example

Lambda that works only with std::vectorGeneric version:

auto g = [](auto v)
{
    static_assert(std::is_std_vector<decltype(v)>::value, "necesito vector!");
    // Obtenemos el tipo almacenado en el vector
    using T = typename decltype(vector)::value_type; 
    // ... código ...
};

Template version:

auto p = []<typename T>(std::vector<T> v)
{
    // ... código ...
}; 

Lambda that calls a static function of the passed type and accesses nested types Generic version:

auto g = [](const auto &t)
{
    /* Necesitamos decay porque si no deduce referencia (&)
    y no podríamos usar el operador de contexto (::) para
    acceder a funciones estáticas o tipos anidados. */
    using T = std::decay_t<decltype(t)>;
    T copia = t;
    T::f_estatica();
    using Iterator = typename T::iterator;
    // ... código ...
};

Template version:

auto p = []<typename T>(const T &t)
{
    /* Obtenemos el tipo como parámetro de plantilla, esto
    nos evita complicar el código con decay. */
    T copia = t;
    T::f_estatica();
    using Iterator = typename T::iterator;
    // ... código ...
}; 

Three-way comparison (white paper P0515R3 ).

This proposal is known by the pseudonym " The spaceship operator " because of the resemblance of the proposed operator ( operator <=>) to a Tie-Fighter:

The proposal suggests adding a new operator to the language that performs a comparison between objects, being able to obtain three different results, for the three-way comparison , the following a <=> bwould be obtained:

• A value less than zero if ait is less than b.
• A value equal to zero if aand bwere equivalent.
• A value greater than zero if ait is greater than b.

The three-way comparison would reduce the amount of code needed to allow a data to be strictly sortable , which requires several comparisons that are usually implemented based on the previous ones to save code:

struct coordenada { int x, y; };

bool operator==(const coordenada &a, const coordenada &b) { return a.x == b.x && a.y == b.y; }
bool operator< (const coordenada &a, const coordenada &b) { return a.x < b.x || (a.x == b.x && a.y < b.y); }
bool operator!=(const coordenada &a, const coordenada &b) { return !(a==b); }
bool operator<=(const coordenada &a, const coordenada &b) { return !(b<a); }
bool operator> (const coordenada &a, const coordenada &b) { return b<a; }
bool operator>=(const coordenada &a, const coordenada &b) { return !(a<b); } 

The proposal suggests allowing the compiler to generate the three-way comparison by default, doing so would perform a member-to-member three-way comparison recursively between the operators of the operator.

Example

Three-way comparison (generated by the compiler) of the object in the code above:

struct coordenada
{
    int x, y;
    auto operator<=>(const coordenada &) const = default; 
};

The return type will be autobecause the return type is compiler dependent, the only restriction it must follow is that it can be compared against zero (greater than, less than, or equal to zero).

forrange with initializer (technical document P0614R1 )

In C++11 the range loop was added forwith the following syntax:

for (declaración : expresión) {
    Código
}

It allows you to create code that is easier to understand and maintain, but lacks the flexibility of the fortraditional loop by not allowing initializers. The proposal is to relax the range loop forwith an initializer:

for (inicialización; declaración : expresión) {
    Código
}

Example

We get a temporary object from which we iterate one of its internal properties:

for (Coche c = fabricar_coche(); auto &rueda : c.ruedas()) {
    std::cout << comprobar_presion(rueda) << '\n';
}

Default Constructable and Mappable Stateless Lambdas (DT P0624R2 )

A lambda without captures is called " Lambda without state ", this type of lambda is implicitly convertible to function pointer:

using funcion_void = void();
función_void *fv = []{ std::cout << "Hola mundo!\n"; };

Pero en algunas situaciones no se comportan como punteros a función. Los punteros a función son copiables, asignables y construibles mientras que las lambdas sin estado no lo son.

Ejemplo

Esta propuesta hace que las lambda sin estado se comporten como punteros a función:

using funcion_void = void();
void a(){}
void b(){}
void f(funcion_void *){}

funcion_void *fv; // Correcto, construcción por defecto.
fv = a;           // Correcto, asignación.
fv = b;           // Correcto, reasignación.
f(fv);            // Correcto, copia.

auto lambda = []{};
decltype(lambda) l;          // Construible por defecto? Error (Correcto en C++20).
decltype(lambda) m = lambda; // Asignable? Error (Correcto en C++20).
decltype(lambda) m = l;      // Copiable? Error (Correcto en C++20).

Permitir la expansión de paquetes de parámetros en la captura de lambdas (DT P0780R0)

En una lambda se pueden capturar los parámetros por copia:

template <typename ... paquete_de_parametros>
void f(paquete_de_parametros ... parametros)
{
    auto lambda = [parametros ...]{};
//                 ^^^^^^^^^^^^^^ <--- captura por copia.
}

Pero el estándar previo a C++20 prohíbe explícitamente expandir paquetes de parámetros en las capturas.

Ejemplo

C++20 levanta esta prohibición:

template <typename ... paquete_de_parametros>
void f(paquete_de_parametros ... parametros)
{
    auto lambda = [std::move(parametros) ...]{};
//                 ^^^^^^^^^^^^^^^^^^^^^ <--- Expande con std::move
}

Literales de cadena de caracteres como parámetros no-tipo en plantillas (DT P0424R2)

El estándar previo a C++20 establece explícitamente que los literales de cadena de caracteres no pueden ser usados como parámetros de plantilla:

template <auto T> void f() {}

f<"Hola">(); // Error!
f<"Hola">(); // Error!

El motivo de esta limitación es que dos literales de texto iguales (como en el ejemplo anterior) no tienen garantías de ser el mismo literal (se almacenan como punteros) y en consecuencia no hay manera de saber si dos funciones con el mismo literal de texto son la misma. En C++20 se permite la verificación del parámetro literal de texto en tiempo de compilación pudiendo comprobar si dos literales de texto tienen el mismo contenido, esto permite que los literales de texto puedan ser usados como parámetros no-tipo en plantillas.

Macros de verificación de funcionalidades (DT P0941R1)

Si el compilador dispone de una funcionalidad determinada, ésta podrá ser verificada usando la macro __has_cpp_attribute. La macro recibirá un único parámetro que será un identificador asociado a una funcionalidad determinada.

Ejemplo

Si el compilador dispone del bucle for de rango (C++11) lo usamos, usamos el bucle tradicional en caso contrario:

int datos[100];

#if __has_cpp_attribute(__cpp_range_based_for)
    for (int &i : datos)
    {
        i = 0;
    }
#else
    for(int *i = datos; i != datos + 100; ++i)
    {
        *i = 0;
    }
#endif

###Explícito condicional explicit(bool) (documento técnico P0892R2). En el estándar C++11 se permitió controlar las conversiones implícitas al construir o convertir objetos al permitir marcar como explícitos los constructores u operadores. En C++20 se amplía esta funcionalidad pudiendo pasar un parámetro al especificador explicit para hacer que éste se aplique condicionalmente.

Ejemplo

El objeto O tiene un constructor explícito cuando el tipo usado para construirlo sea de mayor tamaño que el tipo almacenado, constructor implícito en caso contrario:

template <typename T>
struct O
{
    T t{};

    template <typename U>
    explicit(sizeof(U) > sizeof(T))
    O(U u) :
        t{static_cast<T>(u)} {}
};

La palabra clave explicit esperará una expresión convertible a booleano a partir de C++20, así que habrá que corregir algunas líneas de código:

struct S
{
    explicit(true) S(int) {}          // Constructor explícito
    explicit(false) S(std::string) {} // Constructor implícito
};

Permitir que las llamadas a funciones virtuales sean constexpr (DT P1064R0)

Las llamadas a funciones virtuales están prohibidas en expresiones constantes en estándares previos a C++20.

Ejemplo

El compilador conoce los tipos implicados en algunas llamadas virtuales y podría resolver la llamada en tiempo de compilación.

struct X1
{
    constexpr virtual X1 const* f() const { return this; }
//  ~~~~~~~~~~~~~~~~~ <--- Error! Correcto a partir de C++20.
};

struct Y
{
    int m = 0;
};

struct X2: public Y, public X1
{
    constexpr virtual X2 const* f() const { return this; }
//  ~~~~~~~~~~~~~~~~~ <--- Error! Correcto a partir de C++20.
};

constexpr X1 x1;
static_assert( x1.f() == &x1 );
//                ~~ <--- 'f' es una función virtual, no se puede usar 
//                         en una verificación estática, salvo en C++20 o superior

Funciones Inmediatas (DT P1073R2)

A partir de C++11 se puede usar la palabra clave constexpr para marcar valores o funciones que podrían ser válidas dentro de una expresión constante (expresión calculada en tiempo de compilación). Las funciones marcadas como constexpr pueden también ser llamadas en tiempo de ejecución.

Esta propuesta añade la palabra clave consteval para marcar valores o funciones que obligatoriamente deben ser evaluadas en tiempo de compilación y producir un error en caso contrario.

Las funciones consteval reciben el nombre de función inmediata porque la función no se compila para ser ejecutada si no que se evalúa en tiempo de compilación y se sustituye su llamada por el resultado de la evaluación, una función inmediata no tiene por qué aparecer en el binario compilado.

Ejemplo

Las funciones inmediatas provocan un error de compilación si no se pueden calcular en tiempo de compilación:

consteval int cubo(int n) {
  return n*n*n;
}
// Correcto: 'cubo' se llama con un literal, es calculable en tiempo de compilación
constexpr int v = cubo(3);
int tres = 3;
// Error: 'cubo' se llama con una variable, NO es calculable en tiempo de compilación
int w = cubo(tres);

constinit (DT P1143R2)

El lenguaje C++ no especifica el orden en que las variables estáticas deben ser inicializadas, dejando esta decisión en manos de los compiladores. Esto provoca que las variables estáticas con inicializadores dinámicos provoquen errores difíciles de rastrear cuando unas dependen de otras (esto se conoce como Static Initialization Order Fiasco). Las variables con inicializadores constantes evitan este problema, ya que pueden inicializarse en tiempo de compilación y se pueden usar de manera segura para inicializar otras variables.

Para garantizar que una variable se inicializa en tiempo de compilación, se debe obligar al compilador a que la inicialización sea constante, para ello se puede marcar una con constinit:

Ejemplo

Tenemos una función (valor_dinamico) que calcula un valor en tiempo de ejecución y otra (misterio) que podría ser evaluada en tiempo de compilación o en tiempo de ejecución:

int valor_dinamico() { static int x = 0; return x++; }
constexpr int misterio(bool p) { return p ? 42 : valor_dinamico(); }

constinit const int a = misterio(true);  // Correcto.
constinit const int b = misterio(false); // Error

Si misterio no puede ser evaluada en tiempo de compilación, la expresión marcada con constinit falla.

using enumerado (DT P1099r5)

En C++11 se añadieron al lenguaje los enumerados-clase:

enum class Dia : unsigned { L, M, X, J, V, S, D };

Este nuevo tipo de enumerado no exporta sus símbolos al ámbito superior:

enum Vocal { a, e, i, o, u };
enum class Dia : unsigned { L, M, X, J, V, S, D };

int main()
{
    // Correcto, 'Vocal' exporta sus símbolos a este ámbito: 'Vocal::a' es accesible.
    std::cout << a << '\n';

    // Error, 'Dia' NO exporta sus símbolos a este ámbito: 'Día::D' NO es accesible.
    std::cout << static_cast<unsigned>(D) << '\n';

    return 0;
}

Ejemplo

A partir de C++20 se permite importar los símbolos de un enumerado-clase mediante la cláusula using:

enum Vocal { a, e, i, o, u };
enum class Dia : unsigned { L, M, X, J, V, S, D };

int main()
{
    // Correcto, 'Vocal' exporta sus símbolos a este ámbito: 'Vocal::a' es accesible.
    std::cout << a << '\n';

    using enum Dia;
    // Correcto, 'Dia' exportó explícitamente sus símbolos a este ámbito: 'Dia::D' es accesible.
    std::cout << static_cast<unsigned>(D) << '\n';

    return 0;
}

Permitir conversiones a formaciones abiertas (DT P0388R4)

WIP.

Funciones miembro especiales condicionalmente triviales (DT P0848R3)

WIP.

Parcheando la deducción de parámetros plantilla de clase (DT P1021R5)

WIP.

Deprecar volatile (DT P1152R4)

WIP.

Librería.

Extender <chrono> para manejar calendarios y zonas horarias (DT P0355R7).

Se incorpora a la librería de manejo de tiempo <chrono> utilidades para manejar calendarios y zonas horarias:

using namespace std::chrono;
auto date = 2016y/May/29;
std::cout << date << '\n'; // Muestra 2016-05-29 (cambia según configuración local).

Conversión estándar a bits (documento técnico P0476R2).

En programación a bajo nivel, suele ser necesario interpretar un dato como si fuera otro; en otras palabras: mantener la misma representación binaria pero obteniendo un dato de diferente tipo.

Normalmente se usa reinterpret_cast o type punning mediante uniones para conseguirlo, pero éstos métodos son propensos a errores, lo más seguro es usar un std::aligned_storage sobre el que copiar los datos, pero es incómodo y costoso.

La nueva cabecera <bit> proporciona herramientas para acceder, manipular y procesar tanto secuencias de bits como bits individuales de una forma menos propensa a errores y más flexible: asegura que los tamaños de los tipos de entrada y de salida coincidan, garantiza que ambos tipos sean copiables y hace que la expresión se calcule en tiempo de compilación cuando sea posible.

Librería de formato de texto (DT P0645R10).

Las herramientas de escritura de texto de C++ son difíciles de entender y usar, el encadenado de std::ostream y los formateos de <iomanip> en ocasiones se quedan cortos y no ofrecen una suficiente flexibilidad, en ocasiones se delega a printf por claridad o costumbre. Este documento técnico propone una alternativa a el formateo de texto con la flexibilidad de printf y la seguridad de std::ostream.

La librería de formato de texto acepta argumentos posicionales implícitos y explícitos:

std::cout << std::format("La cadena '{}' tiene {} caracteres\n", string, string.length()));
std::cout << std::format("{1} caracteres tiene la cadena '{0}'\n", string, string.length()));

Constantes matemáticas (DT P0631R8).

Este documento técnico propone una nueva cabecera <numbers> y espacio de nombres numbers. Se incluyen varias constantes matemáticas de uso común como e, π, inversa de π… en formato de variable plantilla:

template<typename T> constexpr T pi =3.14159265358979323846L;

Sufijos para ptrdiff_t y size_t (DT P0330R3)

El siguiente código provoca un error de compilación:

std::vector<int> v{0, 1, 2, 3};
for (auto i = 0, f = v.size(); i < f; ++i) {
    // …
}

La variable i se deduce como int mientras que f se deduce como el retorno de std::vector::size (que suele definirse como std::size_t), el siguiente código corrige el problema:

std::vector<int> v{0, 1, 2, 3};
for (std::size_t i = 0, f = v.size(); i < f; ++i) {
    // …
}

Pero pierde flexibilidad. Dado que no existen literales de tipo std::size_t se propone un sufijo:

El sufijo zu (size unsigned) soluciona el problema:

std::vector<int> v{0, 1, 2, 3};
for (auto i = 0zu, f = v.size(); i < f; ++i) {
    // …
}

Evolución.

Excepciones determinísticas sin coste: throw valores (DT P0709R4)

WIP.

using de enumerado (DT P1099R5)

WIP.

Soporte a la configuración de clases (DT P1112R2)

WIP.

constinit (DT P1143R2)

WIP.

Añadir texto informativo a [[nodiscard]] (DT P1301R4)

WIP.

Evolución de librería.

Integrar simd con algoritmos paralelos (DT P0350R3)

WIP.

Hacer que std::string y std::vector sean constexpr (DT P0980R1 y P1004R2)

WIP.

Librería de Conceptos (documento técnico P0898R2).

Los conceptos serán una herramienta de C++ para hacer verificaciones sobre los tipos de los parámetros en tiempo de compilación. Es una utilidad que se lleva desarrollando desde C++11 y aunque aún no ha sido incorporada al lenguaje hay varios compiladores que le dan soporte, lo que hace pensar que será aprobada en breve. Para evitar desarrollar conceptos desde cero se propone una librería de conceptos que ofrezca los más comunes.

Ejemplo.

Usamos el concepto Copyable para que una función sólo acepte tipos que se puedan copiar:

#include <concepts>

template <std::Copyable T>
T clonar(const T&)
{
    // ...
}

Clases como parámetros no-tipo en plantillas (documento técnico P0732R2).

C++ sólo permite datos que puedan ser evaluados en tiempo de compilación para verificar su unicidad como argumentos para parámetros no-tipo en plantillas. Esto limita el tipo de estos parámetros a enteros y punteros o referencias a datos o funciones con enlazado externo.

En otras palabras, se necesita garantizar que dada una plantilla con parámetro no-tipo, tiene que ser cierto que &P<a> == &P<b> cuando a == b, pero las clases de C++ no son por defecto comparables por igualdad ni el operador de igualdad forma parte de las funciones especiales que auto-genera el compilador. Así que este documento técnico propone usar el operador de comparación a tres bandas (apodado operador nave espacial <=>) ya que se ha propuesto que éste si sea auto-generado por el compilador.

Ejemplo.

Este código sería válido en C++20 pero no lo sería en estándares anteriores:

struct S{};

template <S s> struct T {};

T<S{}> t; // Instancia de S como parámetro no-tipo

Reflexión estática (documento técnico P0275R4).

Según la Wikipedia, la reflexión es:

La capacidad que tiene un programa para observar y opcionalmente modificar su estructura de alto nivel.

Un lenguaje con reflexión proporciona un conjunto de características disponibles en tiempo de ejecución que, de otro modo, serían muy difícilmente realizables en un lenguaje de más bajo nivel. Algunas de estas características son las habilidades para:

• Descubrir y modificar construcciones de código fuente (tales como bloques de código, clases, métodos, protocolos, etc.) como objetos de "categoría superior" en tiempo de ejecución.
• Convertir una cadena que corresponde al nombre simbólico de una clase o función en una referencia o invocación a esa clase o función.
• Evaluar una cadena como si fuera una sentencia de código fuente en tiempo de ejecución.

Este documento técnico propone añadir utilidades de reflexión a C++, esta reflexión sería estática (disponible en tiempo de compilación), para ello se añadiría al lenguaje la palabra clave reflexpr que aplicada sobre una definición, devolverá un objeto que contenga información de la misma.

Ejemplo.

Podemos obtener el nombre de un parámetro así:

void f(char c, short s, int i, long l, float f, doublé d);

int main()
{
    auto metadatos_f = reflexpr(f);
    auto parametros_f = get_parameters_t<metadatos_f>;
    auto tercer_parametro_f = get_element_t<2, parametros_f>;

    std::cout << get_name_v<tercer_parametro_f>; // muestra 'i'

    return 0;
}

Usar [[nodiscard]] en la librería estándar (documento técnico P0600R1).

Este documento técnico propone añadir el atributo [[nodiscard]] en la librería estándar cuando no usar el valor de retorno:

• Suponga un gran error (como fugas de memoria).
• Sea propenso a generar problemas.

De momento se valora marcar como [[nodiscard]] std::async(), std::launder, std::allocate y empty en contenedores.

Flujo de salida con sincronización (documento técnico P0053R7).

El estándar garantiza que los flujos de salida de datos no producirán condiciones de carrera, pero no garantiza que enviar datos a esos flujos produzca un efecto perceptible; para que esto sea así se requiere un mecanismo de sincronización.

Este documento técnico propone añadir al estándar basic_osyncstream que envuelva un flujo de datos al que transferirá datos cuando se llame su destructor, de esta manera garantiza que los datos se envíen al flujo incluso en presencia de una excepción.

Ejemplo.

{
    std::osyncstream bout(std::cout); // Sincronismo sobre cout
    bout << "Hola," << '\n';          // No hay vaciado
    bout.emit();                      // Se transfiere el contenido actual a cout
    bout << "Mundo!" << std::endl;    // vaciado solicitado, pero no se envia a cout
    bout.emit();                      // Se transfiere el contenido a cout, hay flush
    bout << "Saludetes." << '\n';     // No hay vaciado
} // Se transfiere el contenido automáticamente a cout, no hay vaciado

Constantes matemáticas estandarizadas (documento técnico P0631R5).

Las constantes matemáticas como π y e son usadas frecuentemente en algoritmos pero no existe una definición de las mismas en ninguna cabecera estandarizada. Son muy fáciles de definir, pero es tan extraño como hacer una reserva en un restaurante en el que te piden que traigas tu propio salero.

Para suplir esta carencia, este documento técnico propone crear una colección de variables plantilla con los valores de las constantes más usadas, por citar algunas:

namespace math {
template<typename T > inline constexpr T e_v = ...
template<typename T > inline constexpr T log2e_v = ...
template<typename T > inline constexpr T log10e_v = ...
template<typename T > inline constexpr T pi_v = ...
...
}

Ejemplo.

Con tan sólo incluir la cabecera <math> podremos usar estas constantes:

#include <math>

int main() {
    std::cout << "Pi es " << std::math::pi<long double> << " exactamente\n";
    return 0;
}

Co-rutinas (documento técnico N3985).

Según la Wikipedia una co-rutina es:

In a program, a coroutine is a unit of treatment similar to a subroutine, with the difference that, while the exit of a subroutine ends the subroutine, the exit of a coroutine can be the result of a suspension of its treatment until prompted to resume execution ( cooperative multitasking ). Suspending the coroutine and resuming it may be accompanied by a data transmission.

Several programming languages ​​support coroutines natively, this document proposes to make coroutines part of the C++ standard.