C++26 introduce contratos: pre y post condiciones en el lenguaje

C++26 Contracts: Introduction to Preconditions and Postconditions

C++26 introduce contratos: pre y post condiciones en el lenguaje

C++26 añade contratos con sintaxis pre() y post() para expresar precondiciones y postcondiciones directamente en la declaración de una función, visibles para quien lee la API. A diferencia de assert, los contratos ofrecen semánticas de evaluación (ignore, observe, enforce, quick-enforce) y no sirven para validar entradas. GCC 16 ya los soporta con -fcontracts.

Principio 12: Las aserciones de contrato no son control de flujo: aunque una aserción de contrato proporciona un algoritmo para validar la corrección, nada garantiza un comportamiento en tiempo de ejecución asociado a esa construcción sintáctica.
  1. cogman10

    No me gusta.

    Estoy totalmente a favor de suscribir un contrato si puede convertir un error en tiempo de ejecución en un error en tiempo de compilación. Sin embargo, esto parece que solo genera más errores en tiempo de ejecución. En ese punto, no parecen mejores que `assert`, excepto por el hecho de que prometen realmente afirmar (probablemente).

    El artículo también señala un gran problema, que es: "Es importante destacar que este aspecto de los Contratos es la razón por la que las aserciones de contrato no deben usarse para el manejo de errores y la validación de entrada: si una función tiene requisitos en el contrato para reportar ciertos eventos como errores, ese manejo debe hacerse con declaraciones de control estándar de C++ que no son opcionales, nunca con aserciones de contrato".

    Ese tipo de definición confusa de para qué se supone que sirven los contratos casi con certeza va a crear un desastre. No es validación de entrada, sino validación de parámetros... pero en realidad no validación, sino más bien comprobaciones que generan errores, pero no son errores los que estamos produciendo.

  2. WalterBright

    Solía ser un gran fan de los contratos, e incluso los implementé en el compilador Zortech C++ allá por los años 90:

    https://www.digitalmars.com/ctg/contract.html

    También lo implementé en D. Pero resultó que no era muy útil.

  3. ZuLuuuuuu

    Esto me recuerda el concepto de "Diseño por Contrato" del lenguaje de programación Eiffel:

    https://en.wikipedia.org/wiki/Design_by_contract

    https://www.eiffel.com/values/design-by-contract/introductio...

  4. Surac

    ¿Para qué sirven si no podemos validar la entrada con ellos? Una forma conveniente de escribir rangos de parámetros. Nada más.

  5. gavinray

    Dato curioso: escribí un plugin de compilador GCC hace años para agregar Contratos a C/C++ mientras esperaba que esto llegara al estándar

    https://gavinray97.github.io/blog/adding-invariant-to-cpp-de...

    El artículo resultó ser más útil como introducción a la escritura de plugins de GCC que cualquier otra cosa, pero al menos me divertí.

  6. tsukikage

    El artículo no menciona casos de uso de optimización. En caso de que alguien ya lo sepa de memoria y antes de que empiece a buscar la respuesta, ¿parte de la intención aquí es que estos informen a las etapas del optimizador, quizás de manera similar a lo que puede lograr el modismo `if (!(some_condition)) { __builtin_unreachable(); }`?

  7. MetaverseClub

    Me pregunto cuáles son los casos de uso que tienen en mente al diseñar esto.

    Para aserciones en tiempo de ejecución y documentación, sí, funcionaría, pero funciona sin contrato, discutiblemente bien.

    Para verificación formal, el diseño está muy equivocado.

  8. randyrand

    Quizás sea solo yo, pero los lenguajes enormes y complicados como C++ parecen tan poco atractivos como siempre.

    Si voy a escribir código a mano, el requisito de un lenguaje bello y agradable es más grande que nunca.

Más de este día

2026-10-15