Condição

Estamos trabalhando duro no Go 1.13, cujo lançamento, espero, ocorrerá no início de agosto deste ano. Este é o primeiro lançamento que incluirá alterações especificamente no idioma (e não apenas pequenas alterações na especificação) após uma longa moratória sobre essas alterações.

Para chegar a essas mudanças no idioma, começamos com várias propostas viáveis, selecionadas a partir de uma lista muito maior de ofertas Go 2 , de acordo com o novo processo de avaliação de proposta descrito no post " Go 2, aqui vamos nós !". Queríamos que a seleção inicial de propostas tivesse um papel relativamente pequeno e, na maioria das vezes, não causasse controvérsia, para que, com uma alta probabilidade, eles passassem por todo o processo. As alterações propostas precisavam ser compatíveis com versões anteriores para quebrar o mínimo possível, porque os módulos (que no futuro permitirão selecionar a versão do idioma para um módulo específico) ainda não são o modo de construção padrão. Resumidamente, a atual fase inicial das mudanças foi mais voltada para decolar e ganhar experiência, em vez de resolver grandes problemas.

Nossa lista inicial de frases - Unicode na forma geral em identificadores , literais inteiros binários , delimitadores de literais numéricos , deslocamento de bits por um número inteiro assinado - foi reduzida e expandida. A proposta de Unicode em termos gerais nos identificadores não sobreviveu à redução, porque não conseguimos elaborar um documento de design a tempo. A proposta de literais inteiros binários foi bastante expandida e levou a uma revisão abrangente e modernização da sintaxe dos literais numéricos Go. Também adicionamos uma proposta preliminar de verificação de erro do Go 2, que foi parcialmente aceita.

Dadas essas mudanças iniciais no Go 1.13, é hora de pensar no futuro do Go 1.14 e determinar o que queremos mudar a seguir.

Sugestões para o Go 1.14

As metas que definimos para o Go hoje são as mesmas de 2007: tornar o desenvolvimento de software escalável . Os três principais obstáculos para melhorar a escalabilidade do Go são a falta de um sistema de gerenciamento de pacotes e versões, suporte para um melhor sistema de tratamento de erros e genéricos.

Com a melhoria do sistema do módulo Go, o problema de gerenciar pacotes e versões está sendo resolvido. Permaneça aprimorado no tratamento de erros e genéricos. Nós trabalhamos nas duas questões e apresentamos os rascunhos dos documentos de design no GopherCon do ano passado, em Denver. Desde então, nós os aprimoramos gradualmente. No tratamento de erros, publicamos uma proposta significativamente revisada e simplificada (veja abaixo). Quanto aos genéricos, estamos trabalhando nisso: “Generics in Go”, de Ian Lance Taylor, fará um discurso sobre este tópico no GopherCon em San Diego este ano, mas ainda não chegamos ao estágio em que poderíamos fornecer uma proposta concreta.

Também queremos continuar a melhorar gradualmente o próprio idioma. Para o Go 1.14, selecionamos as seguintes ofertas:

# 32437 . A função interna de verificação de erros é "try" ( documento de design ).

Esta é a nossa sugestão para melhorar o tratamento de erros. Embora a extensão de idioma compatível com versões anteriores proposta seja pequena, esperamos um impacto significativo no código de tratamento de erros. Essa proposta já causou um grande número de comentários, e isso não é tão fácil de seguir. Recomendamos começar com o primeiro comentário para obter uma breve descrição e depois ler o documento de design detalhado. O primeiro comentário possui alguns links para um resumo das revisões. Por favor, siga as orientações de feedback (consulte a seção "Próximas etapas") antes de responder.

# 6977 . Permitir incorporação de interfaces sobrepostas ( documento de design ).

Essa é uma proposta antiga compatível com versões anteriores para tornar as interfaces de incorporação mais tolerantes.

# 32479 . Avise sobre a conversão da string(int) do formulário string(int) para go vet ao go vet .

Uma conversão da string(int) do formulário string(int) foi adicionada há muito tempo ao Go por conveniência, no entanto, confunde muito os iniciantes (a string(10) é "\n" , não "10" ) e não é mais justificada, pois agora a conversão está disponível no unicode/utf8 pacote unicode/utf8 . Como a exclusão dessa transformação não é uma alteração compatível com versões anteriores, sugerimos gerar um erro ao executar go vet .

# 32466 . Aceite os princípios de design de criptografia ( documento de design ).

Esta é uma solicitação de feedback para um conjunto de princípios de design de biblioteca criptográfica que gostaríamos de aceitar. Consulte também a sugestão correspondente para remover o suporte SSLv3 de crypto/tls .

Próximas etapas

Estamos coletando ativamente comentários sobre todas essas sugestões. Estamos especialmente interessados ​​em evidências que mostram por que a proposta pode não funcionar bem na prática ou em aspectos problemáticos que podemos ter esquecido no desenvolvimento. Exemplos convincentes em apoio a sugestões também são muito úteis. Por outro lado, comentários contendo apenas opiniões pessoais são menos eficazes: podemos levá-los em consideração, mas não podemos trabalhar construtivamente com eles. Antes de responder, reserve um momento para ler os documentos detalhados do projeto e as análises anteriores ou seu resumo. Seu tópico já pode ter sido levantado e discutido em comentários anteriores, especialmente durante longas discussões.

Se essas propostas não atenderem a problemas óbvios, planejamos implementar tudo no início do ciclo de desenvolvimento Go 1.14 (início de agosto de 2019), para que isso já possa ser avaliado na prática. De acordo com o processo de avaliação de propostas, a decisão final será tomada no final do ciclo de desenvolvimento (início de novembro de 2019).

Obrigado por ajudar a melhorar o idioma Go!

Robert Griesemer, para a equipe Go