O Comitê de Padrão do C ++ possui estatutos e regras, mas a maioria deles está centrada na estrutura da organização, como enviar propostas, votar, publicar o padrão etc., e não tanto nos detalhes técnicos do próprio padrão ou em como ele pode ser testado.
Não há nenhum requisito formal para "testar" um recurso ou seu design, até onde eu saiba. O C ++ também é um tanto único, pois não há referência ou implementação "primária" (por exemplo, Microsoft CLR, Oracle JDK, Zend PHP). No entanto, os membros do comitê consistem em muitas organizações com profundo conhecimento do idioma e da implementação do compilador. Por exemplo, se você seguir o link anterior, verá representantes da Microsoft e da Intel que possuem compiladores C ++ respeitados. A Red Hat e algumas outras empresas que contribuem para o GCC também estão envolvidas.
Ao propor um novo recurso, os membros do comitê já têm uma boa idéia de se é viável, se pode entrar em conflito com outros recursos ou fazer com que a gramática seja ambígua de uma maneira que complique a análise desnecessariamente. ( aqui está uma boa pergunta sobre a gramática do C ++ )
A resposta curta é "não, o comitê não exige testar seus projetos usando prototipagem". No entanto, não há muita necessidade, porque os membros do comitê são especialistas em C ++ que entendem todos os detalhes em um nível que a grande maioria dos programadores não. Lembre-se, essas pessoas são arquitetos de linguagem, especialistas em teoria da linguagem e design de compiladores.
Dado o envolvimento de fornecedores do compilador no processo, é possível que um ou mais deles podem protótipo de um novo recurso, mas, novamente, não há nenhuma exigência formal para isso nem é algo que eu tenho lido sobre em documentos publicamente disponíveis a partir do Comitê C ++.
Eles também tendem a ser muito conservadores, adicionando novos recursos de forma incremental que têm uma demanda no mundo real, sem especificar grandes quantidades de novos recursos que podem ser arriscados. De fato, nos últimos anos, eles adicionaram novos recursos que existiam como extensões proprietárias ou bibliotecas de código aberto que já funcionam no mundo real. Por exemplo, C ++ 11 e C ++ 14 incorporam partes do Boost , que já foram testadas no mundo real em vários compiladores e ambientes de execução. Não há necessidade de testar algo que já foi testado.