C++26 é reprovado na votação ISO por causa dos Contracts, testado no GCC 16

O rascunho do C++26, a próxima versão do padrão da linguagem C++, foi reprovado na votação ISO em outubro de 2026. A disputa que o derrubou gira em torno de um único recurso: os Contracts. O comitê do C++, chamado WG21, se reúne de 16 a 21 de novembro em Búzios, no Brasil. Lá, ele vai decidir se corta o recurso, se o move para fora ou se vota de novo. O resultado vai decidir se os programadores de C++ terão Contracts neste padrão.

O que aconteceu na votação do C++26

A votação era sobre o Draft International Standard, a última votação completa antes de a ISO publicar um padrão. O órgão de normalização de cada país vota. The Register relatou 13 votos a favor, 9 contra e 12 abstenções. A ISO não permite mais de 25% de votos negativos.

Outros relatos trazem uma contagem um pouco diferente. Um post de blog de Mond e uma análise da HFT University se baseiam em números publicados por Robert Seacord, membro do comitê. Segundo eles, 12 dos 20 membros com direito a voto aprovaram, abaixo dos 14 necessários para dois terços. Eles também dizem que 9 de 22 órgãos votaram não, quando no máximo 5 são permitidos. A HFT University observa que o resultado oficial ainda não é público. O post de Seacord foi direto: "A votação do C++26 terminou. Infelizmente, foi desaprovada."

A HFT University lista os países que votaram não:

Voto	Países
Não	Dinamarca, Finlândia, Irã, Itália, Japão, Luxemburgo, Romênia, Espanha, Suécia
Abstenção com comentários	França, Irlanda
Abstenção	Polônia, Estados Unidos

Por que órgãos nacionais votaram contra os Contracts

Os Contracts permitem escrever verificações na declaração de uma função. Uma pré-condição, escrita pre, diz o que deve ser verdade quando a função é chamada. Uma pós-condição, escrita post, diz o que deve ser verdade quando ela retorna. Uma instrução contract_assert verifica algo no meio do código.

Bjarne Stroustrup, criador do C++, lidera a oposição. "Os contracts do P2900 e suas extensões pretendem mudar a natureza do C++ e são uma ameaça existencial ao C++", disse ele, segundo o The Register. Andreas Fertig, membro do comitê, defendeu o design: "O tema foi trabalhado por anos e recebeu voto da maioria várias vezes em sua forma atual."

A análise de Mond diz que órgãos de pelo menos sete países pediram mudanças que foram rejeitadas. Alguns queriam remover os Contracts. Outros queriam verificações que não pudessem ser desligadas. Pelo menos quatro pediram que a biblioteca padrão reforçada, que adiciona verificações de segurança ao código da biblioteca, não dependesse dos Contracts. O comitê manteve esse vínculo.

O que o WG21 pode decidir em Búzios

O The Register lista três opções. O WG21 pode remover os Contracts para que o restante do C++26 seja lançado. Pode mover os Contracts para uma Technical Specification separada, um documento à parte, fora do padrão. Ou pode fazer uma revisão pequena e votar de novo.

Segundo Mond, dois artigos defendem cada lado. O P4433R0, "Do not remove Contracts from C++26", alerta que a remoção também exigiria reescrever o texto sobre o reforço da biblioteca. O D4420, "Do Remove Contracts From C++26", de Vinnie Falco, defende o contrário. Se o padrão atrasar, seu nome formal pode passar a ser ISO/IEC 14882:2027, segundo o The Register.

Testado: os Contracts do C++26 no GCC 16

A página de status do GCC lista os Contracts como disponíveis a partir do GCC 16. A página de status do Clang diz "No". Em um teste do Tech AI Wire no macOS 26 com GCC 16.2.0 em um contêiner Docker Linux ARM64, um pequeno programa chamou safe_div(10, 0) com esta verificação:

int safe_div(const int a, const int b)
    pre(b != 0)
    post(r: r * b <= a)
{
    return a / b;
}

Cada build usou g++ -std=c++26 -fcontracts -O2 mais um modo de -fcontract-evaluation-semantic=:

Modo	O que aconteceu em safe_div(10, 0)	Código de saída
enforce (padrão)	Exibiu a violação e depois abortou	134
observe	Exibiu a violação, continuou rodando, exibiu 0	0
quick_enforce	Abortou sem mensagem do contrato	134
ignore	Nenhuma verificação; exibiu 0	0

Os builds com ignore e observe exibiram 0 para 10 dividido por 0, uma resposta sem sentido. O relatório de violação mostra o arquivo, a linha e a condição: contract violation in function int safe_div(int, int) at contracts.cpp:4: b != 0.

Vale conhecer dois erros de build. A primeira tentativa usou int a, int b simples, e o GCC recusou: "a value parameter used in a postcondition must be const" (um parâmetro por valor usado em uma pós-condição deve ser const). Um build com -std=c++26, mas sem -fcontracts, compilou. Depois falhou na linkagem, com uma referência indefinida a handle_contract_violation.

O teste também contou as instruções de máquina da função compilada, só com a pré-condição. Um if (b == 0) std::abort(); escrito à mão usou 6 instruções. quick_enforce usou 11, e enforce, 15. Com -fno-contracts-conservative-ipa adicionado, caíram para 6 e 9. Segundo a documentação do GCC, essa opção controla se o compilador pode otimizar através do corpo de funções inline. A HFT University relatou o mesmo padrão em processadores x86.

O que isso significa para desenvolvedores

Não planeje ainda uma base de código em torno dos Contracts padrão. O recurso pode ser cortado, adiado ou alterado em Búzios, e o relatório do WG21 depois de 21 de novembro vai dizer qual dessas opções venceu. Código escrito hoje para a opção -fcontracts do GCC pode precisar de ajustes.

Se você testar o GCC 16 mesmo assim, escolha o modo de propósito. ignore e observe deixam o programa seguir após uma falha. Por isso servem para registro de logs, não para segurança. Marque os parâmetros como const quando uma pós-condição os ler. Compare quick_enforce com um if simples nos seus próprios caminhos críticos antes de confiar no custo dele. Se você depende do reforço da biblioteca, acompanhe se ele continua ligado aos Contracts depois da reunião.