C++26 atingiu um obstáculo. Uma funcionalidade é a culpada

A jornada do C++26 rumo à padronização atingiu um obstáculo sem precedentes em 24 de outubro de 2026. O rascunho falhou na votação do ISO Draft International Standard (DIS), marcando a primeira vez que um padrão C++ foi reprovado nesta etapa crítica. Esta votação de tudo ou nada exigia que os órgãos membros aprovassem o rascunho completo, não funcionalidades individuais.

Os resultados da votação foram claros: entre os membros participantes, apenas 60% (12 de 20) votaram sim, ficando abaixo da maioria de dois terços necessária. Além disso, 9 dos 22 órgãos membros votaram "Não", excedendo o limite de 25% permitido para reprovação, atingindo alarmantes 41%. Isso não foi um cancelamento do C++ ou uma rejeição total de todas as funcionalidades do C++26; foi um sinal negativo decisivo para todo o pacote, impulsionado por profundas divergências sobre uma única proposta controversa.

Este resultado confirma que os órgãos nacionais não são meros carimbadores. A reprovação significa que o padrão C++26, como redigido, não prosseguirá. A comunidade agora enfrenta a tarefa complexa de reavaliar e revisar o rascunho, potencialmente atrasando o lançamento significativamente.

Contracts, as verificações de tempo de execução propostas para o C++26, tornaram-se o ponto de ruptura indiscutível. Esta funcionalidade, detalhada no P2900, visava introduzir preconditions, postconditions e assertions nativas diretamente na linguagem, permitindo que os desenvolvedores especifiquem estados e comportamentos esperados do programa.

Esta não foi uma adição menor; apenas os Contracts aumentaram o rascunho do padrão em aproximadamente 56 páginas. A proposta especificava quatro modos de avaliação definidos pela implementação: ignore, observe, enforce e quick-enforce. Essa flexibilidade, destinada a se adaptar a vários cenários de implantação, alimentou, em vez disso, uma oposição significativa.

Críticos, incluindo o criador do C++, Bjarne Stroustrup, viam os Contracts como um design grande e incompleto, repleto de perigos. Eles argumentaram que isso introduzia complexidade desnecessária, novos caminhos para undefined behavior e uma falha fundamental de design: verificações em tempo de execução que poderiam ser (e provavelmente seriam) desativadas em builds de produção. Isso, argumentaram, minava o princípio de zero-overhead do C++ e oferecia uma solução dos anos 1980 para um problema melhor resolvido por análise estática moderna.

Bjarne Stroustrup, o criador do C++, não apenas não gostou dos Contracts; ele ajudou a liderar a investida contra eles. Em agosto, Stroustrup e quatro coautores — J. Daniel Garcia, Vinnie Falco, John Spicer e Ville Voutilainen — publicaram o P4334R0, “P2900 Contracts' Fundamental Flaws.” Este documento chamou a proposta de “ameaça existencial ao C++” e descartou sua abordagem como uma “abordagem dos anos 1980 que ignora cerca de 50 anos de progresso.”

A divisão central de design é clara. Críticos, incluindo Stroustrup, defendem uma análise estática coerente e garantias de segurança robustas, argumentando que verificações apenas em tempo de execução violam o princípio de zero-overhead do C++ ao serem removidas de builds de produção. Eles também argumentaram que a proposta introduzia novos riscos de undefined behavior e modelos de herança não comprovados.

Os apoiadores, no entanto, veem os contratos em tempo de execução como uma ferramenta prática e imediatamente útil para expressar e verificar suposições de programas, uma funcionalidade necessária para o desenvolvimento moderno. Para mais informações sobre a proposta, veja P2900: Contracts for C++.

O contra-argumento à preocupação de Stroustrup sobre o zero-overhead é igualmente convincente: um processo de padronização funcional deveria examinar uma proposta tão profundamente, em vez de apenas aprovar automaticamente um compromisso de comitê. A rejeição do C++26 prova que os órgãos nacionais estão atentos, garantindo que novos recursos atinjam o mais alto nível, mesmo que isso atrase o padrão. Não se trata apenas de Contracts; trata-se da integridade de todo o processo de padronização.

A natureza de tudo ou nada da votação do C++26 significa que os Contracts não falharam sozinhos; eles levaram todo o padrão com eles. Recursos altamente aguardados, como static reflection e std::execution, agora definham no limbo. Esse dano colateral é uma pílula amarga para uma comunidade ansiosa por progresso.

Este impasse surge à medida que o C++ enfrenta um escrutínio crescente para melhorar a segurança e a confiabilidade do software. Linguagens concorrentes como Rust e Swift oferecem garantias de segurança de memória e modelos de concorrência robustos, pressionando o Comitê de Padrões C++ a evoluir. A indústria exige mais do que apenas desempenho; ela exige correção comprovável.

Agora, o comitê deve traçar um curso difícil. As opções incluem revisar os comentários nacionais e abordar as preocupações, ou, de forma mais drástica, remover Contracts inteiramente para salvar o cronograma. Um compromisso mais restrito pode surgir, mas o caminho final e seu cronograma permanecem profundamente incertos. Esta votação prova que um único recurso pode, de fato, atrasar tudo.

Por que o rascunho do C++26 falhou em sua votação ISO?

O rascunho não atingiu o limite de aprovação necessário e excedeu a parcela permitida de votos negativos. A discordância sobre a proposta de Contracts foi amplamente vista como a causa central.

O que são Contracts em C++?

Contracts são recursos de linguagem propostos para expressar pré-condições, pós-condições e asserções que podem ser verificadas em tempo de execução.

A votação rejeitou todos os recursos do C++26?

A votação cobriu o rascunho completo do padrão, portanto, o rascunho falhou como um todo. As objeções descritas na fonte focaram principalmente em Contracts, não em todos os recursos do C++26.

O que acontece com o C++26 após a votação fracassada?

O comitê deve revisar os comentários dos órgãos nacionais e decidir se remove os Contracts, revisa a proposta ou segue outro caminho. O cronograma de lançamento é incerto.