CL https://golang.org/cl/22057 menciona esse problema.

Deixe-me lembrar preventivamente a todos da nossa política https://golang.org/wiki/NoMeToo . A festa emoji está acima.

Há o Resumo das Discussões Genéricas do Go , que tenta fornecer uma visão geral das discussões de diferentes lugares. Ele também fornece alguns exemplos de como resolver problemas, onde você gostaria de usar genéricos.

Existem dois "requisitos" na proposta vinculada que podem complicar a implementação e reduzir a segurança do tipo:

• Defina tipos genéricos com base em tipos que não são conhecidos até que sejam instanciados.
• Não exija um relacionamento explícito entre a definição de um tipo ou função genérica e seu uso. Ou seja, os programas não deveriam ter que dizer explicitamente que o tipo T implementa G genérico.

Esses requisitos parecem excluir, por exemplo, um sistema semelhante ao sistema de traços de Rust, onde tipos genéricos são restringidos por limites de traços. Por que eles são necessários?

Torna-se tentador construir genéricos na biblioteca padrão em um nível muito baixo, como em C++ std::basic_string, std::alocador>. Isso tem seus benefícios - caso contrário ninguém faria isso - mas tem efeitos abrangentes e às vezes surpreendentes, como em mensagens de erro C++ incompreensíveis.

O problema em C++ surge do código gerado pela verificação de tipo. É necessário haver uma verificação de tipo adicional antes da geração do código. A proposta de conceitos de C++ possibilita isso ao permitir que o autor do código genérico especifique os requisitos de um tipo genérico. Dessa forma, a compilação pode falhar na verificação de tipo antes da geração de código e mensagens de erro simples podem ser impressas. O problema com os genéricos de C++ (sem conceitos) é que o código genérico _é_ a especificação do tipo genérico. É isso que cria as mensagens de erro incompreensíveis.

O código genérico não deve ser a especificação de um tipo genérico.

@tamird É uma característica essencial dos tipos de interface do Go que você pode definir um tipo de interface não T e depois definir um tipo de interface I tal que T implemente I. Veja https://golang.org/doc/faq#implements_interface . Seria inconsistente se Go implementasse uma forma de genéricos para os quais um tipo genérico G só pudesse ser usado com um tipo T que dissesse explicitamente "Eu posso ser usado para implementar G".

Não estou familiarizado com Rust, mas não conheço nenhuma linguagem que exija que T declare explicitamente que pode ser usado para implementar G. Os dois requisitos que você mencionou não significam que G não possa impor requisitos a T, apenas como I impõe requisitos em T. Os requisitos apenas significam que G e T podem ser escritos independentemente. Esse é um recurso altamente desejável para genéricos, e não consigo imaginar abandoná-lo.

@ianlancetaylor https://doc.rust-lang.org/book/traits.html explica os traços de Rust. Embora eu ache que eles são um bom modelo em geral, eles seriam um mau ajuste para o Go como existe hoje.

@sbunce Eu também pensei que os conceitos fossem a resposta, e você pode ver a ideia espalhada pelas várias propostas antes da última. Mas é desencorajador que os conceitos tenham sido originalmente planejados para o que se tornou o C++11, e agora estamos em 2016, e ainda são controversos e não estão particularmente próximos de serem incluídos na linguagem C++.

Haveria valor na literatura acadêmica para qualquer orientação sobre a avaliação de abordagens?

O único artigo que li sobre o assunto é Os desenvolvedores se beneficiam de tipos genéricos? (paywall desculpe, você pode pesquisar no Google seu caminho para um download de pdf) que tinha o seguinte a dizer

Consequentemente, uma interpretação conservadora do experimento
é que os tipos genéricos podem ser considerados como uma compensação
entre as características positivas da documentação e a
características de extensibilidade negativa. A parte emocionante de
o estudo é que mostrou uma situação em que o uso de um
sistema de tipo estático (mais forte) teve um impacto negativo na
tempo de desenvolvimento e, ao mesmo tempo, o benefício esperado
fit – a redução do tempo de correção do erro de tipo – não apareceu.
Achamos que tais tarefas podem ajudar em experimentos futuros em
identificar o impacto dos sistemas de tipo.

Eu também vejo https://github.com/golang/go/issues/15295 também faz referência a genéricos orientados a objetos leves e flexíveis .

Se fôssemos nos apoiar na academia para orientar a decisão, acho que seria melhor fazer uma revisão de literatura inicial e provavelmente decidir cedo se pesaríamos os estudos empíricos de maneira diferente daqueles que se baseiam em provas.

Por favor, veja: http://dl.acm.org/citation.cfm?id=2738008 por Barbara Liskov:

O suporte para programação genérica em linguagens de programação orientadas a objetos modernas é estranho e carece de poder expressivo desejável. Introduzimos um mecanismo de generalidade expressivo que adiciona poder expressivo e fortalece a verificação estática, mantendo-se leve e simples em casos de uso comuns. Como classes e conceitos de tipo, o mecanismo permite que tipos existentes modelem restrições de tipo retroativamente. Para poder expressivo, expomos modelos como construções nomeadas que podem ser definidas e selecionadas explicitamente para testemunhar restrições; em usos comuns de genericidade, no entanto, os tipos testemunham implicitamente as restrições sem esforço adicional do programador.

Eu acho que o que eles fizeram lá é muito legal - desculpe se este é o lugar incorreto para parar, mas não consegui encontrar um lugar para comentar em /propostas e não encontrei um problema apropriado aqui.

Pode ser interessante ter um ou mais transpiladores experimentais - um compilador de código-fonte Go genéricos para Go 1.xy.
Quero dizer - muita conversa/argumentos-para-minha-opinião, e ninguém está escrevendo código-fonte que _tenta_ implementar _algum tipo_ de genéricos para Go.

Apenas para obter conhecimento e experiência com Go e genéricos - para ver o que funciona e o que não funciona.
Se todas as soluções genéricas Go não forem realmente boas, então; Não há genéricos para Go.

A proposta também pode incluir as implicações no tamanho do binário e no consumo de memória? Eu esperaria que houvesse duplicação de código para cada tipo de valor concreto para que as otimizações do compilador funcionassem neles. Espero uma garantia de que não haverá duplicação de código para tipos de ponteiro concretos.

Eu ofereço uma matriz de decisão de Pugh. Meus critérios incluem impactos de perspicuidade (complexidade da fonte, tamanho). Eu também forcei os critérios de classificação para determinar os pesos dos critérios. O seu pode variar, é claro. Eu usei "interfaces" como a alternativa padrão e comparei isso com genéricos de "copiar/colar", genéricos baseados em modelo (eu tinha em mente algo parecido com o funcionamento da linguagem D) e algo que chamei de genéricos de estilo de instanciação de tempo de execução. Tenho certeza de que isso é uma grande simplificação. No entanto, pode gerar algumas ideias sobre como avaliar as escolhas... este deve ser um link público para minha Planilha Google, aqui

Fazer um ping em @yizhouzhang e @andrewcmyers para que eles possam expressar suas opiniões sobre gêneros como genéricos em Go. Parece que pode ser uma boa combinação :)

O design genérico que criamos para o Genus tem verificação de tipo estático e modular, não requer pré-declaração de que os tipos implementam alguma interface e vem com desempenho razoável. Eu definitivamente olharia para isso se você estiver pensando em genéricos para Go. Parece um bom ajuste do meu entendimento de Go.

Aqui está um link para o artigo que não requer acesso à Biblioteca Digital ACM:
http://www.cs.cornell.edu/andru/papers/genus/

A página inicial do Genus está aqui: http://www.cs.cornell.edu/projects/genus/

Ainda não lançamos o compilador publicamente, mas planejamos fazê-lo em breve.

Feliz em responder a quaisquer perguntas que as pessoas tenham.

Em termos da matriz de decisão do @mandolyte , Genus pontua 17, empatado em #1. Eu acrescentaria mais alguns critérios para pontuar, no entanto. Por exemplo, a verificação de tipo modular é importante, como outros, como @sbunce , observados acima, mas os esquemas baseados em modelo não têm. O relatório técnico do documento Genus tem uma tabela muito maior na página 34, comparando vários designs genéricos.

Acabei de ler todo o documento Summary of Go Generics , que foi um resumo útil das discussões anteriores. O mecanismo de genéricos em Genus, a meu ver, não sofre dos problemas identificados para C++, Java ou C#. Os genéricos de gênero são reificados, diferentemente do Java, para que você possa descobrir os tipos em tempo de execução. Você também pode instanciar em tipos primitivos, e você não obtém boxing implícito nos lugares que você realmente não quer: arrays de T onde T é um primitivo. O sistema de tipos é o mais próximo de Haskell e Rust -- na verdade um pouco mais poderoso, mas acho que também é intuitivo. A especialização primitiva ala C# não é suportada atualmente no gênero, mas poderia ser. Na maioria dos casos, a especialização pode ser determinada no tempo do link, portanto, a geração de código em tempo de execução verdadeiro não seria necessária.

CL https://golang.org/cl/22163 menciona esse problema.

Uma maneira de restringir tipos genéricos que não requer a adição de novos conceitos de linguagem: https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing.

Genus parece muito legal e é claramente um avanço importante da arte, mas não vejo como isso se aplicaria ao Go. Alguém tem um esboço de como ele se integraria ao sistema/filosofia do tipo Go?

A questão é que a equipe de go está tentando impedir. O título afirma claramente as intenções da equipe go. E se isso não bastasse para deter todos os compradores, as características exigidas de um domínio tão amplo nas propostas de ian deixam claro que se você quer genéricos, eles não querem você. É estúpido até mesmo tentar dialogar com a equipe de go. Para quem procura genéricos em go, digo fraturar a linguagem. Comece uma nova jornada - muitos se seguirão. Eu já vi ótimos trabalhos feitos em forks. Organizem-se, juntem-se a uma causa

Se alguém quiser tentar desenvolver uma extensão genérica para Go com base no design Genus, ficaremos felizes em ajudar. Não conhecemos o Go o suficiente para produzir um design que se harmonize com a linguagem existente. Acho que o primeiro passo seria uma proposta de design do espantalho com exemplos elaborados.

@andrewcmyers esperando que @ianlancetaylor trabalhe com você nisso. Apenas ter alguns exemplos para olhar ajudaria muito.

Eu li o jornal Genus. Até onde eu entendo, parece bom para Java, mas não parece ser um ajuste natural para Go.

Um aspecto chave do Go é que quando você escreve um programa Go, a maior parte do que você escreve é ​​código. Isso é diferente de C++ e Java, onde muito mais do que você escreve são tipos. Gênero parece ser principalmente sobre tipos: você escreve restrições e modelos, em vez de código. O sistema de tipos de Go é muito simples. O sistema de tipos de Genus é muito mais complexo.

As idéias de modelagem retroativa, embora claramente úteis para Java, não parecem se encaixar em Go. As pessoas já usam tipos de adaptadores para combinar tipos existentes com interfaces; nada mais deve ser necessário ao usar genéricos.

Seria interessante ver essas ideias aplicadas ao Go, mas não estou otimista quanto ao resultado.

Eu não sou um especialista em Go, mas seu sistema de tipos não parece mais simples do que o Java pré-genérico. A sintaxe de tipo é um pouco mais leve de uma maneira agradável, mas a complexidade subjacente parece a mesma.

No Genus, as restrições são tipos, mas os modelos são códigos. Os modelos são adaptadores, mas se adaptam sem adicionar uma camada de embalagem real. Isso é muito útil quando você deseja, digamos, adaptar uma matriz inteira de objetos a uma nova interface. A modelagem retroativa permite tratar a matriz como uma matriz de objetos que satisfaz a interface desejada.

Eu não ficaria surpreso se fosse mais complicado do que Java (pré-genéricos) em um sentido teórico de tipos, embora seja mais simples de usar na prática.

Complexidade relativa à parte, eles são diferentes o suficiente para que Genus não consiga mapear 1:1. Nenhuma subtipagem parece ser grande.

Se você está interessado:

O resumo mais breve das diferenças filosóficas/de design relevantes que mencionei está contido nas seguintes entradas de perguntas frequentes:

• https://golang.org/doc/faq#implements_interface
• https://golang.org/doc/faq#overloading
• https://golang.org/doc/faq#covariant_types
• https://golang.org/doc/faq#variant_types

Ao contrário da maioria das linguagens, a especificação Go é muito curta e clara sobre as propriedades relevantes do sistema de tipos, começando em https://golang.org/ref/spec#Constants e indo direto até a seção intitulada "Blocks" (todos os quais é inferior a 11 páginas impressas).

Ao contrário dos genéricos Java e C#, o mecanismo Genus genéricos não é baseado em subtipagem. Por outro lado, parece-me que Go tem subtipagem, mas subtipagem estrutural. Essa também é uma boa combinação para a abordagem Genus, que tem um sabor estrutural em vez de depender de relacionamentos pré-declarados.

Não acredito que Go tenha subtipagem estrutural.

Enquanto dois tipos cujo tipo subjacente é idêntico são, portanto, idênticos
podem ser substituídos um pelo outro, https://play.golang.org/p/cT15aQ-PFr

Isso não se estende a dois tipos que compartilham um subconjunto comum de campos,
https://play.golang.org/p/KrC9_BDXuh.

Na quinta-feira, 28 de abril de 2016 às 13h09, Andrew Myers [email protected]
escreveu:

Ao contrário dos genéricos Java e C#, o mecanismo Genus genéricos não é baseado em
subtipagem. Por outro lado, parece-me que Go tem subtipagem,
mas subtipagem estrutural. Essa também é uma boa combinação para a abordagem Genus,
que tem um sabor estrutural em vez de depender de pré-declarados
relacionamentos.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment -215298127

Obrigado, eu estava interpretando mal parte da linguagem sobre quando os tipos implementam interfaces. Na verdade, parece-me que as interfaces Go, com uma extensão modesta, poderiam ser usadas como restrições de estilo Genus.

É exatamente por isso que eu dei um ping em você, o gênero parece uma abordagem muito melhor do que os genéricos do Java/C #.

Houve algumas ideias com relação à especialização nos tipos de interface; por exemplo, a abordagem _package templates_ "propostas" 1 2 são exemplos disso.

tl;dr; o pacote genérico com especialização de interface ficaria assim:

package set
type E interface { Equal(other E) bool }
type Set struct { items []E }
func (s *Set) Add(item E) { ... }

Versão 1. com especialização no escopo do pacote:

package main
import items set[[E: *Item]]

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs items.Set
xs.Add(&Item{})

Versão 2. a especialização no escopo da declaração:

package main
import set

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs set.Set[[E: *Item]]
xs.Add(&Item{})

Os genéricos no escopo do pacote impedirão que as pessoas abusem significativamente do sistema de genéricos, uma vez que o uso é limitado a algoritmos básicos e estruturas de dados. Basicamente, impede a construção de novas abstrações de linguagem e código funcional.

A especialização com escopo de declaração tem mais possibilidades ao custo, tornando-a mais propensa a abusos e é mais detalhada. Mas, código funcional seria possível, por exemplo:

type E interface{}
func Reduce(zero E, items []E, fn func(a, b E) E) E { ... }

Reduce[[E: int]](0, []int{1,2,3,4}, func(a, b int)int { return a + b } )
// there are probably ways to have some aliases (or similar) to make it less verbose
alias ReduceInt Reduce[[E: int]]
func ReduceInt Reduce[[E: int]]

A abordagem de especialização de interface tem propriedades interessantes:

• Pacotes já existentes usando interfaces seriam especializados. por exemplo, eu seria capaz de chamar sort.Sort[[Interface:MyItems]](...) e fazer a classificação funcionar no tipo concreto em vez da interface (com ganhos potenciais de inlining).
• O teste é simplificado, só tenho que garantir que o código genérico funcione com interfaces.
• É fácil dizer como funciona. ou seja, imagine que [[E: int]] substitui todas as declarações de E por int .

Mas, há problemas de detalhamento ao trabalhar em pacotes:

type op
import "set"

type E interface{}
func Union(a, b set.Set[[set.E: E]]) set.Set[[set.E: E]] {
    result := set.New[[set.E: E]]()
    ...
}

_Claro, a coisa toda é mais simples de declarar do que de implementar. Internamente, provavelmente existem muitos problemas e maneiras de como isso pode funcionar._

_PS, para os resmungos sobre o progresso lento dos genéricos, eu aplaudo o Go Team por gastar mais tempo em questões que têm um benefício maior para a comunidade, por exemplo, bugs do compilador/tempo de execução, SSA, GC, http2._

@egonelbre seu ponto de que os genéricos no nível do pacote impedirão o "abuso" é realmente importante que acho que a maioria das pessoas ignora. Isso, além de sua relativa simplicidade semântica e sintática (somente as construções package e import são afetadas) os tornam muito atraentes para o Go.

@andrewcymyers interessante que você acha que as interfaces Go funcionam como restrições no estilo Genus. Eu teria pensado que eles ainda têm o problema de que você não pode expressar restrições de parâmetros de vários tipos com eles.

Uma coisa que acabei de perceber, no entanto, é que em Go você pode escrever uma interface inline. Portanto, com a sintaxe correta, você pode colocar a interface no escopo de todos os parâmetros e capturar restrições de vários parâmetros:

tipo [V, E] Gráfico [V interface { Edges() E }, E interface { Endpoints() (V, V) }] ...

Acho que o maior problema com interfaces como restrições é que os métodos não são tão difundidos em Go quanto em Java. Tipos internos não possuem métodos. Não existe um conjunto de métodos universais como aqueles em java.lang.Object. Os usuários normalmente não definem métodos como Equals ou HashCode em seus tipos, a menos que precisem especificamente, porque esses métodos não qualificam um tipo para uso como chaves de mapa ou em qualquer algoritmo que precise de igualdade.

(Igualdade em Go é uma história interessante. A linguagem fornece seu tipo "==" se atender a determinados requisitos (consulte https://golang.org/ref/spec#Logical_operators, procure por "comparable"). Qualquer tipo com " ==" pode servir como uma chave de mapa. Mas se seu tipo não merecer "==", então não há nada que você possa escrever que faça funcionar como uma chave de mapa.)

Como os métodos não são difundidos e não há uma maneira fácil de expressar as propriedades dos tipos internos (como os operadores com os quais eles trabalham), sugeri usar o próprio código como o mecanismo de restrição genérico. Veja o link no meu comentário de 18 de abril, acima. Esta proposta tem seus problemas, mas um bom recurso é que o código numérico genérico ainda pode usar os operadores usuais, em vez de chamadas de método complicadas.

A outra maneira é adicionar métodos a tipos que não os possuem. Você pode fazer isso na linguagem existente de uma maneira muito mais leve do que em Java:

digite Int int
func (i Int) Less(j Int) bool { return i < j }

O tipo Int "herda" todos os operadores e outras propriedades de int. Embora você tenha que lançar entre os dois para usar Int e int juntos, o que pode ser uma dor.

Modelos de gênero podem ajudar aqui. Mas eles teriam que ser mantidos muito simples. Acho que @ianlancetaylor foi muito estreito em sua caracterização de Go como escrevendo mais código, menos tipos. O princípio geral é que Go abomina a complexidade. Nós olhamos para Java e C++ e estamos determinados a nunca ir lá. (Sem ofensa.)

Portanto, uma ideia rápida para um recurso semelhante a um modelo seria: fazer com que o usuário escreva tipos como Int acima e, em instanciações genéricas, permita "int com Int", o que significa usar o tipo int, mas tratá-lo como Int. Então não há nenhuma construção de linguagem aberta chamada modelo, com sua palavra-chave, semântica de herança e assim por diante. Não entendo os modelos bem o suficiente para saber se isso é viável, mas está mais no espírito do Go.

@jba Certamente concordamos com o princípio de evitar complexidade. "O mais simples possível, mas não mais simples." Eu provavelmente deixaria alguns recursos do Genus fora do Go por esses motivos, pelo menos no começo.

Uma das coisas boas sobre a abordagem Genus é que ela lida com tipos internos sem problemas. Lembre-se de que tipos primitivos em Java não possuem métodos, e Genus herda esse comportamento. Em vez disso, Genus trata tipos primitivos _como se_ eles tivessem um conjunto bastante grande de métodos com o propósito de satisfazer restrições. Uma tabela de hash requer que suas chaves possam ser criptografadas e comparadas, mas todos os tipos primitivos satisfazem essa restrição. Portanto, instanciações de tipo como Map[int, boolean] são perfeitamente legais sem maiores problemas. Não há necessidade de distinguir entre dois tipos de inteiros (int vs Int) para conseguir isso. No entanto, se o int não estivesse equipado com operações suficientes para alguns usos, usaríamos um modelo quase exatamente como o uso do Int acima.

Outra coisa que vale a pena mencionar é a ideia de "modelos naturais" em Genus. Normalmente, você não precisa declarar um modelo para usar um tipo genérico: se o argumento de tipo satisfizer a restrição, um modelo natural será gerado automaticamente. Nossa experiência é que este é o caso usual; declarar modelos nomeados explícitos normalmente não é necessário. Mas se um modelo for necessário - por exemplo, se você quiser hash ints de uma maneira não padrão - a sintaxe será semelhante à que você sugeriu: Map[int with fancyHash, boolean] . Eu diria que Genus é sintaticamente leve em casos de uso normal, mas com energia de reserva quando necessário.

@egonelbre O que você está propondo aqui se parece com tipos virtuais, que são suportados pelo Scala. Há um artigo do ECOOP'97 de Kresten Krab Thorup, "Genericidade em Java com tipos virtuais", que explora essa direção. Também desenvolvemos mecanismos para tipos virtuais e classes virtuais em nosso trabalho ("J&: nested interseção para composição de software escalável", OOPSLA'06).

Como as inicializações literais são difundidas em Go, tive que me perguntar como seria uma função literal. Eu suspeito que o código para lidar com isso existe em grande parte em Go gerar, corrigir e renomear. Talvez inspire alguém :-)

// a definição do tipo de função (genérica)
digite Sum64 func (X, Y) float64 {
return float64(X) + float64(Y)
}

// instancia um, posicionalmente
eu := 42
var j uint = 86
soma := &Soma64{i, j}

// instancia um, por tipos de parâmetros nomeados
soma := &Soma64{ X: int, Y: uint}

// agora use...
resultado := soma(i, j) // resultado é 128

A proposta de Ian exige demais. Não podemos desenvolver todos os recursos de uma só vez, ele existirá em um estado inacabado por muitos meses.

Enquanto isso, o projeto inacabado não pode ser chamado de idioma oficial do Go até que seja concluído, porque isso corre o risco de fragmentar o ecossistema.

Então a questão é como planejar isso.

Também uma grande parte do projeto seria desenvolver o corpus de referência.
desenvolver as coleções genéricas reais, algoritmos e outras coisas de tal forma que todos concordamos que eles são idiomáticos, enquanto usamos os novos recursos do go 2.0

Uma sintaxe possível?

// Module defining generic type
module list(type t)

type node struct {
    next *node
    data t
}

// Module using generic type:
import (
    intlist "module/path/to/list" (int)
    funclist "module/path/to/list" (func (int) int)
)

l := intlist.New()
l.Insert(5)

@md2perpe , a sintaxe não é a parte difícil deste problema. Na verdade, é de longe o mais fácil. Por favor, veja a discussão e os documentos vinculados acima.

@md2perpe Discutimos a parametrização de pacotes inteiros ("módulos") como uma maneira de generalidade interna - parece ser uma maneira de reduzir a sobrecarga sintática. Mas tem outros problemas; por exemplo, não está claro como parametrizá-lo com tipos que não são de nível de pacote. Mas a ideia ainda pode valer a pena explorar em detalhes.

Eu gostaria de compartilhar uma perspectiva: em um universo paralelo, todas as assinaturas de função Go sempre foram restritas a mencionar apenas tipos de interface e, em vez de demanda por genéricos hoje, há uma maneira de evitar a indireção associada aos valores de interface. Pense em como você resolveria esse problema (sem alterar o idioma). Eu tenho algumas ideias.

@thwd Assim, o autor da biblioteca continuaria usando interfaces, mas sem a troca de tipo e as asserções de tipo necessárias hoje. E o usuário da biblioteca simplesmente passaria tipos concretos como se a biblioteca fosse usar os tipos como estão... e então o compilador reconciliaria os dois? E se não pudesse dizer por quê? (como o operador módulo foi usado na biblioteca, mas o usuário forneceu uma fatia de algo.

Estou perto? :-)

@mandolyte sim! vamos trocar e-mails para não poluir este tópico. Você pode me alcançar em "me at thwd dot me". Qualquer outra pessoa lendo isso que possa estar interessada; me mande um e-mail e eu te adiciono ao tópico.

É um ótimo recurso para type system e collection library .
Uma sintaxe potencial:

type Element<T> struct {
    prev, next *Element<T>
    list *List<T>
    value T
}
type List<E> struct {
    root Element<E>
    len int
}

Por interface

type Collection<E> interface {
    Size() int
    Add(e E) bool
}

super type ou type implement :

func contain(l List<parent E>, e E) bool
<V> func (c Collection<child E>)Map(fn func(e E) V) Collection

O acima também conhecido em java:

boolean contain(List<? super E>, E e)
<V> Collection Map(Function<? extend E, V> mapFunc);

@leaxoy como dito antes, a sintaxe não é a parte difícil aqui. Veja discussão acima.

Apenas esteja ciente de que o custo da interface é incrivelmente grande.

Por favor, explique por que você acha que o custo da interface é "inacreditavelmente"
ampla.
Não deve ser pior do que as chamadas virtuais não especializadas do C++.

@minux não posso falar sobre os custos de desempenho, mas em relação à qualidade do código. interface{} não pode ser verificado em tempo de compilação, mas os genéricos podem. Na minha opinião, isso é, na maioria dos casos, mais importante do que os problemas de desempenho de usar interface{} .

@xoviat

Não há realmente nenhuma desvantagem nisso porque o processamento necessário para isso não diminui a velocidade do compilador.

Existem (pelo menos) duas desvantagens.

Um é o aumento do trabalho para o vinculador: se as especializações para dois tipos resultarem no mesmo código de máquina subjacente, não queremos compilar e vincular duas cópias desse código.

Outra é que os pacotes parametrizados são menos expressivos que os métodos parametrizados. (Veja as propostas vinculadas no primeiro comentário para detalhes.)

O tipo hiper é uma boa ideia?

func getAddFunc (aType type) func(aType, aType) aType {
    return func(a, b aType) aType {
        return a+b
    }
}

O tipo hiper é uma boa ideia?

O que você está descrevendo aqui é apenas parametrização de tipo ala C++ (ou seja, templates). Ele não verifica o tipo de maneira modular porque não há como saber se o tipo aType tem uma operação + a partir das informações fornecidas. Parametrização de tipo restrito como em CLU, Haskell, Java, Genus é a solução.

@golang101 Tenho uma proposta detalhada nesse sentido. Enviarei um CL para adicioná-lo à lista, mas dificilmente será adotado.

CL https://golang.org/cl/38731 menciona esse problema.

@andrewcmyers

Ele não verifica o tipo de maneira modular porque não há como saber se o tipo aType tem uma operação + a partir das informações fornecidas.

Claro que existe. Essa restrição está implícita na definição da função e as restrições dessa forma podem ser propagadas para todos os chamadores (transitivos) de tempo de compilação de getAddFunc .

A restrição não faz parte de um Go _type_ — ou seja, não pode ser codificada no sistema de tipos da parte de tempo de execução da linguagem — mas isso não significa que não possa ser avaliada de forma modular.

Adicionada minha proposta como 2016-09-compile-time-functions.md .

Não espero que seja adotado, mas pode pelo menos servir como um ponto de referência interessante.

@bcmills Eu sinto que as funções de tempo de compilação são uma ideia poderosa, além de qualquer consideração de genéricos. Por exemplo, eu escrevi um solucionador de sudoku que precisa de um popcount. Para acelerar isso, pré-calculei os popcounts para os vários valores possíveis e armazenei-os como Go source . Isso é algo que se pode fazer com go:generate . Mas se houvesse uma função de tempo de compilação, essa tabela de pesquisa também poderia ser calculada em tempo de compilação, evitando que o código gerado pela máquina tivesse que ser confirmado no repositório. Em geral, qualquer tipo de função matemática memoizável é um bom ajuste para tabelas de pesquisa pré-fabricadas com funções de tempo de compilação.

Mais especulativamente, pode-se também querer, por exemplo, baixar uma definição de protobuf de uma fonte canônica e usá-la para construir tipos em tempo de compilação. Mas talvez isso seja demais para ser permitido em tempo de compilação?

Eu sinto que as funções de tempo de compilação são muito poderosas e muito fracas ao mesmo tempo: elas são muito flexíveis e podem cometer erros de maneiras estranhas / retardar a compilação da maneira como os modelos C++ fazem, mas por outro lado são muito estáticos e difíceis de adaptar a coisas como funções de primeira classe.

Para a segunda parte, não vejo uma maneira de fazer algo como uma "fatia de funções que processam fatias de um tipo específico e retornam um elemento", ou em uma sintaxe ad-hoc []func<T>([]T) T , que é muito fácil de fazer essencialmente em todas as linguagens funcionais estaticamente tipadas. O que é realmente necessário é que os valores sejam capazes de assumir tipos paramétricos, não alguma geração de código em nível de código-fonte.

@bunsim

Para a segunda parte, não vejo uma maneira de fazer algo como uma "fatia de funções que processam fatias de um tipo específico e retornam um elemento",

Se você está falando de um único parâmetro de tipo, na minha proposta isso seria escrito:

const func SliceOfSelectors(T gotype) gotype { return []func([]T)T (type) }

Se você está falando sobre misturar parâmetros de tipo e parâmetros de valor, não, minha proposta não permite isso: parte do objetivo das funções de tempo de compilação é poder operar em valores unboxed, e o tipo de parametricidade de tempo de execução Eu acho que você está descrevendo praticamente requer boxe de valores.

Sim, mas na minha opinião esse tipo de coisa que requer boxing deve ser permitido mantendo a segurança de tipo, talvez com uma sintaxe especial que indique o "boxedness". Uma grande parte da adição de "genéricos" é realmente evitar a segurança de tipo de interface{} mesmo quando a sobrecarga de interface{} não é evitável. (Talvez permita apenas certas construções de tipo paramétrico com tipos de ponteiro e interface que "já" estão em caixa? Os objetos em caixa Integer etc do Java não são completamente uma má ideia, embora fatias de tipos de valor sejam complicadas)

Eu apenas sinto que as funções de tempo de compilação são muito parecidas com C++, e seria extremamente decepcionante para pessoas como eu esperando que o Go2 tivesse um sistema de tipo paramétrico moderno baseado em uma teoria de tipo de som em vez de um hack baseado na manipulação de pedaços de código-fonte escritos em uma linguagem sem genéricos.

@bcmills
O que você propõe não será modular. Se o módulo A usa o módulo B, que usa o módulo C, que usa o módulo D, uma mudança em como um parâmetro de tipo é usado em D pode precisar se propagar de volta para A, mesmo que o implementador de A não tenha ideia de que D está no sistema. O acoplamento frouxo fornecido pelos sistemas modulares será enfraquecido e o software ficará mais frágil. Este é um dos problemas com modelos C++.

Se, por outro lado, as assinaturas de tipo capturam os requisitos nos parâmetros de tipo, como em linguagens como CLU, ML, Haskell ou Genus, um módulo pode ser compilado sem nenhum acesso aos componentes internos dos módulos dos quais depende.

@bunsim

Uma grande parte da adição de "genéricos" é realmente evitar a insegurança de tipo da interface{} mesmo quando a sobrecarga da interface{} não é evitável.

"não evitável" é relativo. Observe que a sobrecarga do boxe é o ponto 3 no post de Russ de 2009 (https://research.swtch.com/generic).

esperando que o Go2 tenha um sistema de tipo paramétrico moderno baseado em uma teoria de tipo de som em vez de um hack baseado na manipulação de pedaços de código-fonte

Uma boa "teoria do tipo de som" é descritiva, não prescritiva. Minha proposta em particular se baseia no cálculo lambda de segunda ordem (ao longo das linhas do Sistema F), onde gotype representa o tipo type e todo o sistema de tipo de primeira ordem é içado para o segundo -order ("tempo de compilação").

Também está relacionado ao trabalho de teoria do tipo modal de Davies, Pfenning, et al na CMU. Para algum conhecimento, eu começaria com Uma Análise Modal de Computação Estágio e Tipos Modais como Especificações de Preparação para Geração de Código em Tempo de Execução .

É verdade que a teoria de tipos subjacente em minha proposta é menos formalmente especificada do que na literatura acadêmica, mas isso não significa que não esteja lá.

@andrewcmyers

Se o módulo A usa o módulo B, que usa o módulo C, que usa o módulo D, uma mudança na forma como um parâmetro de tipo é usado em D pode precisar se propagar até A, mesmo que o implementador de A não tenha ideia de que D está no sistema.

Isso já é verdade em Go hoje: se você olhar com atenção, notará que os arquivos de objeto gerados pelo compilador para um determinado pacote Go incluem informações sobre as partes das dependências transitivas que afetam a API exportada.

O acoplamento frouxo fornecido pelos sistemas modulares será enfraquecido e o software ficará mais frágil.

Eu ouvi esse mesmo argumento usado para defender a exportação de tipos interface em vez de tipos concretos em APIs Go, e o inverso acaba sendo mais comum: a abstração prematura restringe os tipos e dificulta a extensão das APIs. (Para um exemplo, veja #19584.) Se você quiser confiar nessa linha de argumento, acho que precisa fornecer alguns exemplos concretos.

Este é um dos problemas com modelos C++.

A meu ver, os principais problemas com os modelos C++ são (em nenhuma ordem específica):

• Excessiva ambiguidade sintática.
  uma. Ambiguidade entre nomes de tipo e nomes de valor.
  b. Suporte excessivamente amplo para sobrecarga do operador, levando a uma capacidade enfraquecida de inferir restrições do uso do operador.
• Confiança excessiva na resolução de sobrecarga para metaprogramação (ou, de forma equivalente, evolução ad-hoc do suporte à metaprogramação).
  uma. Especialmente regras de recolhimento de referência wrt.
• Aplicação excessivamente ampla do princípio SFINAE, levando a restrições muito difíceis de propagar e muitas condicionais implícitas nas definições de tipo, levando a relatórios de erros muito difíceis.
• Uso excessivo de token-colando e inclusão textual (o pré-processador C) em vez de substituição AST e artefatos de compilação de ordem superior (que felizmente parece ser pelo menos parcialmente abordado com Módulos).
• Falta de boas linguagens de bootstrapping para compiladores C++, levando a relatórios de erros ruins em linhagens de compiladores de longa duração (por exemplo, a cadeia de ferramentas GCC).
• A duplicação (e às vezes a multiplicação) de nomes resultantes do mapeamento de conjuntos de operadores em "conceitos" com nomes diferentes (em vez de tratar os próprios operadores como as restrições fundamentais).

Eu tenho codificado em C++ de vez em quando há uma década e estou feliz em discutir as deficiências de C++ longamente, mas o fato de que as dependências do programa são transitivas nunca esteve nem remotamente perto do topo da minha lista de reclamações.

Por outro lado, precisando atualizar uma cadeia de dependências O(N) apenas para adicionar um único método a um tipo no módulo A e poder usá-lo no módulo D? Esse é o tipo de problema que me atrasa regularmente. Onde a parametricidade e o acoplamento fraco entram em conflito, eu escolho a parametricidade qualquer dia.

Ainda assim, acredito firmemente que metaprogramação e polimorfismo paramétrico devem ser separados, e a confusão deles em C++ é a causa raiz do motivo pelo qual os modelos C++ são irritantes. Simplificando, C++ tenta implementar uma ideia de teoria de tipos usando essencialmente macros em esteróides, o que é muito problemático, pois os programadores gostam de pensar em modelos como polimorfismo paramétrico real e são atingidos por comportamentos inesperados. As funções de tempo de compilação são uma ótima ideia para metaprogramação e substituição do hack que é go generate , mas não acredito que deva ser a maneira abençoada de fazer programação genérica.

O polimorfismo paramétrico "real" ajuda no acoplamento fraco e não deve entrar em conflito com ele. Também deve ser fortemente integrado com o resto do sistema de tipos; por exemplo, provavelmente deve ser integrado ao sistema de interface atual, para que muitos usos de tipos de interface possam ser reescritos em coisas como:

func <T io.Reader> ReadAll(in T)

o que deve evitar sobrecarga de interface (como o uso de Rust), embora neste caso não seja muito útil.

Um exemplo melhor pode ser o pacote sort , onde você poderia ter algo como

func <T Comparable> Sort(slice []T)

onde Comparable é simplesmente uma boa e velha interface que os tipos podem implementar. Sort pode então ser chamado em uma fatia de tipos de valor que implementam Comparable , sem encaixá-los em tipos de interface.

@bcmills Dependências transitivas não restritas pelo sistema de tipos estão, na minha opinião, no centro de algumas de suas reclamações sobre C++. Dependências transitivas não são um grande problema se você controla os módulos A, B, C e D. Em geral, você está desenvolvendo o módulo A e pode estar apenas fracamente ciente de que o módulo D está lá embaixo e, inversamente, o desenvolvedor de D pode não ter conhecimento de A. Se o módulo D agora, sem fazer nenhuma alteração nas declarações visíveis em D, começa a usar algum novo operador em um parâmetro de tipo - ou simplesmente usa esse parâmetro de tipo como um argumento de tipo para um novo módulo E com seu próprio restrições implícitas — essas restrições serão transmitidas a todos os clientes, que podem não estar usando argumentos de tipo que satisfaçam as restrições. Nada diz ao desenvolvedor D que eles estão estragando tudo. Na verdade, você tem uma espécie de inferência de tipo global, com todas as dificuldades de depuração que isso implica.

Acredito que a abordagem que adotamos no Gênero [ PLDI'15 ] é muito melhor. Os parâmetros de tipo têm restrições explícitas, mas leves (eu entendo seu ponto sobre o suporte a restrições de operação; o CLU mostrou como fazer isso desde 1977). A verificação de tipo de gênero é totalmente modular. O código genérico pode ser compilado apenas uma vez para otimizar o espaço de código ou especializado para argumentos de tipo específicos para um bom desempenho.

@andrewcmyers

Se o módulo D agora, sem fazer nenhuma alteração nas declarações visíveis em D, começa a usar algum novo operador em um parâmetro de tipo […] [clientes] podem não estar usando argumentos de tipo que satisfaçam as restrições. Nada diz ao desenvolvedor D que eles estão estragando tudo.

Claro, mas isso já é verdade para muitas restrições implícitas em Go, independentemente de qualquer mecanismo de programação genérico.

Por exemplo, uma função pode receber um parâmetro do tipo interface e inicialmente chamar seus métodos sequencialmente. Se essa função for alterada posteriormente para chamar esses métodos simultaneamente (gerando goroutines adicionais), a restrição "deve ser segura para uso simultâneo" não será refletida no sistema de tipos.

Da mesma forma, o sistema de tipo Go hoje não especifica restrições nos tempos de vida das variáveis: algumas implementações de io.Writer supõem erroneamente que podem manter uma referência à fatia passada e lê-la mais tarde (por exemplo, fazendo a gravação real de forma assíncrona em uma goroutine em segundo plano), mas isso causará corridas de dados se o chamador de Write tentar reutilizar a mesma fatia de apoio para um Write subsequente.

Ou uma função usando um switch de tipo pode seguir um caminho diferente de um método adicionado a um dos tipos no switch.

Ou uma função que verifica um código de erro específico pode falhar se a função que gera o erro alterar a maneira como relata essa condição. (Por exemplo, consulte https://github.com/golang/go/issues/19647.)

Ou uma função que verifica um tipo de erro específico pode quebrar se os wrappers em torno do erro forem adicionados ou removidos (como aconteceu no pacote net padrão no Go 1.5).

Ou o buffer em um canal exposto em uma API pode mudar, introduzindo deadlocks e/ou corridas.

...e assim por diante.

Go não é incomum nesse sentido: restrições implícitas são onipresentes em programas do mundo real.

Se você tentar capturar todas as restrições relevantes em anotações explícitas, acabará indo em uma das duas direções.

Em uma direção, você constrói um sistema complexo e extremamente abrangente de tipos e anotações dependentes, e as anotações acabam recapitulando uma parte substancial do código que anotam. Como espero que você possa ver claramente, essa direção não está de forma alguma de acordo com o design do restante da linguagem Go: Go favorece a simplicidade de especificação e a concisão do código sobre a tipagem estática abrangente.

Na outra direção, as anotações explícitas cobririam apenas um subconjunto das restrições relevantes para uma determinada API. Agora, as anotações fornecem uma falsa sensação de segurança: o código ainda pode quebrar devido a alterações nas restrições implícitas, mas a presença de restrições explícitas leva o desenvolvedor a pensar que qualquer alteração "type-safe" também mantém a compatibilidade.

Não é óbvio para mim por que esse tipo de estabilidade de API precisa ser obtido por meio de anotação explícita de código-fonte: o tipo de estabilidade de API que você está descrevendo também pode ser alcançado (com menos redundância no código) por meio de análise de código-fonte. Por exemplo, você pode imaginar que a ferramenta api analise o código e produza um conjunto de restrições muito mais rico do que pode ser expresso no sistema de tipos formal da linguagem, e dando à ferramenta guru a capacidade de consultar o conjunto calculado de restrições para qualquer função, método ou parâmetro da API.

@bcmills Você não está fazendo do perfeito o inimigo do bom? Sim, existem restrições implícitas que são difíceis de capturar em um sistema de tipos. (E um bom design modular evita a introdução de tais restrições implícitas quando viável.) Seria ótimo ter uma análise abrangente que pudesse verificar estaticamente todas as propriedades que você deseja verificar -- e fornecer explicações claras e não enganosas aos programadores sobre onde eles devem ser verificados. estão cometendo erros. Mesmo com o progresso recente no diagnóstico e localização automática de erros , não estou prendendo a respiração. Por um lado, as ferramentas de análise só podem analisar o código que você fornece a elas. Os desenvolvedores nem sempre têm acesso a todo o código que pode ser vinculado ao deles.

Então, onde há restrições fáceis de capturar em um sistema de tipos, por que não dar aos programadores a capacidade de escrevê-las? Temos 40 anos de experiência em programação com parâmetros de tipo restritos estaticamente. Esta é uma anotação estática simples e intuitiva que vale a pena.

Uma vez que você começa a construir um software maior que estratifica módulos de software, você começa a querer escrever comentários explicando tais restrições implícitas de qualquer maneira. Supondo que haja uma maneira boa e verificável de expressá-los, por que não deixar o compilador entrar na piada para que ele possa ajudá-lo?

Observo que alguns de seus exemplos de outras restrições implícitas envolvem tratamento de erros. Acho que nossa verificação estática leve de exceções [ PLDI 2016 ] abordaria esses exemplos.

@andrewcmyers

Então, onde há restrições fáceis de capturar em um sistema de tipos, por que não dar aos programadores a capacidade de escrevê-las?
[…]
Uma vez que você começa a construir um software maior que estratifica módulos de software, você começa a querer escrever comentários explicando tais restrições implícitas de qualquer maneira. Supondo que haja uma maneira boa e verificável de expressá-los, por que não deixar o compilador entrar na piada para que ele possa ajudá-lo?

Na verdade, concordo completamente com esse ponto e costumo usar um argumento semelhante em relação ao gerenciamento de memória. (Se você tiver que documentar invariantes em alias e retenção de dados de qualquer maneira, por que não impor essas invariantes em tempo de compilação?)

Mas eu levaria esse argumento um passo adiante: o inverso também vale! Se você _não_ precisa escrever um comentário para uma restrição (porque é óbvio no contexto para os humanos que trabalham com o código), por que você precisa escrever esse comentário para o compilador? Independentemente das minhas preferências pessoais, o uso de coleta de lixo e valores zero por Go indica claramente um viés de "não exigir que os programadores declarem invariantes óbvios". Pode ser que a modelagem estilo Gênero possa expressar muitas das restrições que seriam expressas nos comentários, mas como isso se sai em termos de eliminar as restrições que também seriam eliminadas nos comentários?

Parece-me que os modelos de estilo Genus são mais do que apenas comentários de qualquer maneira: eles realmente mudam a semântica do código em alguns casos, eles não apenas o restringem. Agora teríamos dois mecanismos diferentes — interfaces e modelos de tipo — para parametrizar comportamentos. Isso representaria uma grande mudança na linguagem Go: descobrimos algumas práticas recomendadas para interfaces ao longo do tempo (como "definir interfaces no lado do consumidor") e não é óbvio que essa experiência se traduziria em um sistema tão radicalmente diferente, mesmo negligenciando a compatibilidade com Go 1.

Além disso, uma das excelentes propriedades do Go é que sua especificação pode ser lida (e amplamente compreendida) em uma tarde. Não é óbvio para mim que um sistema de restrições no estilo Genus possa ser adicionado à linguagem Go sem complicar substancialmente - eu estaria curioso para ver uma proposta concreta de mudanças nas especificações.

Aqui está um ponto de dados interessante para "metaprogramação". Seria bom para certos tipos nos pacotes sync e atomic — ou seja, atomic.Value e sync.Map — para suportar métodos CompareAndSwap , mas esses só funcionam para tipos que são comparáveis. O restante das APIs atomic.Value e sync.Map permanecem úteis sem esses métodos, portanto, para esse caso de uso, precisamos de algo como SFINAE (ou outros tipos de APIs definidas condicionalmente) ou temos que cair de volta a uma hierarquia mais complexa de tipos.

Eu quero abandonar essa ideia de sintaxe criativa de usar silábicos aborígenes.

@bcmills Você pode explicar mais sobre esses três pontos?

1. Ambiguidade entre nomes de tipo e nomes de valor.
2. Suporte excessivamente amplo para sobrecarga do operador
   3. Confiança excessiva na resolução de sobrecarga para metaprogramação

@mahdix Claro.

1. Ambiguidade entre nomes de tipo e nomes de valor.

Este artigo dá uma boa introdução. Para analisar um programa C++, você deve saber quais nomes são tipos e quais são valores. Ao analisar um programa C++ com modelo, você não tem essas informações disponíveis para os membros dos parâmetros do modelo.

Um problema semelhante surge em Go para literais compostos, mas a ambiguidade está entre valores e nomes de campo em vez de valores e tipos. Neste código Go:

const a = someValue
x := T{a: b}

a é um nome de campo literal ou a constante a está sendo usada como uma chave de mapa ou índice de matriz?

1. Suporte excessivamente amplo para sobrecarga do operador

A pesquisa dependente de argumento é um bom lugar para começar. Sobrecargas de operadores em C++ podem ocorrer como métodos no tipo receptor ou como funções livres em qualquer um dos vários namespaces, e as regras para resolver essas sobrecargas são bastante complexas.

Existem muitas maneiras de evitar essa complexidade, mas a mais simples (como o Go atualmente faz) é não permitir totalmente a sobrecarga do operador.

1. Confiança excessiva na resolução de sobrecarga para metaprogramação

A biblioteca <type_traits> é um bom lugar para começar. Confira a implementação em sua vizinhança amigável libc++ para ver como a resolução de sobrecarga entra em jogo.

Se Go alguma vez suportar metaprogramação (e mesmo isso é muito duvidoso), eu não esperaria que envolvesse resolução de sobrecarga como a operação fundamental para proteger definições condicionais.

@bcmills
Como eu nunca usei C++, você poderia esclarecer onde a sobrecarga do operador por meio da implementação de 'interfaces' predefinidas está em termos de complexidade. Python e Kotlin são exemplos disso.

Eu acho que o próprio ADL é um grande problema com modelos C++ que não foram mencionados, porque eles forçam o compilador a atrasar a resolução de todos os nomes até o momento da instanciação, e podem resultar em bugs muito sutis, em parte porque o "ideal" e " compiladores preguiçosos" se comportam de maneira diferente aqui e o padrão permite isso. O fato de suportar a sobrecarga do operador não é, de longe, a pior parte.

Esta proposta é baseada em Templates, um sistema de macro expansão não seria suficiente? Não estou falando de go generate ou projetos como o gottemplate. Estou falando mais assim:

macro MacroFoo(stmt ast.Statement) {
    ....
}

Macro pode reduzir o clichê e o uso de reflexão.

Eu acho que C++ é um exemplo bom o suficiente para que os genéricos não sejam baseados em modelos ou macros. Especialmente considerando que o Go tem coisas como funções anônimas que realmente não podem ser "instanciadas" em tempo de compilação, exceto como uma otimização.

@samadadi , você pode expressar seu ponto de vista sem dizer "o que há de errado com vocês". Dito isto, o argumento da complexidade já foi levantado várias vezes.

Go não é a primeira linguagem a tentar alcançar a simplicidade omitindo o suporte para polimorfismo paramétrico (genéricos), apesar desse recurso se tornar cada vez mais importante nos últimos 40 anos - na minha experiência, é um grampo dos cursos de programação do segundo semestre.

O problema de não ter o recurso na linguagem é que os programadores acabam recorrendo a soluções ainda piores. Por exemplo, os programadores Go geralmente escrevem modelos de código que são macro-expandidos para produzir o código "real" para vários tipos desejados. Mas a linguagem de programação real é aquela que você digita, não aquela que o compilador vê. Portanto, essa estratégia significa efetivamente que você está usando uma linguagem (não mais padrão) que tem toda a fragilidade e o excesso de código dos modelos C++.

Conforme observado em https://blog.golang.org/toward-go2 , precisamos fornecer "relatórios de experiência", para que as necessidades e as metas de design possam ser determinadas. Você poderia levar alguns minutos e documentar os casos macro que você observou?

Por favor, mantenha este bug no tópico e civil. E novamente, https://golang.org/wiki/NoMeToo. Por favor, comente apenas se você tiver informações únicas e construtivas para adicionar.

@mandolyte É muito fácil encontrar explicações detalhadas na web defendendo a geração de código como um substituto (parcial) para genéricos:
https://appliedgo.net/generics/
https://www.calhoun.io/using-code-generation-to-survive-without-generics-in-go/
http://blog.ralch.com/tutorial/golang-code-generation-and-generics/

Claramente, há um monte de gente lá fora, adotando essa abordagem.

@andrewcmyers , existem algumas limitações, bem como advertências de conveniência ao usar a geração de código, MAS .
Geralmente - se você acredita que essa abordagem é melhor/boa o suficiente, acho que o esforço para permitir uma geração um pouco semelhante de dentro da cadeia de ferramentas go seria uma bênção.

• A otimização do compilador pode ser um desafio neste caso, mas o tempo de execução será consistente, E a manutenção do código, a experiência do usuário (simplicidade...), as melhores práticas padrão e os padrões de código unificados podem ser mantidos.
  Além disso - toda a cadeia de ferramentas será mantida a mesma, exceto as ferramentas de depuração (profilers , depuradores de etapas, etc.) que verão linhas de código que não foram escritas pelo desenvolvedor, mas é um pouco como entrar no código ASM durante a depuração - apenas é um código legível :) .

Desvantagem - nenhum precedente (que eu saiba) para essa abordagem dentro da cadeia de ferramentas go.

Para resumir - considere a geração de código como parte do processo de compilação, não deve ser muito complicado, bastante seguro, otimizado em tempo de execução, pode manter a simplicidade e mudanças muito pequenas na linguagem.

IMHO: É um compromisso facilmente alcançado, com um preço baixo.

Para ser claro, não considero a geração de código no estilo macro, seja feita com gen, cpp, gofmt -r ou outras ferramentas de macro/modelo, como uma boa solução para o problema dos genéricos, mesmo que padronizada. Ele tem os mesmos problemas que os modelos C++: código bloat, falta de verificação de tipo modular e dificuldade de depuração. Fica pior quando você começa, como é natural, construir código genérico em termos de outro código genérico. Na minha opinião, as vantagens são limitadas: manteria a vida relativamente simples para os escritores do compilador Go e produz código eficiente - a menos que haja pressão de cache de instruções, uma situação frequente em software moderno!

Eu acho que o ponto era que a geração de código é usada para substituir
genéricos, então os genéricos devem procurar resolver a maioria desses casos de uso.

Em qua, 26 de julho de 2017, 22:41 Andrew Myers, [email protected] escreveu:

Para ser claro, não considero a geração de código no estilo macro, seja feita
com gen, cpp, gofmt -r ou outras ferramentas de macro/modelo, para ser uma boa
solução para o problema dos genéricos mesmo que padronizados. Tem o mesmo
problemas como modelos C++: código bloat, falta de verificação de tipo modular e
dificuldade de depuração. Fica pior à medida que você começa, como é natural, a construir
código genérico em termos de outro código genérico. A meu ver, as vantagens são
limitado: manteria a vida relativamente simples para os escritores do compilador Go
e produz código eficiente - a menos que haja cache de instruções
pressão, uma situação frequente em softwares modernos!

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-318242016 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

Sem dúvida, a geração de código não é uma solução REAL, mesmo que embrulhada com algum suporte à linguagem para tornar a aparência como uma "parte da linguagem"

Meu ponto foi muito custo-benefício.

Btw, se você olhar para alguns dos substitutos de geração de código, você pode ver facilmente como eles poderiam ter sido muito mais legíveis, mais rápidos e não possuem alguns conceitos errados (por exemplo, iteração sobre matrizes de ponteiros versus valores) se a linguagem lhes fornecesse ferramentas melhores por esta.

E talvez esse seja um caminho melhor para resolver a curto prazo, que não pareceria um patch:
antes de pensar no "melhor suporte genérico que também será idiomático" (acredito que algumas implementações acima levariam anos para realizar a integração completa), implemente alguns conjuntos de funções suportadas "na linguagem" que são necessárias de qualquer maneira (como uma compilação em estruturas cópia profunda) tornaria essa solução de geração de código muito mais utilizável.

Depois de ler as propostas de genéricos de @bcmills e @ianlancetaylor , fiz as seguintes observações:

Funções de tempo de compilação e tipos de primeira classe

Gosto da ideia de avaliação em tempo de compilação, mas não vejo o benefício de limitá-la a funções puras. Esta proposta apresenta o gotype embutido, mas limita seu uso a funções const e quaisquer tipos de dados definidos dentro do escopo da função. Do ponto de vista de um usuário de biblioteca, a instanciação é limitada a funções construtoras como "New" e leva a assinaturas de função como esta:

const func New(K, V gotype, hashfn Hashfn(K), eqfn Eqfn(K)) func()*Hashmap(K, V, hashfn, eqfn)

O tipo de retorno aqui não pode ser separado em um tipo de função porque estamos limitados a funções puras. Além disso, a assinatura define dois novos "tipos" na própria assinatura (K e V), o que significa que, para analisar um único parâmetro, devemos analisar toda a lista de parâmetros. Isso é bom para um compilador, mas gostaria de saber se adiciona complexidade à API pública de um pacote.

Parâmetros de tipo em Go

Tipos parametrizados permitem a maioria dos casos de uso de programação genérica, por exemplo, a capacidade de definir estruturas de dados genéricas e operações sobre diferentes tipos de dados. A proposta lista exaustivamente os aprimoramentos do verificador de tipos que seriam necessários para produzir melhores erros de compilação, tempos de compilação mais rápidos e binários menores.

Na seção "Type Checker", a proposta também lista algumas restrições de tipo úteis para acelerar o processo, como "Indexable", "Comparable", "Callable", "Composite", etc... O que não entendo é por que não permitir que o usuário especifique suas próprias restrições de tipo? A proposta afirma que

Não há restrições sobre como os tipos parametrizados podem ser usados ​​em uma função parametrizada.

No entanto, se os identificadores tivessem mais restrições vinculadas a eles, isso não teria o efeito de auxiliar o compilador? Considerar:

HashMap[Anything,Anything] // Compiler must always compare the implementation and usages to make sure this is valid.

vs

HashMap[Comparable,Anything] // Compiler can first filter out instantiations for incomparable types before running an exhaustive check.

Separar restrições de tipo de parâmetros de tipo e permitir restrições definidas pelo usuário também pode melhorar a legibilidade, tornando os pacotes genéricos mais fáceis de entender. Curiosamente, as falhas listadas no final da proposta em relação à complexidade das regras de dedução de tipo poderiam realmente ser mitigadas se essas regras fossem explicitamente definidas pelo usuário.

@smasher164

Gosto da ideia de avaliação em tempo de compilação, mas não vejo o benefício de limitá-la a funções puras.

A vantagem é que torna possível a compilação separada. Se uma função de tempo de compilação puder modificar o estado global, o compilador deverá ter esse estado disponível ou registrar as edições nele de forma que o vinculador possa sequenciá-las no momento do link. Se uma função de tempo de compilação puder modificar o estado local, precisaríamos de alguma maneira de rastrear qual estado é local versus global. Ambos adicionam complexidade, e não é óbvio que qualquer um forneça benefícios suficientes para compensá-lo.

@smasher164

O que não entendo é por que não permitir que o usuário especifique suas próprias restrições de tipo?

As restrições de tipo nessa proposta correspondem a operações na sintaxe da linguagem. Isso reduz a área de superfície dos novos recursos: não há necessidade de especificar sintaxe adicional para tipos de restrição, porque todas as restrições sintáticas podem ser inferidas do uso.

se os identificadores tivessem mais restrições vinculadas a eles, isso não teria o efeito de auxiliar o compilador?

A linguagem deve ser projetada para seus usuários, não para os compiladores-escritores.

não há necessidade de especificar sintaxe adicional para tipos de restrição porque todas as restrições sintáticas podem ser inferidas a partir do uso.

Esta é a rota que o C++ caiu. Requer uma análise global do programa para identificar os usos relevantes. O código não pode ser raciocinado pelos programadores de forma modular, e as mensagens de erro são detalhadas e incompreensíveis.

Pode ser tão fácil e leve especificar as operações necessárias. Veja CLU (1977) para um exemplo.

@andrewcmyers

Requer uma análise global do programa para identificar os usos relevantes. O código não pode ser raciocinado pelos programadores de forma modular,

Isso está usando uma definição particular de "modular", que eu não acho que seja tão universal quanto você parece supor. Sob a proposta de 2013, cada função ou tipo teria um conjunto inequívoco de restrições inferidas de baixo para cima de pacotes importados, exatamente da mesma forma que o tempo de execução (e as restrições de tempo de execução) de funções não paramétricas são derivadas de baixo para cima. das cadeias de chamadas hoje.

Você presumivelmente poderia consultar as restrições inferidas usando guru ou uma ferramenta semelhante, e poderia responder a essas consultas usando informações locais dos metadados do pacote exportado.

e as mensagens de erro são detalhadas e incompreensíveis.

Temos alguns exemplos (GCC e MSVC) demonstrando que as mensagens de erro geradas ingenuamente são incompreensíveis. Eu acho que é um exagero supor que as mensagens de erro para restrições implícitas são intrinsecamente ruins.

Acho que a maior desvantagem das restrições inferidas é que elas facilitam o uso de um tipo de uma maneira que introduz uma restrição sem entendê-la completamente. Na melhor das hipóteses, isso significa apenas que seus usuários podem se deparar com falhas inesperadas em tempo de compilação, mas na pior das hipóteses, isso significa que você pode quebrar o pacote para os consumidores introduzindo uma nova restrição inadvertidamente. Restrições especificadas explicitamente evitariam isso.

Pessoalmente, também não acho que as restrições explícitas estejam fora de sintonia com a abordagem Go existente, já que as interfaces são restrições explícitas do tipo de tempo de execução, embora tenham expressividade limitada.

Temos alguns exemplos (GCC e MSVC) demonstrando que as mensagens de erro geradas ingenuamente são incompreensíveis. Eu acho que é um exagero supor que as mensagens de erro para restrições implícitas são intrinsecamente ruins.

A lista de compiladores em que a inferência de tipo não local - que é o que você propõe - resulta em mensagens de erro ruins é um pouco mais longa do que isso. Inclui SML, OCaml e GHC, onde muito esforço já foi feito para melhorar suas mensagens de erro e onde há pelo menos alguma estrutura de módulo explícita ajudando. Você pode ser capaz de fazer melhor, e se você criar um algoritmo para boas mensagens de erro com o esquema que você propõe, você terá uma boa publicação. Como ponto de partida para esse algoritmo, você pode achar úteis nossos artigos POPL 2014 e PLDI 2015 sobre localização de erros. Eles são mais ou menos o estado da arte.

porque todas as restrições sintáticas podem ser inferidas a partir do uso.

Isso não limita a amplitude dos programas genéricos com verificação de tipo? Por exemplo, observe que a proposta de parâmetros de tipo não especifica uma restrição "Iterable". Na linguagem atual, isso corresponderia a uma fatia ou canal, mas um tipo composto (digamos, uma lista vinculada) não atenderia necessariamente a esses requisitos. Definindo uma interface como

type Iterable[T] interface {
    Next() T
}

ajuda o caso de lista vinculada, mas agora os tipos de fatia e canal internos devem ser estendidos para satisfazer essa interface.

Uma restrição que diz "Aceito o conjunto de todos os tipos que são Iterables, slices ou canais" parece uma situação ganha-ganha para o usuário, autor do pacote e implementador do compilador. O ponto que estou tentando mostrar é que as restrições são um superconjunto de programas sintaticamente válidos, e alguns podem não fazer sentido do ponto de vista da linguagem, mas apenas do ponto de vista da API.

A linguagem deve ser projetada para seus usuários, não para os compiladores-escritores.

Concordo, mas talvez eu devesse ter formulado de forma diferente. A eficiência aprimorada do compilador pode ser um efeito colateral das restrições definidas pelo usuário. O principal benefício seria a legibilidade, já que o usuário tem uma ideia melhor do comportamento de sua API do que o compilador. A desvantagem aqui é que os programas genéricos teriam que ser um pouco mais explícitos sobre o que eles aceitam.

E se em vez de

type Iterable[T] interface {
    Next() T
}

separamos a ideia de "interfaces" de "restrições". Então podemos ter

type T generic

type Iterable class {
    Next() T
}

onde "class" significa uma classe de tipo no estilo Haskell, não uma classe no estilo Java.

Ter "typeclasses" separados de "interfaces" pode ajudar a esclarecer um pouco da não ortogonalidade das duas ideias. Então Sortable (ignorando sort.Interface) pode ser algo como:

type T generic

type Comparable class {
    Less(a, b T) bool
}

type Sortable class {
    Next() Comparable
}

Aqui estão alguns comentários para a seção "Classes e conceitos de tipo" em Genus por @andrewcmyers e sua aplicabilidade para Go.

Esta seção aborda as limitações das classes e conceitos de tipos, declarando

primeiro, a satisfação da restrição deve ser testemunhada de forma única

Não sei se entendi essa limitação. Amarrar uma restrição a identificadores separados não impediria que ela fosse exclusiva para um determinado tipo? Parece-me que a cláusula "where" em Genus essencialmente constrói um tipo/restrição de uma determinada restrição, mas isso parece análogo a instanciar uma variável de um determinado tipo. Uma restrição dessa maneira se assemelha a um tipo .

Aqui está uma simplificação dramática das definições de restrição, adaptadas para Go:

kind Any interface{} // accepts any type that satisfies interface{}.
type T Any // Declare a type of Any kind. Also binds it to an identifier.
kind Eq T == T // accepts any type for which equality is defined.

Assim, uma declaração de mapa apareceria como:

type Map[K Eq, V Any] struct {
}

onde em Gênero, poderia ser assim:

type Map[K, V] where Eq[K], Any[V] struct {
}

e na proposta de Type-Params existente, ficaria assim:

type Map[K,V] struct {
}

Acho que todos podemos concordar que permitir restrições para alavancar o sistema de tipos existente pode remover a sobreposição entre os recursos da linguagem e facilitar a compreensão de novos.

e segundo, seus modelos definem como adaptar um único tipo, enquanto em uma linguagem com subtipagem, cada tipo adaptado em geral representa todos os seus subtipos.

Essa limitação parece menos pertinente ao Go, pois a linguagem já possui boas regras de conversão entre tipos nomeados/sem nome e interfaces sobrepostas.

Os exemplos apresentados propõem modelos como solução, o que parece ser um recurso útil, mas não necessário para Go. Se uma biblioteca espera que um tipo implemente http.Handler, por exemplo, e o usuário deseja comportamentos diferentes dependendo do contexto, escrever adaptadores é simples:

type handleFunc func(http.ResponseWriter, *http.Request)
func (f handlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w,r) }

Na verdade, é isso que a biblioteca padrão faz.

@smasher164

primeiro, a satisfação da restrição deve ser testemunhada de forma única
Não sei se entendi essa limitação. Amarrar uma restrição a identificadores separados não impediria que ela fosse exclusiva para um determinado tipo?

A ideia é que em Genus você possa satisfazer a mesma restrição com o mesmo tipo de mais de uma maneira, diferentemente de Haskell. Por exemplo, se você tem um HashSet[T] , você pode escrever HashSet[String] para hash strings da maneira usual, mas HashSet[String with CaseInsens] para hash e comparar strings com CaseInsens model, que presumivelmente trata strings de uma maneira que não diferencia maiúsculas de minúsculas. Gênero realmente distingue esses dois tipos; isso pode ser um exagero para Go. Mesmo que o sistema de tipos não o acompanhe, ainda parece importante poder substituir as operações padrão fornecidas por um tipo.

kind Qualquer interface{} // aceita qualquer tipo que satisfaça a interface{}.
type T Any // Declara um tipo de Qualquer tipo. Também o vincula a um identificador.
kind Eq T == T // aceita qualquer tipo para o qual a igualdade é definida.
type Map[K Eq, V Any] struct { ...
}

O equivalente moral disso em Gênero seria:

constraint Any[T] {}
// Just use Any as if it were a type
constraint Eq[K] {
   boolean equals(K);
}
class Map[K, V] where Eq[K] { ... }

Em Familia escreveríamos apenas:

interface Eq {
    boolean equals(This);
}
class Map[K where Eq, V] { ... }

Edit: retirando isso em favor de uma solução baseada em reflexão, conforme descrito em #4146. Uma solução baseada em genéricos, conforme descrevi abaixo, cresce linearmente no número de composições. Embora uma solução baseada em reflexão sempre tenha uma desvantagem de desempenho, ela pode se otimizar em tempo de execução para que a desvantagem seja constante, independentemente do número de composições.

Esta não é uma proposta, mas um caso de uso potencial a ser considerado ao criar uma proposta.

Duas coisas são comuns no código Go hoje

• encapsulando um valor de interface para fornecer funcionalidade adicional (encapsulando um http.ResponseWriter para um framework)
• ter métodos opcionais que às vezes têm valores de interface (como Temporary() bool em net.Error )

Estes são bons e úteis, mas eles não se misturam. Depois de encapsular uma interface, você perde a capacidade de acessar qualquer método não definido no tipo de encapsulamento. Ou seja, dado

type MyError struct {
  error
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.error)
}

Se você envolver um erro nessa estrutura, ocultará quaisquer métodos adicionais no erro original.

Se você não encapsular o erro na estrutura, não poderá fornecer o contexto extra.

Digamos que a proposta genérica aceita permite que você defina algo como o seguinte (sintaxe arbitrária que tentei tornar intencionalmente feia para que ninguém se concentre nela)

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.E)
}

Aproveitando a incorporação, podemos incorporar qualquer tipo concreto que satisfaça a interface de erro e tanto envolvê-la quanto ter acesso a seus outros métodos. Infelizmente, isso só nos leva a parte do caminho.

O que realmente precisamos aqui é pegar um valor arbitrário da interface de erro e incorporar seu tipo dinâmico.

Isso levanta imediatamente duas preocupações

• o tipo teria que ser criado em tempo de execução (provavelmente necessário para refletir de qualquer maneira)
• a criação do tipo teria que entrar em pânico se o valor do erro for nil

Se isso não o azedou no pensamento, você também precisa de um mecanismo para "saltar" a interface para seu tipo dinâmico, seja por uma anotação na lista de parâmetros genéricos para dizer "sempre instanciar no tipo dinâmico de valores de interface " ou por alguma função mágica que só pode ser chamada durante a instanciação de tipo para desembalar a interface para que seu tipo e valor possam ser emendados corretamente.

Sem isso, você está apenas instanciando MyError no próprio tipo de erro, não no tipo dinâmico da interface.

Digamos que temos uma função mágica unbox para extrair e (de alguma forma) aplicar as informações:

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  return MyError{
    E: unbox(err),
    extraContext: ec,
  }
}

Agora digamos que temos um erro não nulo, err , cujo tipo dinâmico é *net.DNSError . Então isso

wrapped := wrap(getExtraContext(), err)
//wrapped 's dynamic type is a MyStruct embedding E=*net.DNSError
_, ok := wrapped.(net.Error)
fmt.Println(ok)

imprimiria true . Mas se o tipo dinâmico de err fosse *os.PathError , teria sido impresso falso.

Espero que a semântica proposta seja clara, dada a sintaxe obtusa usada na demonstração.

Também espero que haja uma maneira melhor de resolver esse problema com menos mecanismo e cerimônia, mas acho que o acima poderia funcionar.

@jimmyfrasche Se estou entendendo o que você quer, é um mecanismo de adaptação sem wrapper. Você deseja expandir o conjunto de operações que um tipo oferece sem envolvê-lo em outro objeto que oculte o original. Esta é uma funcionalidade que o Genus oferece.

@andrewcmyers não.

Estruturas em Go permitem a incorporação. Se você adicionar um campo sem nome, mas com um tipo a uma estrutura, ele fará duas coisas: criará um campo com o mesmo nome do tipo e permitirá despacho transparente para qualquer método desse tipo. Isso soa muito como herança, mas não é. Se você tivesse um tipo T que tivesse um método Foo(), os seguintes são equivalentes

type S struct {
  T
}

e

type S struct {
  T T
}
func (s S) Foo() {
  s.T.Foo()
}

(quando Foo é chamado seu "this" é sempre do tipo T).

Você também pode incorporar interfaces em estruturas. Isso fornece à estrutura todos os métodos no contrato da interface (embora você precise atribuir algum valor dinâmico ao campo implícito ou causará um pânico com o equivalente a uma exceção de ponteiro nulo)

Go tem interfaces que definem um contrato em termos de métodos de um tipo. Um valor de qualquer tipo que satisfaça o contrato pode ser enquadrado em um valor dessa interface. Um valor de uma interface é um ponteiro para o manifesto de tipo interno (tipo dinâmico) e um ponteiro para um valor desse tipo dinâmico (valor dinâmico). Você pode fazer asserções de tipo em um valor de interface para (a) obter o valor dinâmico se você declarar para seu tipo sem interface ou (b) obter um novo valor de interface se você declarar para uma interface diferente que o valor dinâmico também satisfaça. É comum usar o último para "teste de recursos" de um objeto para ver se ele suporta métodos opcionais. Para reutilizar um exemplo anterior, alguns erros têm um método "Temporary() bool" para que você possa ver se algum erro é temporário com:

func isTemp(err error) bool {
  if t, ok := err.(interface{ Temporary() bool}); ok {
    return t.Temporary()
  }
  return false
}

Também é comum envolver um tipo em outro tipo para fornecer recursos extras. Isso funciona bem com tipos que não são de interface. Quando você encapsula uma interface, você também oculta os métodos que não conhece e não pode recuperá-los com asserções do tipo "teste de recurso": o tipo encapsulado expõe apenas os métodos necessários da interface, mesmo que tenha métodos opcionais . Considerar:

type A struct {}
func (A) Foo()
func (A) Bar()

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

Você não pode chamar Bar em i ou mesmo saber que ele existe, a menos que você saiba que o tipo dinâmico de i é um B, então você pode desembrulhar e acessar o campo I para digitar assert sobre isso .

Isso causa problemas reais, especialmente ao lidar com interfaces comuns como erro ou Leitor.

Se houvesse uma maneira de retirar o tipo dinâmico e o valor de uma interface (de alguma maneira segura e controlada), você poderia parametrizar um novo tipo com isso, definir o campo incorporado para o valor e retornar uma nova interface. Então você obtém um valor que satisfaz a interface original, tem qualquer funcionalidade aprimorada que você deseja adicionar, mas o resto dos métodos do tipo dinâmico original ainda estão lá para serem testados.

@jimmyfrasche De fato. O que o Genus permite que você faça é usar um tipo para satisfazer um contrato de "interface" sem encaixotá-lo. O valor ainda tem seu tipo original e suas operações originais. Além disso, o programa pode especificar quais operações o tipo deve usar para satisfazer o contrato - por padrão, são as operações que o tipo fornece, mas o programa pode fornecer novas se o tipo não tiver as operações necessárias. Ele também pode substituir as operações que o tipo usaria.

@jimmyfrasche @andrewcmyers Para esse caso de uso, consulte também https://github.com/golang/go/issues/4146#issuecomment -318200547.

@jimmyfrasche Para mim, parece que o principal problema aqui é obter o tipo/valor dinâmico de uma variável. Deixando de lado a incorporação, um exemplo simplificado seria

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  e E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.e)
}

O valor atribuído a e precisa ter um tipo dinâmico (ou concreto) de algo como *net.DNSError , que implementa error . Aqui estão algumas maneiras possíveis de uma futura mudança de idioma resolver esse problema:

1. Tenha uma função mágica do tipo unbox que descubra o valor dinâmico de uma variável. Isso se aplica a qualquer tipo que não seja concreto, por exemplo, sindicatos.
2. Se a alteração de idioma oferecer suporte a variáveis ​​de tipo, forneça um meio de obter o tipo dinâmico da variável. Com informações de tipo, podemos escrever a função unbox nós mesmos. Por exemplo,

func unbox(v T1) T2 {
    t := dynTypeOf(v)
    return v.(t)
}

wrap pode ser escrito da mesma forma que antes, ou como

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  t := dynTypeOf(err)
  return MyError{
    e: v.(t),
    extraContext: ec,
  }
}

1. Se a mudança de idioma suportar restrições de tipo, aqui está uma ideia alternativa:

type E1 which_is_a_type_satisfying error
type E2 which_is_a_type_satisfying error

func wrap(ec extraContext, err E1) E2 {
  if err == nil {
    return nil
  }
  return MyError{
    e: err,
    extraContext: ec,
  }
}

Neste exemplo, aceitamos um valor de qualquer tipo que implemente erro. Qualquer usuário de wrap que espera um error receberá um. No entanto, o tipo de e dentro MyError é o mesmo do err que é passado, que não se limita a um tipo de interface. Se alguém quisesse o mesmo comportamento que 2,

var iface error = ...
wrap(getExtraContext(), unbox(iface))

Como ninguém mais parece ter feito isso, gostaria de destacar os "relatos de experiência" muito óbvios para genéricos, conforme solicitado por https://blog.golang.org/toward-go2.

O primeiro é o tipo map embutido:

m := make(map[string]string)

O próximo é o tipo chan embutido:

c := make(chan bool)

Finalmente, a biblioteca padrão está repleta de alternativas interface{} onde os genéricos funcionariam com mais segurança:

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• próximo sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Pode haver outros que eu estou perdendo. O ponto é que cada um dos itens acima é onde eu esperaria que os genéricos fossem úteis.

(Nota: não estou incluindo sort.Sort aqui porque é um excelente exemplo de como interfaces podem ser usadas em vez de genéricos.)

http://www.yinwang.org/blog-cn/2014/04/18/golang
Eu acho que o genérico é importante. Caso contrário, não pode lidar com tipos semelhantes. Às vezes, a interface não pode resolver o problema.

Sintaxe simples e sistema de tipos são as vantagens importantes do Go. Se você adicionar genéricos, a linguagem se tornará uma bagunça feia como Scala ou Haskell. Além disso, esse recurso atrairá fanboys pseudo-acadêmicos, que eventualmente transformarão os valores da comunidade de "Vamos fazer isso" para "Vamos falar sobre teoria e matemática de CS". Evite genéricos, é um caminho para o abismo.

@bxqgit , por favor, mantenha isso civilizado. Não há necessidade de insultar ninguém.

Quanto ao que o futuro trará, veremos, mas sei que, embora em 98% do meu tempo não precise de genéricos, sempre que precisar, gostaria de poder usá-los. Como eles são usados ​​vs como eles são usados ​​indevidamente é uma discussão diferente. Educar os usuários deve ser parte do processo.

@bxqgit
Existem situações em que os genéricos são necessários, como estruturas de dados genéricas (Árvores, Pilhas, Filas, ...) ou funções genéricas (Map, Filter, Reduce, ...) e essas coisas são inevitáveis, usando interfaces em vez de genéricos em essas situações apenas adicionam uma enorme complexidade tanto para o escritor de código quanto para o leitor de código e também tem um efeito ruim na eficiência do código em tempo de execução, então deve ser muito mais racional adicionar genéricos de linguagem do que tentar usar interfaces e refletir para escrever complexos e código ineficiente.

@bxqgit Adicionar genéricos não necessariamente adiciona complexidade à linguagem, isso também pode ser alcançado com uma sintaxe simples. Com genéricos, você está adicionando uma restrição de tipo de tempo de compilação variável que é muito útil com estruturas de dados, como disse @riwogo .

O sistema de interface atual em go é muito útil, mas é muito ruim quando você precisa, por exemplo, de uma implementação geral de list, que com interfaces precisa de uma restrição de tipo de tempo de execução, no entanto, se você adicionar genéricos, o tipo genérico pode ser substituído em tempo de compilação com o tipo real, tornando a restrição desnecessária.

Além disso, lembre-se, as pessoas por trás vão, desenvolvem a linguagem usando o que você chama de "teoria e matemática CS", e também são as pessoas que "estão fazendo isso".

Além disso, lembre-se, as pessoas por trás vão, desenvolvem a linguagem usando o que você chama de "teoria e matemática CS", e também são as pessoas que "estão fazendo isso".

Pessoalmente, não vejo muita teoria e matemática de CS no design da linguagem Go. É uma linguagem bastante primitiva, o que é bom na minha opinião. Além disso, essas pessoas de quem você está falando decidiram evitar os genéricos e fizeram as coisas. Se funciona bem, por que mudar alguma coisa? Geralmente, acho que evoluir e estender constantemente a sintaxe da linguagem é uma má prática. Ele só adiciona complexidade que leva ao caos de Haskell e Scala.

O template é complicado mas o Generics é simples

Veja as funções SortInts, SortFloats, SortStrings no pacote de classificação. Ou SearchInts, SearchFloats, SearchStrings. Ou os métodos Len, Less e Swap de byName no pacote io/ioutil. Cópia clichê pura.

As funções de copiar e anexar existem porque tornam as fatias muito mais úteis. Genéricos significaria que essas funções são desnecessárias. Os genéricos tornariam possível escrever funções semelhantes para mapas e canais, sem mencionar os tipos de dados criados pelo usuário. É verdade que as fatias são o tipo de dados composto mais importante, e é por isso que essas funções eram necessárias, mas outros tipos de dados ainda são úteis.

Meu voto é não para genéricos de aplicativos generalizados, sim para funções genéricas mais internas como append e copy que funcionam em vários tipos de base. Talvez sort e search possam ser adicionados para os tipos de coleção?

Para meus aplicativos, o único tipo que está faltando é um conjunto não ordenado (https://github.com/golang/go/issues/7088), eu gostaria disso como um tipo interno para obter a digitação genérica como slice e map . Coloque o trabalho no compilador (benchmarking para cada tipo base e um conjunto selecionado de tipos struct e depois ajuste para melhor desempenho) e mantenha anotações adicionais fora do código do aplicativo.

smap embutido em vez de sync.Map também, por favor. Da minha experiência, usar interface{} para segurança de tipo de tempo de execução é uma falha de design. A verificação de tipo em tempo de compilação é um dos principais motivos para usar o Go.

@pciet

Pela minha experiência, usar a interface{} para segurança do tipo de tempo de execução é uma falha de design.

Você pode apenas escrever um wrapper pequeno (tipo seguro)?
https://play.golang.org/p/tG6hd-j5yx

@pierrre Esse invólucro é melhor do que um cheque de reflect.TypeOf(item).AssignableTo(type) . Mas escrever seu próprio tipo com map + sync.Mutex ou sync.RWMutex é a mesma complexidade sem a declaração de tipo que sync.Map requer.

Meu uso de mapa sincronizado tem sido para mapas globais de mutexes com var myMapLock = sync.RWMutex{} ao lado em vez de fazer um tipo. Isso poderia ser mais limpo. Um tipo interno genérico soa bem para mim, mas exige um trabalho que não posso fazer, e prefiro minha abordagem em vez de declaração de tipo.

Suspeito que a reação visceral negativa aos genéricos que muitos programadores Go parecem ter surge porque sua principal exposição aos genéricos foi por meio de modelos C++. Isso é lamentável porque o C++ errou tragicamente os genéricos desde o primeiro dia e vem agravando o erro desde então. Os genéricos para Go podem ser muito mais simples e menos propensos a erros.

Seria decepcionante ver o Go se tornando cada vez mais complexo adicionando tipos parametrizados embutidos. Seria melhor apenas adicionar o suporte à linguagem para programadores escreverem seus próprios tipos parametrizados. Em seguida, os tipos especiais poderiam ser fornecidos apenas como bibliotecas, em vez de sobrecarregar a linguagem principal.

@andrewcmyers "Genéricos para Go poderia ser muito mais simples e menos propenso a erros." --- como genéricos em C#.

É decepcionante ver o Go se tornando cada vez mais complexo ao adicionar tipos parametrizados embutidos.

Apesar da especulação nesta edição, acho extremamente improvável que isso aconteça.

O expoente na medida de complexidade dos tipos parametrizados é a variância.
Os tipos de Go (exceto interfaces) são invariáveis ​​e isso pode e deve ser
manteve a regra.

Uma implementação de genéricos "tipo copiar-colar" mecânica e assistida por compilador
resolveria 99% do problema de uma forma fiel aos princípios básicos de Go
princípios de superficialidade e não surpresa.

Aliás, essa e dezenas de outras ideias viáveis ​​já foram discutidas
antes e alguns até culminaram em abordagens boas e viáveis. Neste
ponto, estou no limite do ódio de papel alumínio sobre como todos eles desapareceram
silenciosamente no vazio.

Em 28 de novembro de 2017 23:54, "Andrew Myers" [email protected] escreveu:

Suspeito que a reação visceral negativa aos genéricos que muitos Go
programadores parecem ter surgido porque sua principal exposição aos genéricos foi
através de modelos C++. Isso é lamentável porque o C++ recebeu os genéricos tragicamente
errado desde o primeiro dia e vem agravando o erro desde então. Genéricos para
Go poderia ser muito mais simples e menos propenso a erros.

É decepcionante ver o Go se tornando cada vez mais complexo ao adicionar
tipos parametrizados embutidos. Seria melhor apenas adicionar o idioma
suporte para programadores escreverem seus próprios tipos parametrizados. Então o
tipos especiais poderiam ser fornecidos apenas como bibliotecas em vez de desordenar
a linguagem central.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-347691444 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
.

Sim, você pode ter genéricos sem modelos. Os modelos são uma forma de polimorfismo paramétrico avançado principalmente para instalações de metaprogramação.

@ianlancetaylor Rust permite que um programa implemente uma característica T em um tipo existente Q , desde que sua caixa defina T ou Q .

Apenas um pensamento: eu me pergunto se Simon Peyton Jones (sim, da fama de Haskell) e/ou os desenvolvedores do Rust podem ajudar. Rust e Haskell têm provavelmente os dois sistemas de tipos mais avançados de qualquer linguagem de produção, e Go deve aprender com eles.

Há também Phillip Wadler , que trabalhou em Generic Java , que eventualmente levou à implementação de genéricos que Java tem hoje.

@tarcieri Não acho que os genéricos do Java sejam muito bons, mas são testados em batalha.

@DemiMarie Tivemos Andrew Myers lançando aqui, felizmente.

Com base na minha experiência pessoal, acho que as pessoas que sabem muito sobre diferentes idiomas e sistemas de tipos diferentes podem ser muito úteis no exame de ideias. Mas para produzir as ideias em primeiro lugar, o que precisamos são pessoas que estejam muito familiarizadas com o Go, como ele funciona hoje e como ele pode funcionar razoavelmente no futuro. Go foi projetado para ser, entre outras coisas, uma linguagem simples. Importar ideias de linguagens como Haskell ou Rust, que são significativamente mais complicadas que Go, provavelmente não será uma boa opção. E, em geral, as ideias de pessoas que ainda não escreveram uma quantidade razoável de código Go provavelmente não serão adequadas; não que as ideias sejam ruins como tal, apenas que elas não se encaixem bem com o resto da linguagem.

Por exemplo, é importante entender que Go já tem suporte parcial para programação genérica usando tipos de interface e já tem suporte (quase) completo usando o pacote reflect. Embora essas duas abordagens à programação genérica sejam insatisfatórias por várias razões, qualquer proposta de genéricos em Go precisa interagir bem com elas e, ao mesmo tempo, abordar suas deficiências.

Na verdade, enquanto estou aqui, há algum tempo pensei em programação genérica com interfaces por um tempo e cheguei a três razões pelas quais ela não é satisfatória.

1. Interfaces requerem que todas as operações sejam expressas como métodos. Isso torna difícil escrever uma interface para tipos internos, como tipos de canal. Todos os tipos de canal suportam o operador <- para operações de envio e recebimento, e é bastante fácil escrever uma interface com os métodos Send e Receive , mas para atribuir um valor de canal para esse tipo de interface, você deve escrever os métodos clichê Send e Receive . Esses métodos padronizados serão exatamente os mesmos para cada tipo de canal diferente, o que é tedioso.

2. As interfaces são tipadas dinamicamente e, portanto, os erros que combinam diferentes valores tipados estaticamente são capturados apenas em tempo de execução, não em tempo de compilação. Por exemplo, uma função Merge que mescla dois canais em um único canal usando seus métodos Send e Receive exigirá que os dois canais tenham elementos do mesmo tipo, mas isso verificação só pode ser feita em tempo de execução.

3. As interfaces são sempre encaixotadas. Por exemplo, não há como usar interfaces para agregar um par de outros tipos sem colocar esses outros tipos em valores de interface, exigindo alocações de memória adicionais e busca de ponteiro.

Estou feliz em kibitz sobre propostas de genéricos para Go. Talvez também seja interessante a crescente quantidade de pesquisas sobre genéricos em Cornell ultimamente, aparentemente relevantes para o que pode ser feito com Go:

http://www.cs.cornell.edu/andru/papers/familia/ (Zhang & Myers, OOPSLA'17)
http://io.livecode.ch/learn/namin/unsound (Amin & Tate, OOPSLA'16)
http://www.cs.cornell.edu/projects/genus/ (Zhang et al., PLDI '15)
https://www.cs.cornell.edu/~ross/publications/shapes/shapes-pldi14.pdf (Greenman, Muehlboeck & Tate, PLDI '14)

No benchmarking map vs. slice para um tipo de conjunto não ordenado, escrevi testes de unidade separados para cada um, mas com tipos de interface posso combinar essas duas listas de teste em uma:

type Item interface {
    Equal(Item) bool
}

type Set interface {
    Add(Item) Set
    Remove(Item) Set
    Combine(...Set) Set
    Reduce() Set
    Has(Item) bool
    Equal(Set) bool
    Diff(Set) Set
}

Testando a remoção de um item:

type RemoveCase struct {
    Set
    Item
    Out Set
}

func TestRemove(t *testing.T) {
    for i, c := range RemoveCases {
        if c.Out.Equal(c.Set.Remove(c.Item)) == false {
            t.Fatalf("%v failed", i)
        }
    }
}

Dessa forma, posso juntar meus casos anteriormente separados em uma fatia de casos sem problemas:

var RemoveCases = []RemoveCase{
    {
        Set: MapPathSet{
            &Path{{0, 0}}:         {},
            &Path{{0, 1}, {1, 1}}: {},
        },
        Item: Path{{0, 0}},
        Out: MapPathSet{
            &Path{{0, 1}, {1, 1}}: {},
        },
    },
    {
        Set: SlicePathSet{
            {{0, 0}},
            {{0, 1}, {1, 1}},
        },
        Item: Path{{0, 0}},
        Out: SlicePathSet{
            {{0, 1}, {1, 1}},
        },
    },
}

Para cada tipo concreto tive que definir os métodos de interface. Por exemplo:

func (the MapPathSet) Remove(an Item) Set {
    return MapDelete(the, an.(Path))
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an.(Path))
}

Esses testes genéricos podem usar uma verificação de tipo em tempo de compilação proposta:

type Item generic {
    Equal(Item) bool
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an)
}

Fonte: https://github.com/pciet/pathsetbenchmark

Pensando mais nisso, não parece que uma verificação de tipo em tempo de compilação seria possível para tal teste, pois você teria que executar o programa para saber se um tipo é passado para o método de interface correspondente.

Então, que tal um tipo "genérico" que é uma interface e tem uma declaração de tipo invisível adicionada pelo compilador quando usada concretamente?

@andrewcmyers O artigo "Familia" foi interessante (e muito acima da minha cabeça). Uma noção chave era herança. Como os conceitos mudariam para uma linguagem como Go, que depende de composição em vez de herança?

Obrigado. A parte de herança não se aplica a Go -- se você estiver interessado apenas em genéricos para Go, você pode parar de ler após a seção 4 do artigo. A principal coisa sobre esse artigo que é relevante para Go é que ele mostra como usar interfaces tanto da maneira como elas são usadas para Go agora quanto como restrições em tipos para abstrações genéricas. O que significa que você obtém o poder das classes do tipo Haskell sem adicionar uma construção totalmente nova à linguagem.

@andrewcmyers Você pode dar um exemplo de como isso ficaria em Go?

A principal coisa sobre esse artigo que é relevante para Go é que ele mostra como usar interfaces tanto da maneira como elas são usadas para Go agora quanto como restrições em tipos para abstrações genéricas.

Meu entendimento é que a interface Go define uma restrição em um tipo (por exemplo, "este tipo pode ser comparado para igualdade usando a 'interface de tipo Comparable' porque satisfaz ter um método Eq"). Não tenho certeza se entendi o que você quer dizer com uma restrição de tipo.

Eu não estou familiarizado com Haskell, mas lendo uma visão geral rápida me fez adivinhar que os tipos que se encaixam em uma interface Go se encaixam nessa classe de tipo. Você pode explicar o que é diferente nas classes do tipo Haskell?

Uma comparação concreta entre Familia e Go seria interessante. Obrigado por compartilhar seu papel.

As interfaces Go podem ser vistas como descrevendo uma restrição nos tipos, por meio de subtipagem estrutural. No entanto, essa restrição de tipo, como está, não é expressiva o suficiente para capturar as restrições desejadas para programação genérica. Por exemplo, você não pode expressar a restrição de tipo chamada Eq no documento do Familia.

Algumas reflexões sobre a motivação para facilidades de programação mais genéricas em Go:

Portanto, há minha lista de teste genérica que realmente não precisa de nada adicionado à linguagem. Na minha opinião, o tipo genérico que propus não satisfaz o objetivo do Go de compreensão direta, não tem muito a ver com o termo de programação geralmente aceito, e fazer a afirmação de tipo não era feio, pois um pânico na falha é multar. Já estou satisfeito com as facilidades de programação genérica do Go para minha necessidade.

Mas sync.Map é um caso de uso diferente. Há uma necessidade na biblioteca padrão de uma implementação de mapa sincronizado genérico maduro além de apenas uma estrutura com um mapa e mutex. Para manipulação de tipo, podemos envolvê-lo com outro tipo que define um tipo{} não de interface e faz uma declaração de tipo, ou podemos adicionar uma verificação de reflexão internamente para que os itens que seguem o primeiro devem corresponder ao mesmo tipo. Ambos têm verificações de tempo de execução, o encapsulamento requer a reescrita de cada método para cada tipo de uso, mas adiciona uma verificação de tipo de tempo de compilação para entrada e oculta a declaração do tipo de saída, e com a verificação interna ainda temos que fazer uma declaração de tipo de saída de qualquer maneira. De qualquer forma, estamos fazendo conversões de interface sem nenhum uso real de interfaces; interface{} é um hack da linguagem e não ficará claro para novos programadores de Go. Embora json.Marshal seja um bom design na minha opinião (incluindo as tags struct feias, mas sensatas).

Acrescentarei que, como o sync.Map está na biblioteca padrão, o ideal é que ele troque a implementação pelos casos de uso medidos em que a estrutura simples tem melhor desempenho. O mapa não sincronizado é uma armadilha comum na programação concorrente Go e uma correção de biblioteca padrão deve funcionar.

O mapa regular tem apenas uma verificação de tipo em tempo de compilação e não requer nenhum desses andaimes. Eu argumento que sync.Map deve ser o mesmo ou não deve estar na biblioteca padrão para Go 2.

Propus adicionar sync.Map à lista de tipos internos e fazer o mesmo para futuras necessidades semelhantes. Mas meu entendimento é dar aos programadores Go uma maneira de fazer isso sem ter que trabalhar no compilador e passar pelo desafio de aceitação de código aberto é a ideia por trás dessa discussão. Na minha opinião, corrigir sync.Map é um caso real que define parcialmente o que essa proposta de genéricos deve ser.

Se você adicionar o sync.Map como um built-in, até onde você vai? você caso especial cada recipiente?
sync.Map não é o único contêiner e alguns são melhores para alguns casos do que outros.

@Azareal : @chowey listou estes em agosto:

Por fim, a biblioteca padrão está repleta de alternativas{} de interface em que os genéricos funcionariam com mais segurança:

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• próximo sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Pode haver outros que eu estou perdendo. O ponto é que cada um dos itens acima é onde eu esperaria que os genéricos fossem úteis.

E eu gostaria do conjunto não ordenado para tipos que podem ser comparados para igualdade.

Eu gostaria de muito trabalho colocado em uma implementação de variável no tempo de execução para cada tipo com base em benchmarking para que a melhor implementação possível seja geralmente a que é usada.

Gostaria de saber se existem implementações alternativas razoáveis ​​com Go 1 que atinjam o mesmo objetivo para esses tipos de biblioteca padrão sem interface{} e sem genéricos.

interfaces golang e classes do tipo haskell superam duas coisas (que são muito boas!):

1.) (Type Constraint) Agrupam diferentes tipos com uma tag, o nome da interface
2.) (Dispatch) Eles oferecem despacho diferente em cada tipo para um determinado conjunto de funções via implementação de interface

Mas,

1.) Às vezes você quer apenas grupos anônimos como um grupo de int, float64 e string. Como você deve nomear essa interface, NumericandString?

2.) Muitas vezes, você não deseja despachar de forma diferente para cada tipo de interface, mas fornecer apenas um método para todos os tipos de interface listados (Talvez possível com métodos padrão de interfaces )

3.) Muitas vezes, você não deseja enumerar todos os tipos possíveis para um grupo. Em vez disso, você segue o caminho preguiçoso e diz que eu quero todos os tipos T implementando alguma Interface A e o compilador, em seguida, pesquisa todos os tipos em todos os arquivos de origem que você edita e em todas as bibliotecas que você usa para gerar as funções apropriadas em tempo de compilação.

Embora o último ponto seja possível via polimorfismo de interface, ele tem a desvantagem de ser um polimorfismo de tempo de execução envolvendo conversões e como você restringe a entrada de parâmetros de uma função para conter tipos que implementam mais de uma interface ou uma das muitas interfaces. O caminho certo é introduzir novas interfaces estendendo outras interfaces (por aninhamento de interface) para obter algo semelhante, mas não com as melhores práticas.

Por falar nisso.
Admito aos que dizem que go já tem polimorfismo e exatamente por isso go não é mais uma linguagem simples como C. É uma linguagem de programação de sistema de alto nível. Então, por que não expandir o polimorfismo que oferece.

Aqui está uma biblioteca que comecei hoje para tipos de conjuntos não ordenados genéricos: https://github.com/pciet/unordered

Isso fornece exemplos de documentação e teste que tipo wrapper pattern (obrigado @pierrre) para segurança de tipo em tempo de compilação e também tem a verificação de reflexão para segurança de tipo em tempo de execução.

Que necessidades existem para os genéricos? Minha atitude negativa em relação aos tipos genéricos de biblioteca padrão anteriormente se concentrava no uso de interface{}; minha reclamação pode ser resolvida com um tipo específico de pacote para interface{} (como type Item interface{} em pciet/unordered) que documenta as restrições inexprimíveis pretendidas.

Não vejo a necessidade de um recurso de idioma adicional quando apenas a documentação pode nos levar lá agora. Já existem grandes quantidades de código testado em batalha na biblioteca padrão que fornece recursos genéricos (consulte https://github.com/golang/go/issues/23077).

Seu código verifica o tipo em tempo de execução (e dessa perspectiva não é melhor do que apenas interface{} se não for pior). Com os genéricos, você poderia ter os tipos de coleção com verificações de tipo em tempo de compilação.

As verificações em tempo de execução do @zerkms podem ser desativadas definindo asserting = false (isso não iria na biblioteca padrão), há um padrão de uso para verificações em tempo de compilação e, de qualquer maneira, uma verificação de tipo apenas examina a estrutura da interface (usando interface adiciona mais despesas do que a verificação de tipo). Se a interface não estiver funcionando, você terá que escrever seu próprio tipo.

Você está dizendo que o código genérico de desempenho maximizado é uma necessidade fundamental. Não foi para meus casos de uso, mas talvez a biblioteca padrão possa se tornar mais rápida e talvez outros precisem de algo assim.

as verificações em tempo de execução podem ser desativadas definindo asserting = false

então nada garante a exatidão

Você está dizendo que o código genérico de desempenho maximizado é uma necessidade fundamental.

Eu não disse isso. A segurança de tipo seria um grande negócio. Sua solução ainda está infectada com interface{} .

mas talvez a biblioteca padrão possa se tornar mais rápida, e talvez outros precisem de algo assim.

pode ser, se a equipe de desenvolvimento principal estiver feliz em implementar o que eu precisar sob demanda e rapidamente.

@pciet

Não vejo a necessidade de um recurso de idioma adicional quando apenas a documentação pode nos levar lá agora.

Você diz isso, mas não tem problemas em usar os recursos genéricos da linguagem na forma de fatias e a função make.

Não vejo a necessidade de um recurso de idioma adicional quando apenas a documentação pode nos levar lá agora.

Então, por que se preocupar em usar uma linguagem de tipagem estática? Você pode usar uma linguagem tipada dinamicamente como Python e confiar na documentação para garantir que os tipos de dados corretos sejam enviados à sua API.

Acho que uma das vantagens do Go são as facilidades de impor algumas restrições pelo compilador para evitar bugs futuros. Esses recursos podem ser estendidos (com suporte a genéricos) para impor algumas outras restrições para evitar mais alguns bugs no futuro.

Você diz isso, mas não tem problemas em usar os recursos genéricos da linguagem na forma de fatias e a função make.

Estou dizendo que os recursos existentes nos levam a um bom ponto de equilíbrio que tem soluções de programação genéricas e deve haver fortes razões reais para mudar do sistema do tipo Go 1. Não como uma mudança melhoraria a linguagem, mas quais problemas as pessoas estão enfrentando agora, como manter muita alternância de tipo em tempo de execução para interface{} nos pacotes de biblioteca padrão fmt e banco de dados, que seriam corrigidos.

Então, por que se preocupar em usar uma linguagem de tipagem estática? Você pode usar uma linguagem tipada dinamicamente como Python e confiar na documentação para garantir que os tipos de dados corretos sejam enviados à sua API.

Ouvi sugestões para escrever sistemas em Python em vez de linguagens com tipagem estática e as organizações fazem.

A maioria dos programadores Go que usam a biblioteca padrão usa tipos que não podem ser completamente descritos sem documentação ou sem examinar a implementação. Tipos com subtipos paramétricos ou tipos gerais com restrições aplicadas apenas corrigem um subconjunto desses casos programaticamente e gerariam muito trabalho já feito na biblioteca padrão.

Na proposta para os tipos de soma sugeri um recurso de construção para o switch do tipo de interface onde uma interface usada em uma função ou método tem um erro de compilação emitido quando um possível valor atribuído à interface não corresponde a nenhum caso de switch do tipo de interface contido.

Uma função/método que recebe uma interface pode rejeitar alguns tipos na compilação por não ter nenhum caso padrão e nenhum caso para o tipo. Isso parece uma adição de programação genérica razoável se o recurso for viável de implementar.

Se as interfaces Go pudessem capturar o tipo do implementador, poderia haver uma forma de genéricos que fosse completamente compatível com a sintaxe Go atual - uma forma de parâmetro único de genéricos ( demonstração ).

@dc0d para tipos de contêiner genéricos, acredito que esse recurso adiciona verificação de tipo em tempo de compilação sem exigir um tipo de wrapper: https://gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet Você está certo. No código fornecido, nº 4, o exemplo indica que o tipo é capturado para fatias e canais (e matrizes). Mas não para mapas, porque existe apenas um parâmetro de tipo: o implementador. E como um mapa precisa de dois parâmetros de tipo, são necessárias interfaces de wrapper.

BTW eu tenho que enfatizar o propósito demonstrativo desse código, como uma linha de pensamento. Eu não sou nenhum designer de linguagem. Esta é apenas uma maneira hipotética de pensar sobre a implementação de genéricos em Go:

• Compatível com Go atual
• Simples (parâmetro de tipo genérico único, que _sente_ como _this_ em outro OO, referindo-se ao implementador atual)

A discussão de generalidade e todos os casos de uso possíveis no contexto de um desejo de minimizar impactos enquanto maximiza casos de uso importantes e flexibilidade de expressão é uma análise muito complexa. Não tenho certeza se algum de nós será capaz de destilá-lo em um pequeno conjunto de princípios, também conhecido como essência generativa. Estou tentando. De qualquer forma, aqui estão alguns dos meus pensamentos iniciais da minha leitura _curiosa_ deste tópico…

@adg escreveu:

Acompanhando esta edição está uma proposta genérica geral de @ianlancetaylor que inclui quatro propostas falhas específicas de mecanismos genéricos de programação para Go.

Afaics, a seção vinculada extraída a seguir não indica um caso de falta de generalidade nas interfaces atuais, _“Não há como escrever um método que receba uma interface para o chamador fornecido tipo T, para qualquer T, e retorne um valor de o mesmo tipo T.”_.

Não há como escrever uma interface com um método que receba um argumento do tipo T, para qualquer T, e retorne um valor do mesmo tipo.

Então, de que outra forma o código no tipo de site de chamada pode verificar se ele tem um tipo T como valor de resultado? Por exemplo, a referida interface pode ter um método de fábrica para construir o tipo T. É por isso que precisamos parametrizar as interfaces no tipo T.

Interfaces não são simplesmente tipos; também são valores. Não há como usar tipos de interface sem usar valores de interface e os valores de interface nem sempre são eficientes.

Concordamos que, como as interfaces não podem ser parametrizadas explicitamente no tipo T em que operam, o tipo T não é acessível ao programador.

Então, é isso que os limites de tipo de classe fazem no site de definição de função, tomando como entrada um tipo T e tendo uma cláusula where ou requires declarando a(s) interface(s) necessária(s) para o tipo T. Em muitas circunstâncias esses dicionários de interface podem ser monomorfizados automaticamente em tempo de compilação para que nenhum ponteiro de dicionário (para as interfaces) seja passado para a função em tempo de execução (monomorfização que presumo que o compilador Go se aplica a interfaces atualmente?). Por 'valores' na citação acima, presumo que ele se refira ao tipo de entrada T e não ao dicionário de métodos para o tipo de interface implementado pelo tipo T.

Se permitirmos parâmetros de tipo em tipos de dados (por exemplo struct ), então o tipo T acima pode ser parametrizado para que realmente tenhamos um tipo T<U> . Fábricas para esses tipos que precisam reter o conhecimento de U são chamadas de tipos superiores (HKT) .

Os genéricos permitem recipientes polimórficos de tipo seguro.

Cf também a questão dos contêineres _heterogêneos_ discutida abaixo. Portanto, por polimórfico queremos dizer a generalidade do tipo de valor do contêiner (por exemplo, tipo de elemento da coleção), mas também há a questão de saber se podemos colocar mais de um tipo de valor no contêiner simultaneamente, tornando-os heterogêneos.

@tamir escreveu:

Esses requisitos parecem excluir, por exemplo, um sistema semelhante ao sistema de traços de Rust, onde tipos genéricos são restringidos por limites de traços.

Os limites de traço de Rust são essencialmente limites de classe de tipo.

@alex escreveu:

Traços de ferrugem. Embora eu ache que eles são um bom modelo em geral, eles seriam um mau ajuste para o Go como existe hoje.

Por que você acha que eles se encaixam mal? Talvez você esteja pensando nos objetos trait que empregam o despacho em tempo de execução, portanto, têm menos desempenho do que o monomorfismo? Mas esses podem ser considerados separadamente do princípio de generalidade dos limites da classe de tipos (cf minha discussão sobre contêineres/coleções heterogêneas abaixo). Afaics, as interfaces do Go já são limites do tipo trait e cumprem o objetivo das typeclasses que é vincular os dicionários aos tipos de dados no site da chamada, em vez do anti-padrão de OOP que se vincula antecipadamente (mesmo que ainda em compilação time) dicionários para tipos de dados (na instanciação/construção). As classes de tipo podem (pelo menos uma melhoria parcial dos graus de liberdade) resolver o problema de expressão que a OOP não pode.

@jimmyfrasche escreveu:

• https://golang.org/doc/faq#covariant_types

Eu concordo com o link acima que typeclasses de fato não são subtipagem e não estão expressando nenhum relacionamento de herança. E concordo em não confundir desnecessariamente “genericidade” (como um conceito mais geral de reutilização ou modularidade do que polimorfismo paramétrico) com herança, como faz a subclasse.

No entanto, também quero salientar que as hierarquias de herança (também conhecidas como subtipagem) são inevitáveis ¹ na atribuição de (entradas de função) e de (saídas de função) se a linguagem suportar uniões e interseções, porque, por exemplo, um int ν string pode aceitar uma atribuição de um int ou um string mas nenhum deles pode aceitar uma atribuição de um int ν string . Sem as uniões afaik, as únicas maneiras alternativas de fornecer contêineres/coleções heterogêneas estaticamente tipadas são subclasses ou polimorfismo existencialmente limitado (também conhecido como objetos de traço em Rust e quantificação existencial em Haskell). Os links acima contêm discussões sobre as compensações entre existenciais e sindicatos. Afaik, a única maneira de fazer contêineres/coleções heterogêneos em Go agora é subsumir todos os tipos a um interface{} vazio que está jogando fora as informações de digitação e eu presumo exigir casts e inspeção de tipo de tempo de execução, que tipo de ² derrota o ponto de tipagem estática.

O “anti-padrão” a ser evitado é a subclasse, também conhecida como herança virtual (veja também “EDIT#2” sobre os problemas com subsunção implícita e igualdade, etc).

¹ _{Independentemente de serem combinados estruturalmente ou nominalmente porque a subtipagem é devido ao Princípio de Substituição de Liskov baseado em conjuntos comparativos e na direção de atribuição com entradas de função opostas aos valores de retorno, por exemplo, um parâmetro de tipo de struct ou interface não pode residir nas entradas da função e nos valores de retorno, a menos que seja invariante em vez de co- ou contra-variante.}

² _{O absolutismo não se aplica porque não podemos verificar o universo do não-determinismo ilimitado. Então, como eu entendo que seja, este tópico é sobre a escolha de um limite ótimo (“ponto ideal”) para o nível de declaração de digitação wrt para os problemas de generalidade.}

@andrewcmyers escreveu:

Ao contrário dos genéricos Java e C#, o mecanismo Genus genéricos não é baseado em subtipagem.

É a herança e a subclassificação ( não a subtipagem estrutural ) que é o pior antipadrão que você não deseja copiar de Java, Scala, Ceilão e C++ (não relacionado aos problemas com modelos C++ ).

@thwd escreveu:

O expoente na medida de complexidade dos tipos parametrizados é a variância. Os tipos de Go (exceto interfaces) são invariáveis ​​e isso pode e deve ser mantido como regra.

A subtipagem com imutabilidade evita a complexidade da covariância. A imutabilidade também melhora alguns dos problemas com subclasses (por exemplo Rectangle vs. Square ), mas não outros (por exemplo, subsunção implícita, igualdade, etc).

@bxqgit escreveu:

Sintaxe simples e sistema de tipos são as vantagens importantes do Go. Se você adicionar genéricos, a linguagem se tornará uma bagunça feia como Scala ou Haskell.

Observe que Scala tenta mesclar OOP, subclassing, FP, módulos genéricos, HKT e typeclasses (via implicit ) em um PL. Talvez as classes de tipos sozinhas sejam suficientes.

Haskell não é necessariamente obtuso por causa dos genéricos typeclass, mas mais provavelmente porque está impondo funções puras em todos os lugares e empregando a teoria da categoria monádica para modelar efeitos imperativos controlados.

Assim, acho que não é correto associar a obtusidade e complexidade desses PLs com typeclasses em, por exemplo, Rust. E não vamos culpar as classes de tipos pelas vidas de Rust + abstração de empréstimo de mutabilidade exclusiva.

Afaics, na seção Semantics dos _Type Parameters in Go_, o problema encontrado por @ianlancetaylor é uma questão de conceituação porque ele (afaics) aparentemente reinventando typeclasses involuntariamente:

Podemos juntar SortableSlice e PSortableSlice para ter o melhor dos dois mundos? Não exatamente; não há como escrever uma função parametrizada que suporte um tipo com um método Less ou um tipo interno. O problema é que SortableSlice.Less não pode ser instanciado para um tipo sem um método Less , e não há como instanciar um método apenas para alguns tipos, mas não para outros.

A cláusula requires Less[T] para o limite de typeclass (mesmo se implicitamente inferido pelo compilador) no método Less para []T está em T não []T . A implementação da typeclass Less[T] (que contém um método Less ) para cada T fornecerá uma implementação no corpo da função do método ou atribuirá o < função interna como a implementação. No entanto, acredito que isso requer HKT U[T] se os métodos de Sortable[U] precisarem de um parâmetro de tipo U representando o tipo de implementação, por exemplo, []T . Afair @keean tem outra maneira de estruturar uma classificação empregando uma typeclass separada para o tipo de valor T que não requer um HKT.

Observe que esses métodos para []T podem estar implementando uma typeclass Sortable[U] , onde U é []T .

(Técnico à parte: pode parecer que poderíamos mesclar SortableSlice e PSortableSlice tendo algum mecanismo para instanciar apenas um método para alguns argumentos de tipo, mas não para outros. No entanto, o resultado seria sacrificar a compilação -time segurança de tipo, pois usar o tipo errado levaria a um pânico em tempo de execução. Em Go, já é possível usar tipos e métodos de interface e declarações de tipo para selecionar o comportamento em tempo de execução. Não há necessidade de fornecer outra maneira de fazer isso usando parâmetros de tipo .)

A seleção da typeclass vinculada no site de chamada é resolvida em tempo de compilação para um T estaticamente conhecido. Se for necessário despacho dinâmico heterogêneo, veja as opções que expliquei no meu post anterior.

Espero que @keean encontre tempo para vir aqui e ajudar a explicar typeclasses, pois ele é mais especialista e me ajudou a aprender esses conceitos. Posso ter alguns erros na minha explicação.

Nota PS para aqueles que já leram meu post anterior, note que eu o editei extensivamente cerca de 10 horas depois de postá-lo (depois de um pouco de sono) para tornar os pontos sobre contêineres heterogêneos mais coerentes.

A seção Ciclos parece estar incorreta. A construção em tempo de execução da instância S[T]{e} de um struct não tem nada a ver com a seleção da implementação da função genérica chamada. Ele provavelmente está pensando que o compilador não sabe se está especializando a implementação da função genérica para o tipo dos argumentos, mas todos esses tipos são conhecidos em tempo de compilação.

Talvez a especificação da seção Verificação de tipo possa ser simplificada estudando o conceito de @keean de um grafo conectado de tipos distintos como nós para um algoritmo de unificação. Quaisquer tipos distintos conectados por uma aresta devem ter tipos congruentes, com arestas criadas para quaisquer tipos que se conectam por atribuição ou de outra forma no código-fonte. Se houver união e interseção (do meu post anterior), então a direção de atribuição deve ser levada em consideração (de alguma forma? ). Cada tipo desconhecido distinto começa com um mínimo de limites superiores (LUB) de Top e um maior limite inferior (GLB) de Bottom e, em seguida, as restrições podem alterar esses limites. Os tipos conectados precisam ter limites compatíveis. As restrições devem ser todos limites de tipo de classe.

Em Implementação :

Por exemplo, sempre é possível implementar funções parametrizadas gerando uma nova cópia da função para cada instanciação, onde a nova função é criada substituindo os parâmetros de tipo pelos argumentos de tipo.

Acredito que o termo técnico correto seja monomorfização .

Essa abordagem renderia o tempo de execução mais eficiente ao custo de tempo de compilação extra considerável e tamanho de código maior. É provável que seja uma boa escolha para funções parametrizadas que são pequenas o suficiente para serem incorporadas, mas seria uma troca ruim na maioria dos outros casos.

A criação de perfil informaria ao programador quais funções podem se beneficiar mais da monomorfização. Talvez o otimizador Java Hotspot faça otimização de monomorfização em tempo de execução?

@egonelbre escreveu:

Há o Resumo das Discussões Genéricas do Go , que tenta fornecer uma visão geral das discussões de diferentes lugares.

A seção Visão geral parece implicar que o uso universal de referências boxing em Java para instâncias em um contêiner é o único eixo de design que se opõe diametralmente à monomorfização de templates do C++. Mas os limites de tipo de classe (que também podem ser implementados com modelos C++ , mas sempre monomorfizados) são aplicados a funções e não a parâmetros de tipo de contêiner. Assim afaics a visão geral está faltando o eixo de projeto para typeclasses onde podemos escolher se monomorfizar cada função limitada de typeclass. Com typeclasses nós sempre tornamos os programadores mais rápidos (menos clichê) e podemos obter um equilíbrio mais refinado entre tornar os compiladores/execução mais rápidos/mais lentos e o inchaço do código maior/menor. De acordo com o meu post anterior, talvez o ideal seria se a escolha das funções para monomorfizar fosse orientada pelo perfilador (automaticamente ou mais provavelmente por anotação).

Na seção Problemas: Estruturas de Dados Genéricas :

Contras

• Estruturas genéricas tendem a acumular recursos de todos os usos, resultando em tempos de compilação maiores ou em excesso de código ou na necessidade de um vinculador mais inteligente.

Para typeclasses, isso não é verdade ou é um problema menor, porque as interfaces só precisam ser implementadas para tipos de dados fornecidos a funções que usam essas interfaces. Typeclasses são sobre a vinculação tardia da implementação à interface, ao contrário da OOP, que vincula todos os tipos de dados aos seus métodos para a implementação class .

Além disso, nem todos os métodos precisam ser colocados em uma única interface. A cláusula requires (mesmo se implicitamente inferida pelo compilador) em uma typeclass vinculada para uma declaração de função pode misturar e combinar interfaces necessárias.

• As estruturas genéricas e as APIs que operam nelas tendem a ser mais abstratas do que as APIs criadas especificamente, o que pode impor uma carga cognitiva aos chamadores

Um contra-argumento que acho que melhora significativamente essa preocupação é que a carga cognitiva de aprender um número ilimitado de reimplementações de casos especiais dos algoritmos genéricos essencialmente iguais é ilimitada. Considerando que, aprender as APIs genéricas abstratas é limitado.

• As otimizações detalhadas são muito não genéricas e específicas do contexto, portanto, é mais difícil otimizá-las em um algoritmo genérico.

Este não é um contra válido. A regra 80/20 diz para não adicionar complexidade ilimitada (por exemplo, otimização prematura) para código que, quando perfilado, não a exige. O programador é livre para otimizar em 20% dos casos, enquanto os 80% restantes são tratados pela complexidade limitada e carga cognitiva das APIs genéricas.

O que realmente estamos chegando aqui é a regularidade de uma linguagem e APIs genéricas ajudam, não prejudicam isso. Esses contras realmente não são conceituados corretamente.

Soluções alternativas:

• usar estruturas mais simples em vez de estruturas complicadas
  
  
  
  • por exemplo, use map[int]struct{} em vez de Set
  
  

Rob Pike (e eu também o vi fazer esse ponto no vídeo) parece estar perdendo o ponto de que os contêineres genéricos não são suficientes para criar funções genéricas. Precisamos desse T em map[T] para que possamos passar o tipo de dados genérico em funções para entradas, saídas e para nosso próprio struct . Generics apenas em parâmetros de tipo de contêiner é totalmente insuficiente para expressar APIs genéricas e APIs genéricas são necessárias para complexidade limitada e carga cognitiva e obtenção de regularidade em um ecossistema de linguagem. Também não vi o aumento do nível de refatoração (portanto, a composição reduzida de módulos que não podem ser facilmente refatorados) que o código não genérico requer, que é o problema da expressão que mencionei no meu primeiro post.

Na seção Abordagens genéricas :

Modelos de pacote
Esta é uma abordagem usada por Modula-3, OCaml, SML (os chamados “functors”) e Ada. Em vez de especificar um tipo individual para especialização, todo o pacote é genérico. Você especializa o pacote corrigindo os parâmetros de tipo ao importar.

Posso estar enganado, mas isso não parece muito correto. Os functores ML (não devem ser confundidos com os functores FP) também podem retornar uma saída que permanece parametrizada por tipo. Caso contrário, não haveria como usar os algoritmos em outras funções genéricas, portanto, os módulos genéricos não seriam capazes de reutilizar (importando com tipos concretos para) outros módulos genéricos. Isso parece ser uma tentativa de simplificar demais e, em seguida, perder completamente o ponto de genéricos, reutilização de módulos, etc.

Em vez disso, meu entendimento é que essa parametrização de tipo de pacote (também conhecido como módulo) permite a capacidade de aplicar parâmetros de tipo a um agrupamento de struct , interface e func .

Sistema de tipos mais complicado
Esta é a abordagem que Haskell e Rust adotam.
[…]
Contras:

• difícil de encaixar em linguagem mais simples (https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)

Citando @ianlancetaylor no documento vinculado:

Se você acredita nisso, então vale a pena ressaltar que o núcleo do
map e código de fatia no tempo de execução Go não é genérico no sentido de
usando polimorfismo de tipo. É genérico no sentido de que olha para
digite informações de reflexão para ver como mover e comparar o tipo
valores. Então temos prova por existência que é aceitável escrever
código "genérico" em Go escrevendo código não polimórfico que usa tipo
informações de reflexão de forma eficiente e, em seguida, envolver esse código em
clichê seguro em tempo de compilação (no caso de mapas e fatias
esta placa de caldeira é, obviamente, fornecida pelo compilador).

E é isso que um compilador transpilando de um superconjunto de Go com genéricos adicionados, produziria como código Go. Mas o embrulho não seria baseado em algum delineamento como pacote, pois faltaria a composabilidade que já mencionei. O ponto é que não há atalho para um bom sistema de tipos genéricos combináveis. Ou fazemos isso corretamente ou não fazemos nada, porque adicionar algum hack não combinável que não seja realmente genérico criará eventualmente uma inércia de retalhos de genericidade meia-boca de retalhos e irregularidade de casos de canto e soluções alternativas tornando o código do ecossistema Go ininteligível.

Também é verdade que a maioria das pessoas que escrevem grandes programas complexos em Go tem
não encontrou uma necessidade significativa de genéricos. Até agora tem sido mais como
uma verruga irritante - a necessidade de escrever três linhas de clichê para
cada tipo a ser classificado - em vez de uma grande barreira para escrever
código.

Sim, esse tem sido um dos pensamentos em minha mente sobre se ir para um sistema de classes de tipos completo é justificável. Se todas as suas bibliotecas são baseadas em torno dele, então, aparentemente, pode ser uma bela harmonia, mas se estamos contemplando a inércia dos hacks Go existentes para generalidade, talvez a sinergia adicional obtida seja baixa para muitos projetos ?

Mas se um transpilador de uma sintaxe typeclass emular a maneira manual existente Go pode modelar genéricos (Edit: que acabei de ler que @andrewcmyers afirma é plausível ), isso pode ser menos oneroso e encontrar sinergias úteis. Por exemplo, percebi que duas classes de tipo de parâmetro podem ser emuladas com interface implementado em um struct que emula uma tupla, ou @jba mencionou uma ideia para empregar interface inline no contexto . Aparentemente struct são estruturalmente em vez de nominalmente digitados a menos que seja dado um nome com type ? Também confirmei que um método de interface pode inserir outro interface para que seja possível transpilar de HKT no seu exemplo de classificação sobre o qual escrevi no meu post anterior aqui. Mas preciso pensar mais nisso quando não estiver com tanto sono.

Acho justo dizer que a maioria da equipe Go não gosta de C++
templates, nos quais uma linguagem Turing completa foi sobreposta
outra linguagem Turing completa tal que as duas linguagens tenham
sintaxes completamente diferentes, e programas em ambas as linguagens são
escrito de maneiras muito diferentes. Os modelos C++ servem como advertência
conto porque a implementação complexa permeou todo o
biblioteca padrão, fazendo com que as mensagens de erro C++ se tornem uma fonte de
maravilha e espanto. Este não é um caminho que Go jamais seguirá.

Duvido que alguém discorde! O benefício da monomorfização é ortogonal às desvantagens de um mecanismo de metaprogramação genérico completo de Turing.

Aliás, o erro de design dos modelos C++ me parece ser a mesma essência generativa da falha dos functores ML generativos (em oposição aos aplicativos). Aplica-se o Princípio da Menor Potência.

@ianlancetaylor escreveu:

É decepcionante ver o Go se tornando cada vez mais complexo ao adicionar tipos parametrizados embutidos.

Apesar da especulação nesta edição, acho extremamente improvável que isso aconteça.

Espero que sim. Acredito firmemente que o Go deveria adicionar um sistema genérico coerente ou simplesmente aceitar que nunca terá genéricos.

Acho que uma bifurcação para um transpilador é mais provável de acontecer, em parte porque tenho financiamento para implementá-lo e estou interessado em fazê-lo. Mas ainda estou analisando a situação.

Isso fraturaria o ecossistema, mas pelo menos o Go pode permanecer puro em seus princípios minimalistas. Assim, para evitar fraturar o ecossistema e permitir algumas outras inovações que eu gostaria, provavelmente não faria um superconjunto e o nomearia Zero .

@pciet escreveu:

Meu voto é não para genéricos de aplicativos generalizados, sim para funções genéricas mais internas como append e copy que funcionam em vários tipos de base. Talvez sort e search possam ser adicionados para os tipos de coleção?

Expandir essa inércia talvez impeça que um recurso genérico abrangente chegue ao Go. Aqueles que queriam genéricos provavelmente partiriam para pastos mais verdes. @andrewcmyers reiterou isso:

Seria decepcionante ver o Go se tornando cada vez mais complexo adicionando tipos parametrizados embutidos. Seria melhor apenas adicionar o suporte à linguagem para programadores escreverem seus próprios tipos parametrizados.

@shelby3

Afaik, a única maneira de fazer contêineres/coleções heterogêneos em Go agora é subsumir todos os tipos a uma interface vazia{} que está jogando fora as informações de digitação e eu presumo exigir casts e inspeção de tipo de tempo de execução, o que meio que anula o ponto de digitação estática.

Consulte o padrão de wrapper nos comentários acima para verificação de tipo estático de coleções{} de interface em Go.

O ponto é que não há atalho para um bom sistema de tipos genéricos combináveis. Ou fazemos corretamente ou não fazemos nada, porque adicionar algum hack não combinável que não é realmente genérico…

Você pode explicar isso mais? Para o caso de tipos de coleção, ter uma interface definindo o comportamento genérico necessário dos itens contidos parece razoável para escrever funções.

@pciet este código está literalmente fazendo exatamente o que @shelby3 estava descrevendo e considerando um antipadrão. Citando você de antes:

Isso fornece exemplos de documentação e teste que tipo wrapper pattern (obrigado @pierrre) para segurança de tipo em tempo de compilação e também tem a verificação de reflexão para segurança de tipo em tempo de execução.

Você está pegando código que não tem informações de tipo e, tipo por tipo, adicionando casts e inspeção de tipo de tempo de execução usando reflect. Isso é exatamente o que @shelby3 estava reclamando. Costumo chamar essa abordagem de "monomorfização manual" e é exatamente o tipo de tarefa tediosa que acho que é melhor para um compilador.

Esta abordagem tem uma série de desvantagens:

• Requer wrappers tipo por tipo, mantidos manualmente ou com uma ferramenta semelhante a go generate
• (Se feito à mão em vez de uma ferramenta) oportunidade de cometer erros no clichê que não serão detectados até o tempo de execução
• Requer despacho dinâmico em vez de despacho estático, que é mais lento e usa mais memória
• Usa reflexão de tempo de execução em vez de asserções de tipo de tempo de compilação, que também são lentas
• Não combinável: atua inteiramente em tipos concretos sem oportunidades de usar limites do tipo typeclass (ou mesmo do tipo interface) em tipos, a menos que você passe outra camada de indireção para cada interface não vazia sobre a qual você também deseja abstrair

Você pode explicar isso mais? Para o caso de tipos de coleção, ter uma interface definindo o comportamento genérico necessário dos itens contidos parece razoável para escrever funções.

Agora, em todos os lugares em que você deseja usar um limite em vez de ou além de um tipo concreto, também é necessário escrever o mesmo clichê de verificação de tipos para cada tipo de interface. Ele apenas compõe ainda mais a explosão (talvez combinatória) de wrappers de tipo estático que você precisa escrever.

Existem também ideias que, até onde eu sei, simplesmente não podem ser expressas no sistema de tipos do Go hoje, como um limite em uma combinação de interfaces. Imagine que temos:

type Foo interface {
    ...
}

type Bar interface {
    ...
}

Como expressamos, usando uma verificação de tipo puramente estática, que queremos um tipo que implemente Foo e Bar ? Até onde eu sei, isso não é possível em Go (exceto recorrer a verificações de tempo de execução que podem falhar, evitando a segurança do tipo estático).

Com um sistema genérico baseado em typeclass podemos expressar isso como:

func baz<T Foo + Bar>(t T) {
    ...
}

@tarcieri

Como expressamos, usando uma verificação de tipo puramente estática, que queremos um tipo que implemente Foo e Bar?

simplesmente assim:

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet puro, TIL

Pessoalmente, considero a reflexão de tempo de execução um recurso errado, mas isso sou só eu... Posso explicar o motivo se alguém estiver interessado.

Acho que qualquer um que implemente genéricos de qualquer tipo deveria ler primeiro os "Elementos de Programação" de Stepanov várias vezes. Isso evitaria muitos problemas de Not Invented Here e reinventaria a roda. Depois de ler isso, deve ficar claro por que "C++ Concepts" e "Haskell Typeclasses" são o caminho certo para fazer genéricos.

Vejo que este problema parece ativo novamente
Aqui está um playground de proposta de espantalho
https://go-li.github.io/test.html
basta colar programas de demonstração daqui
https://github.com/go-li/demo

Muito obrigado por sua avaliação deste único parâmetro
funções genéricas.

Mantemos o gccgo hackeado e
este projeto seria impossível sem você, então nós
queria contribuir de volta.

Também estamos ansiosos para quaisquer genéricos que você adote, continue com o ótimo trabalho!

@anlhor onde estão os detalhes de implementação sobre isso? Onde se pode ler sobre a sintaxe? O que é implementado? O que não é implementado? Quais são as especificações para essas implementações? Quais são os prós e contras disso?

O link do playground contém o pior exemplo possível disso:

package main

import "fmt"

func main() {
    fmt.Println("Hello, playground")
}

Esse código não me diz nada sobre como usá-lo e o que posso testar.

Se você pudesse melhorar essas coisas, ajudaria a entender melhor qual é a sua proposta e como ela se compara às anteriores / ver como os outros pontos levantados aqui se aplicam ou não a ela.

Espero que isso ajude você a entender os problemas com seu comentário.

@joho escreveu:

Haveria valor na literatura acadêmica para qualquer orientação sobre a avaliação de abordagens?

O único artigo que li sobre o assunto é Os desenvolvedores se beneficiam de tipos genéricos ? (paywall desculpe, você pode pesquisar no Google seu caminho para um download de pdf) que tinha o seguinte a dizer

Consequentemente, uma interpretação conservadora do experimento
é que os tipos genéricos podem ser considerados como uma compensação
entre as características positivas da documentação e a
características de extensibilidade negativa.

Presumo que OOP e subclasses (por exemplo, classes em Java e C++) não serão considerados seriamente porque Go já tem um tipo de tipo interface (sem o parâmetro de tipo genérico T explícito), Java é citado como o que não deve ser copiado, e porque muitos argumentaram que eles são um antipadrão. Upthread eu vinculei a alguns desses argumentos. Poderíamos aprofundar essa análise se alguém estiver interessado.

Eu ainda não estudei pesquisas mais recentes, como o sistema Genus mencionado upthread . Estou desconfiado de sistemas de “pia de cozinha” que tentam misturar tantos paradigmas (por exemplo, subclasses, herança múltipla, OOP, linearização de traços, implicit , typeclasses, tipos abstratos, etc), devido às reclamações sobre Scala ter tantos casos de canto na prática, embora talvez isso melhore com o Scala 3 (também conhecido como Dotty e o cálculo DOT). Estou curioso para saber se a tabela de comparação deles está comparando com o Scala 3 experimental ou a versão atual do Scala?

Então, afaics, o que resta são functores ML e classes de tipos Haskell em termos de sistemas de genéricos comprovados, que melhoram significativamente a extensibilidade e a flexibilidade em comparação com OOP + subclasses.

Eu escrevi algumas das discussões privadas que @keean e eu tivemos sobre módulos functor ML versus typeclasses. Os destaques parecem ser:

• typeclasses _modela uma álgebra_ (mas sem axiomas verificados ) e implementa cada tipo de dados para cada interface apenas de uma maneira. Permitindo assim a seleção implícita das implementações pelo compilador sem anotação no site da chamada.

• Os functores de aplicativo têm transparência referencial, enquanto os functores generativos criam uma nova instância em cada instanciação, o que significa que eles não são invariantes na ordem de inicialização.

• Functores de ML são mais poderosos/flexíveis do que typeclasses, mas isso tem o custo de mais anotações e potencialmente mais interações de casos de canto. E de acordo com @keean , eles exigem tipos dependentes (para tipos associados ), que é um sistema de tipos mais complexo. @keean acha que a _expressão de genericidade de Stepanov como uma álgebra_ plus typeclasses é suficientemente poderosa e flexível , de modo que parece ser o ponto ideal para a genericidade de ponta e comprovada (em Haskell e agora em Rust). No entanto, os axiomas não são impostos por typeclasses.

• Eu sugeri adicionar uniões para contêineres heterogêneos com typeclasses para estender ao longo de outro eixo do Problema de Expressão, embora isso exija imutabilidade ou cópia (apenas para os casos em que a extensibilidade heterogênea é empregada) que é conhecida por ter um O(log n) desaceleração em comparação com a imperatividade mutável irrestrita.

@larsth escreveu:

Pode ser interessante ter um ou mais transpiladores experimentais - um compilador de código-fonte Go genéricos para Go 1.xy.

_{PS Duvido que o Go adote um sistema de digitação tão sofisticado, mas estou contemplando um transpilador para a sintaxe Go existente, como mencionei no meu post anterior (veja a edição na parte inferior). E eu quero um sistema genérico robusto junto com esses recursos Go muito desejáveis. Genéricos Typeclass em Go parece ser o que eu quero.}

@bcmills escreveu sobre sua proposta sobre funções de tempo de compilação para generalidade:

Eu ouvi esse mesmo argumento usado para defender a exportação de tipos interface em vez de tipos concretos em APIs Go, e o inverso acaba sendo mais comum: a abstração prematura restringe os tipos e dificulta a extensão das APIs. (Para um exemplo, veja #19584.) Se você quiser confiar nessa linha de argumento, acho que precisa fornecer alguns exemplos concretos.

Certamente é verdade que as abstrações do sistema de tipos necessariamente abandonam alguns graus de liberdade e, às vezes, escapamos dessas restrições com “inseguro” (ou seja, em violação da abstração verificada estaticamente), mas isso deve ser compensado pelos benefícios de desacoplamento modular com invariantes anotados sucintamente.

Ao projetar um sistema para a generalidade, provavelmente desejamos aumentar a regularidade e a previsibilidade do ecossistema como um dos principais objetivos, especialmente se a filosofia central do Go for levada em consideração (por exemplo, programadores médios são uma prioridade).

Aplica-se o Princípio da Menor Potência. O poder/flexibilidade das funções de tempo de compilação “escondidas em” para generalidade tem que ser ponderado em relação à sua capacidade de prejudicar, por exemplo, a legibilidade do código-fonte no ecossistema (onde o desacoplamento modular é extremamente importante porque o leitor não 'não precisa ler uma quantidade de código potencialmente ilimitada devido a dependências transitivas implícitas, para entender um determinado módulo/pacote!). A resolução implícita de instâncias de implementação de typeclass tem esse problema se sua álgebra não for respeitada .

Claro, mas isso já é verdade para muitas restrições implícitas em Go, independentemente de qualquer mecanismo de programação genérico.

Por exemplo, uma função pode receber um parâmetro do tipo interface e inicialmente chamar seus métodos sequencialmente. Se essa função for alterada posteriormente para chamar esses métodos simultaneamente (gerando goroutines adicionais), a restrição "deve ser segura para uso simultâneo" não será refletida no sistema de tipos.

Mas o afaik Go não tentou projetar uma abstração para modular esses efeitos. Rust tem essa abstração (que, aliás, acho que é um exagero pita/tsuris/limiting para alguns/a maioria dos casos de uso e defendo uma abstração de modelo de thread único mais fácil, mas infelizmente o Go não suporta a restrição de todas as goroutines geradas ao mesmo thread ) . E Haskell requer controle monádico sobre os efeitos devido à imposição de funções puras para transparência referencial .

@alerca escreveu:

Acho que a maior desvantagem das restrições inferidas é que elas facilitam o uso de um tipo de uma maneira que introduz uma restrição sem entendê-la completamente. Na melhor das hipóteses, isso significa apenas que seus usuários podem se deparar com falhas inesperadas em tempo de compilação, mas na pior das hipóteses, isso significa que você pode quebrar o pacote para os consumidores introduzindo uma nova restrição inadvertidamente. Restrições especificadas explicitamente evitariam isso.

Acordado. Ser capaz de quebrar código clandestinamente em outros módulos porque os invariantes dos tipos não são explicitamente anotados é notoriamente insidioso.

@andrewcmyers escreveu:

Para ser claro, não considero a geração de código no estilo macro, seja feita com gen, cpp, gofmt -r ou outras ferramentas de macro/modelo, como uma boa solução para o problema dos genéricos, mesmo que padronizada. Ele tem os mesmos problemas que os modelos C++: código bloat, falta de verificação de tipo modular e dificuldade de depuração. Fica pior quando você começa, como é natural, construir código genérico em termos de outro código genérico. Na minha opinião, as vantagens são limitadas: manteria a vida relativamente simples para os escritores do compilador Go e produz código eficiente - a menos que haja pressão de cache de instruções, uma situação frequente em software moderno!

@keean parece concordar com você.

@shelby3 obrigado pelos comentários. Você pode da próxima vez fazer os comentários/edições diretamente no próprio documento. É mais fácil rastrear onde as coisas precisam ser corrigidas e mais fácil garantir que todas as notas recebam uma resposta adequada.

A seção Visão geral parece implicar que o uso universal de referências de boxing do Java para instâncias ...

Adicionado comentário para deixar claro que não se trata de uma lista abrangente. Está lá principalmente para que as pessoas entendam a essência de diferentes trade-offs. A lista completa de diferentes abordagens está mais abaixo.

Estruturas genéricas tendem a acumular recursos de todos os usos, resultando em tempos de compilação maiores ou em excesso de código ou na necessidade de um vinculador mais inteligente.
Para typeclasses, isso não é verdade ou é um problema menor, porque as interfaces só precisam ser implementadas para tipos de dados fornecidos a funções que usam essas interfaces. Typeclasses são sobre a vinculação tardia da implementação à interface, ao contrário da OOP, que vincula todos os tipos de dados aos seus métodos para a implementação da classe.

Essa afirmação é sobre o que acontece com estruturas de dados genéricas a longo prazo. Em outras palavras, uma estrutura de dados genérica geralmente acaba coletando todos os diferentes usos - em vez de ter várias implementações menores para diferentes propósitos. Apenas como exemplo, veja https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

É importante notar que, apenas o "design mecânico" e "quanta flexibilidade" não é suficiente para criar uma boa "solução genérica". Também precisa de boas instruções, como as coisas devem ser usadas e o que evitar, e considere como as pessoas acabam usando.

Estruturas genéricas e as APIs que operam nelas tendem a ser mais abstratas do que as APIs construídas para fins específicos...

Um contra-argumento que acho que melhora significativamente essa preocupação é que a carga cognitiva de aprender um número ilimitado de reimplementações de casos especiais dos algoritmos genéricos essencialmente iguais é ilimitada ...

Adicionada uma nota sobre a carga cognitiva de muitas APIs semelhantes.

As reimplementações de casos especiais não são ilimitadas na prática. Você verá apenas um número fixo de especialização.

Este não é um contra válido.

Você pode discordar de alguns pontos, eu discordo de alguns deles até certo ponto, mas eu entendo o ponto de vista deles e tento entender os problemas que as pessoas enfrentam no dia-a-dia. O objetivo do documento é coletar opiniões diferentes, não julgar "como algo é irritante para alguém".

No entanto, o documento se posiciona sobre "problemas rastreáveis ​​a problemas do mundo real", porque problemas abstratos e facilitados em fóruns tendem a se transformar em conversas sem sentido sem que qualquer entendimento seja construído.

O que realmente estamos chegando aqui é a regularidade de uma linguagem e APIs genéricas ajudam, não prejudicam isso.

Claro que na prática você pode precisar desse estilo de otimização apenas para menos de 1% dos casos.

Soluções alternativas:

As soluções alternativas não se destinam a substituir os genéricos. Mas, sim, uma lista de possíveis soluções para diferentes tipos de problemas.

Modelos de pacote

Posso estar enganado, mas isso não parece muito correto. Os functores ML (não devem ser confundidos com os functores FP) também podem retornar uma saída que permanece parametrizada por tipo.

Você pode fornecer uma redação mais clara e, se necessário, dividir em duas abordagens diferentes?

@egonelbre obrigado também por responder para que eu possa saber em quais pontos preciso esclarecer melhor meus pensamentos.

Você pode da próxima vez fazer os comentários/edições diretamente no próprio documento.

Desculpe, gostaria de poder cumprir, mas nunca usei os recursos de discussão do Google Doc, não tenho tempo para aprender e também prefiro poder vincular minhas discussões no Github para referência futura.

Apenas como exemplo, veja https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

O design da biblioteca de coleções do Scala foi criticado por muitas pessoas, incluindo um dos ex-membros da equipe-chave . Um comentário postado na LtU é representativo. Observe que adicionei o seguinte a uma das minhas postagens anteriores neste tópico para resolver isso:

Estou desconfiado de sistemas de “pia de cozinha” que tentam misturar tantos paradigmas (por exemplo, subclasses, herança múltipla, OOP, linearização de traços, implicit , typeclasses, tipos abstratos, etc), devido às reclamações sobre Scala ter tantos casos de canto na prática, embora talvez isso melhore com o Scala 3 (também conhecido como Dotty e o cálculo DOT).

Eu não acho que a biblioteca de coleções do Scala seria representativa de bibliotecas criadas para uma PL com apenas typeclasses para polimorfismo. De fato, as coleções Scala empregam o anti-padrão de herança , o que causou as hierarquias complexas, combinado com ajudantes implicit como CanBuildFrom que explodiram o orçamento da complexidade. E acho que se o ponto de @keean for respeitado sobre os _Elements of Programming_ de Stepanov ser uma álgebra , uma biblioteca de coleções elegante poderia ser criada. Foi a primeira alternativa que vi para uma biblioteca de coleções baseada em functor (FP) (ou seja, não copiando Haskell ) também baseada em matemática. Eu quero ver isso na prática, que é uma das razões pelas quais estou colaborando/discutindo com ele no projeto de um novo PL. E a partir deste momento, estou planejando que essa linguagem inicialmente transpile para Go (embora eu esteja há anos tentando encontrar uma maneira de evitar fazê-lo). Espero que possamos experimentar em breve para ver como funciona.

Minha percepção é que a comunidade/filosofia Go prefere esperar para ver o que funciona na prática e adotá-lo mais tarde, uma vez comprovado, do que se apressar e poluir a linguagem com experimentos fracassados. Porque, como você reiterou, todas essas alegações abstratas não são tão construtivas (exceto talvez para os teóricos do design PL). Também é provavelmente implausível projetar um sistema de genéricos coerente por comitê.

Também precisa de boas instruções, como as coisas devem ser usadas e o que evitar, e considere como as pessoas acabam usando.

E acho que vai ajudar não misturar tantos paradigmas diferentes disponíveis para o programador na mesma linguagem. Aparentemente, não é necessário ( @keean e eu precisamos provar essa afirmação). Acho que nós dois atribuímos a filosofia de que o orçamento de complexidade é finito e é o que você deixa de fora do PL que é tão importante quanto os recursos incluídos.

No entanto, o documento se posiciona sobre "problemas rastreáveis ​​a problemas do mundo real", porque problemas abstratos e facilitados em fóruns tendem a se transformar em conversas sem sentido sem que qualquer entendimento seja construído.

Acordado. E também é difícil para todos seguirem os pontos abstratos. O diabo está nos detalhes e nos resultados reais na natureza.

Claro que na prática você pode precisar desse estilo de otimização apenas para menos de 1% dos casos.

Go já possui interface para genericidade, podendo assim tratar os casos em que não necessite de polimorfismo paramétrico no tipo T para a instância da interface fornecida pelo site de chamada.

Acho que li em algum lugar, talvez tenha sido upthread, o argumento de que na verdade a biblioteca padrão do Go está sofrendo com a inconsistência do uso ideal dos idiomas mais atualizados. Não sei se isso é verdade, pois ainda não tenho experiência com Go. O que quero dizer é que o paradigma de genéricos escolhido infecta todas as bibliotecas. Então sim, a partir de agora você pode afirmar que apenas 1% do código precisaria dele, porque já há inércia em idiomas que evitam a necessidade de genéricos.

Você pode estar correto. Também tenho meu ceticismo sobre o quanto usarei qualquer recurso de linguagem específico. Acho que a experimentação para descobrir é o caminho que vou seguir. O projeto PL é um processo iterativo, então o problema é lutar contra a inércia que se desenvolve dificulta a iteração do processo. Então eu acho que Rob Pike está correto no vídeo onde ele sugere escrever programas que escrevem código para programas (ou seja, vão escrever ferramentas de geração e transpiladores) para experimentar e testar ideias.

Quando pudermos mostrar que um conjunto específico de recursos é superior na prática (e esperamos também popularidade de uso) àqueles atualmente em Go, talvez possamos ver algum consenso sobre adicioná-los ao Go. Eu encorajo outros a também criarem sistemas experimentais que transpilem para Go.

Você pode fornecer uma redação mais clara e, se necessário, dividir em duas abordagens diferentes?

Eu adiciono minha voz àqueles que querem desencorajar a tentativa de colocar algum recurso de modelagem excessivamente simplista em Go e alegar que é genérico. IOW, eu acho que um sistema genérico de funcionamento adequado que não vai acabar sendo uma inércia ruim é fundamentalmente incompatível com o desejo de ter um design excessivamente simplista para genéricos. Afaik, um sistema genérico precisa de um design holístico bem pensado e comprovado. Ecoando o que @larsth escreveu , encorajo aqueles com propostas sérias a primeiro construir um transpilador (ou implementar em um fork do frontend gccgo) e depois experimentar a proposta para que todos possamos entender melhor suas limitações. Fui encorajado a ler upthread que @ianlancetaylor não achava que uma poluição de inércia ruim seria adicionada ao Go. Quanto à minha reclamação específica sobre a proposta de parametrização de nível de pacote, minha sugestão para quem está propondo, por favor, considere se deve fazer um compilador que todos possamos usar para brincar e então todos podemos falar sobre exemplos do que gostamos e não t gosto sobre isso. Caso contrário, estamos nos enganando porque talvez eu nem tenha entendido corretamente a proposta descrita abstratamente. Não devo entender a proposta, pois não entendo como a embalagem parametrizada pode ser reutilizada em outra embalagem também parametrizada. IOW, se um pacote recebe parâmetros, ele também precisa instanciar outros pacotes com parâmetros. Mas parecia que a proposta estava afirmando que a única maneira de instanciar um pacote parametrizado era com um tipo concreto, não com parâmetros de tipo.

Desculpa tão prolixo. Quero ter certeza de que não estou sendo mal interpretado.

@ shelby3 ah, então não entendi a reclamação inicial. Em primeiro lugar, devo deixar claro que as seções em "Abordagens Genéricas" não são propostas concretas. São abordagens ou, em outras palavras, decisões de design maiores que podem ser tomadas em uma abordagem genérica concreta. No entanto, os agrupamentos são fortemente motivados por implementações existentes ou propostas concretas/informais. Além disso, suspeito que ainda faltam pelo menos 5 grandes ideias nessa lista.

Para a abordagem de "modelos de pacote" existem duas variações dela (veja as discussões vinculadas no documento):

1. pacotes genéricos baseados em "interface",
2. pacotes explicitamente genéricos.

Para 1. ele não requer que o pacote genérico faça nada de especial -- por exemplo, o atual container/ring se tornaria utilizável para especialização. Imagine "especialização" aqui substituindo todas as instâncias da interface no pacote pelo tipo concreto (e ignorando importações circulares). Quando esse pacote especializa outro pacote, ele pode usar a "interface" como a especialização - segue que então esse uso também será especializado.

Para 2. você pode olhar para eles de duas maneiras. Uma é a especialização concreta recursiva em cada importação - semelhante ao modelo/macroing, em nenhum momento haveria um "pacote parcialmente aplicado". Claro que também pode ser visto do lado funcional, que o pacote genérico é um parcial com parâmetros e então você o especializa.

Então, sim, você pode usar um pacote parametrizado em outro.

Ecoando o que @larsth escreveu, encorajo aqueles com propostas sérias a primeiro construir um transpilador (ou implementar em um fork do frontend gccgo) e depois experimentar a proposta para que todos possamos entender melhor suas limitações.

Eu sei que isso não foi explicitamente direcionado a essa abordagem, mas tem 4 protótipos diferentes para testar a ideia. Claro, eles não são transpiladores completos, mas são suficientes para testar algumas das ideias. ou seja, não tenho certeza se alguém implementou o caso "usando pacote parametrizado de outro".

Pacotes parametrizados soam muito como módulos de ML (e functores de ML são os parâmetros que podem ser outros pacotes). Existem duas maneiras de trabalhar "aplicativo" ou "generativo". Um functors aplicativo é como um valor ou um tipo de alias. Um functor generativo deve ser construído e cada instância é diferente. Outra maneira de pensar sobre isso é que para um pacote ser aplicativo ele deve ser puro (ou seja, não há variáveis ​​mutáveis ​​no nível do pacote). Se houver estado no nível do pacote, ele deve ser generativo, pois esse estado precisa ser inicializado, e importa qual "instância" de um pacote generativo você realmente passa como parâmetro para outros pacotes que, por sua vez, devem ser generativos. Por exemplo, os pacotes Ada são generativos.

O problema com a abordagem de pacotes generativos é que ela cria muitos clichês, onde você está instanciando pacotes com parâmetros. Você pode olhar os genéricos da Ada para ver como é isso.

As classes de tipo evitam esse clichê selecionando implicitamente a classe de tipo com base nos tipos usados ​​apenas na função. Você também pode visualizar as classes de tipo como sobrecarga restrita com despacho múltiplo, onde a resolução de sobrecarga quase sempre ocorre estaticamente em tempo de compilação, com exceções para recursão polimórfica e tipos existenciais (que são essencialmente variantes das quais você não pode converter, você só pode usar as interfaces para as quais a variante confirma).

Um functors aplicativo é como um valor ou um tipo de alias. Um functor generativo deve ser construído e cada instância é diferente. Outra maneira de pensar sobre isso é que para um pacote ser aplicativo ele deve ser puro (ou seja, não há variáveis ​​mutáveis ​​no nível do pacote). Se houver estado no nível do pacote, ele deve ser generativo, pois esse estado precisa ser inicializado, e importa qual "instância" de um pacote generativo você realmente passa como parâmetro para outros pacotes que, por sua vez, devem ser generativos. Por exemplo, os pacotes Ada são generativos.

Obrigado pela terminologia exata, preciso pensar em como integrar essas ideias no documento.

Além disso, não consigo ver uma razão pela qual você não poderia ter um "alias de tipo automático para um pacote gerado" - em certo sentido, algo entre a abordagem "functor aplicativo" e "funtor generativo". Obviamente, quando o pacote contém alguma forma de estado, pode ser complicado depurar e entender.

O problema com a abordagem de pacotes generativos é que ela cria muitos clichês, onde você está instanciando pacotes com parâmetros. Você pode olhar os genéricos da Ada para ver como é isso.

Até onde eu vejo, isso criaria menos clichê do que modelos C++, mas mais do que classes de tipo. Você tem um bom programa do mundo real para Ada que demonstre o problema? _(Por mundo real, quero dizer código que alguém está/estava usando na produção.)_

Claro, dê uma olhada no meu go-board Ada: https://github.com/keean/Go-Board-Ada/blob/master/go.adb

Embora esta seja uma definição bastante vaga de produção, o código é otimizado, funciona tão bem quanto a versão C++ e seu código aberto, e o algoritmo foi refinado ao longo de vários anos. Você também pode ver a versão C++: https://github.com/keean/Go-Board/blob/master/go.cpp

Isso mostra (eu acho) que os genéricos de Ada são uma solução mais limpa que os templates C++ (mas isso não é difícil), por outro lado é difícil fazer o acesso rápido às estruturas de dados em Ada devido às restrições em retornar uma referência .

Se você quiser olhar para um sistema de pacotes genéricos para uma linguagem imperativa, acho que Ada é um dos melhores para olhar. É uma pena que eles decidiram seguir vários paradigmas e adicionar todas as coisas OO à Ada. Ada é um Pascal aprimorado, e Pascal era uma linguagem pequena e elegante. Os genéricos Pascal mais Ada ainda seriam uma linguagem bem pequena, mas teriam sido muito melhores na minha opinião. Porque o foco da Ada mudou para uma abordagem OO, encontrar boa documentação e exemplos de como fazer as mesmas coisas com genéricos parece difícil de encontrar.

Embora eu ache que as classes de tipos têm algumas vantagens, eu poderia viver com os genéricos do estilo Ada, há alguns problemas que me impedem de usar Ada mais amplamente, acho que ele obtém valores/objetos errados (acho que poucas linguagens acertam, 'C' sendo um dos únicos), é difícil trabalhar com ponteiros (variáveis ​​de acesso) e criar abstrações de ponteiro seguro, e não fornece uma maneira de usar pacotes com polimorfismo de tempo de execução (fornece um modelo de objeto para isso, mas adiciona um paradigma totalmente novo em vez de tentar encontrar uma maneira de ter polimorfismo em tempo de execução usando pacotes).

A solução para o polimorfismo em tempo de execução é tornar os pacotes de primeira classe para que instâncias de assinaturas de pacotes possam ser passadas como argumentos de função, isso infelizmente requer tipos dependentes (veja o trabalho feito em Tipos de Objetos Dependentes para Scala para limpar a bagunça que eles fizeram com seu sistema de tipos original).

Então, acho que os genéricos de pacote podem funcionar, mas Ada levou décadas para lidar com todos os casos extremos, então eu examinaria um sistema de genéricos de produção para ver quais refinamentos usam na produção produzida. No entanto, Ada ainda fica aquém porque os pacotes não são de primeira classe e não podem ser usados ​​em polimorfismo de tempo de execução, e isso precisaria ser resolvido.

@keean escreveu :

Pessoalmente, considero a reflexão de tempo de execução um recurso errado, mas isso sou só eu... Posso explicar o motivo se alguém estiver interessado.

O apagamento de tipo permite “Teoremas de graça”, o que tem implicações práticas . A reflexão de tempo de execução gravável (e talvez até legível devido a relações transitivas com código imperativo?) torna impossível garantir transparência referencial em qualquer código e, portanto, certas otimizações de compilador não são possíveis e mônadas seguras de tipo não são possíveis. Percebo que Rust ainda não tem um recurso de imutabilidade. OTOH, a reflexão permite outras otimizações que não seriam possíveis se não pudessem ser digitadas estaticamente.

Eu também havia declarado upthread:

E é isso que um compilador transpilando de um superconjunto de Go com genéricos adicionados, produziria como código Go. Mas o embrulho não seria baseado em algum delineamento como pacote, pois faltaria a composabilidade que já mencionei. O ponto é que não há atalho para um bom sistema de tipos genéricos combináveis. Ou fazemos isso corretamente ou não fazemos nada, porque adicionar algum hack não combinável que não seja realmente genérico criará eventualmente uma inércia de retalhos de genericidade meia-boca de retalhos e irregularidade de casos de canto e soluções alternativas tornando o código do ecossistema Go ininteligível.

@keean escreveu:

[…] para que um pacote seja aplicativo, ele deve ser puro (ou seja, não há variáveis ​​mutáveis ​​no nível do pacote)

E nenhuma função impura pode ser empregada para inicializar variáveis ​​imutáveis.

@egonelbre escreveu:

Então, sim, você pode usar um pacote parametrizado em outro.

O que eu aparentemente tinha em mente eram “pacotes parametrizados de primeira classe” e o polimorfismo de tempo de execução proporcional (também conhecido como dinâmico) que @keean mencionou posteriormente, porque presumi que os pacotes parametrizados foram propostos em vez de typeclasses ou OOP.

EDIT: mas existem dois significados possíveis para módulos de “primeira classe”: módulos como valores de primeira classe, como em Successor ML e MixML, distinguidos de módulos como valores de primeira classe com tipos de primeira classe como em 1ML, e a compensação necessária na recursão do módulo (ou seja, misturando ) entre eles.

@keean escreveu:

A solução para o polimorfismo em tempo de execução é tornar os pacotes de primeira classe para que instâncias de assinaturas de pacotes possam ser passadas como argumentos de função, isso infelizmente requer tipos dependentes (veja o trabalho feito em Tipos de Objetos Dependentes para Scala para limpar a bagunça que eles fizeram com seu sistema de tipos original).

O que você quer dizer com tipos dependentes? (EDIT: presumo que agora ele quis dizer digitação “não dependente de valor”, ou seja, “ funções cujo tipo de resultado depende do argumento [runtime?] ['s type]”) Certamente não depende dos valores de, por exemplo int dados, como em Idris. Acho que você está se referindo à digitação dependente (ou seja, rastreamento) do tipo dos valores que representam instâncias de módulo instanciadas na hierarquia de chamadas para que essas funções polimórficas possam ser monomorfizadas em tempo de compilação? O polimorfismo de tempo de execução entra devido a esses tipos monomorfizados serem o tipo existencial vinculado a tipos dinâmicos? F-ing Modules demonstraram que tipos “dependentes” não são absolutamente necessários para modelar módulos ML no sistema F _ω . Simplifiquei demais se presumir que @rossberg reformulou o modelo de tipagem para remover todos os requisitos de monomorfização?

O problema com a abordagem de pacote generativo é que ela cria muitos clichês […]
As classes de tipo evitam esse clichê selecionando implicitamente a classe de tipo com base nos tipos usados ​​apenas na função.

Não existe também um clichê com functores de ML de aplicativo? Não há unificação conhecida de typeclasses e functors ML (módulos) que retém a brevidade sem introduzir restrições que são necessárias para evitar (cf também ) a antimodularidade inerente do critério de exclusividade global de instâncias de implementação de typeclass.

Typeclasses só podem implementar cada tipo de uma maneira e, de outra forma, requerem o clichê do wrapper newtype para superar a limitação. Aqui está outro exemplo de várias maneiras de implementar um algoritmo. Afaics, @keean contornou essa limitação em seu exemplo de classificação typeclass substituindo a seleção implícita por um Relation explicitamente selecionado empregando tipos de quebra data para nomear diferentes relações genericamente no tipo de valor, mas estou duvidando se tais táticas são gerais para todas as variantes de modularidade. No entanto, uma solução mais generalizada (que pode ajudar a melhorar o problema de modularidade da singularidade global , possivelmente combinada com uma restrição órfã como melhoria do versionamento proposto para resolução órfã , empregando um não padrão para implementações que poderiam ser órfãs) pode ser ter um parâmetro de tipo extra implicitamente em todos os typeclass interface , que quando não especificado é padronizado para a correspondência implícita normal, mas quando especificado (ou quando não especificado não corresponde a nenhum outro ² ) seleciona a implementação que tem o mesmo valor em sua lista delimitada por vírgulas de valores personalizados (portanto, isso é uma correspondência modular mais generalizada do que nomear uma instância implement específica). A lista delimitada por vírgulas é para que uma implementação possa ser diferenciada em mais de um grau de liberdade, como se tivesse duas especializações ortogonais. O especializado não padrão desejado pode ser especificado na declaração da função ou no site de chamada. No local da chamada, por exemplo, f<non-default>(…) .

Então, por que precisaríamos de módulos parametrizados se tivéssemos typeclasses? Afaics apenas para (← link importante para clicar) substituição porque a reutilização de typeclasses para esse propósito não se encaixa bem, por exemplo, queremos que um módulo de pacote seja capaz de abranger vários arquivos e queremos poder abrir implicitamente o conteúdo de o módulo no escopo sem clichê adicional . Então, talvez seguir em frente com uma parametrização de pacote _sintático-somente_ de substituição (não de primeira classe) seja um primeiro passo razoável que possa abordar a generalidade no nível do módulo, permanecendo aberto à compatibilidade e não sobreposição de funcionalidade se adicionar classes de tipo posteriormente para nível de função genericidade. macros são, por exemplo , digitadas ou apenas substituição sintática (também conhecida como “pré-processador”). Se digitado, os módulos duplicam a funcionalidade de typeclasses, o que é indesejável tanto do ponto de vista de minimizar os paradigmas/conceitos sobrepostos do PL quanto possíveis casos de canto devido a interações da sobreposição ( como aquelas ao tentar oferecer functores e typeclasses de ML ). Os módulos tipados são mais modulares porque as modificações em qualquer implementação encapsulada dentro do módulo que não modifica as assinaturas exportadas não podem fazer com que os consumidores do módulo se tornem incompatíveis (além do problema de antimodularidade mencionado acima de instâncias de implementação sobrepostas de typeclass). Estou interessado em ler os pensamentos de @keean sobre isso.

[…] com exceções para recursão polimórfica e tipos existenciais (que são essencialmente variantes das quais você não pode expulsar, você só pode usar as interfaces para as quais a variante confirma).

Para ajudar outros leitores. Por “recursão polimórfica”, acho que se refere a tipos de classificação mais alta, por exemplo, retornos de chamada parametrizados definidos em tempo de execução, onde o compilador não pode monomorfizar o corpo da função de retorno de chamada porque não é conhecido em tempo de compilação. Os tipos existenciais são, como mencionei antes, equivalentes aos objetos trait de Rust, que são uma maneira de obter contêineres heterogêneos com uma ligação posterior no problema de expressão do que class subclasse herança virtual, mas não tão aberta à extensão na expressão Problema como uniões com estruturas de dados imutáveis ​​ou copiando ³ que têm um custo de desempenho O(log n) .

¹ _{O que não requer HKT no exemplo acima, porque SET não está exigindo o tipo elem é um parâmetro de tipo do tipo genérico de set , ou seja, não é set<elem> .}

² _{No entanto, se existisse mais de uma implementação não padrão e nenhuma implementação padrão, a seleção seria ambígua, de modo que o compilador deveria gerar um erro.}

³ _{Observe que a mutação com estruturas de dados imutáveis ​​não exige necessariamente a cópia de toda a estrutura de dados, se a estrutura de dados for inteligente o suficiente para isolar o histórico, como uma lista vinculada individualmente.}

Implementar func pick(a CollectionOfT, count uint) []T seria um bom exemplo de aplicação de genéricos (de https://github.com/golang/go/issues/23717):

// pick returns a slice (len = n) of pseudorandomly chosen elements 
// in unspecified order from c which is an array, slice, or map.
for i, e := range pick(c, n) {

A abordagem{} da interface aqui é complicada.

Comentei algumas vezes sobre esse problema que um dos principais problemas com a abordagem de modelo C++ é sua dependência da resolução de sobrecarga como mecanismo para metaprogramação em tempo de compilação.

Parece que Herb Sutter chegou à mesma conclusão: agora existe uma proposta interessante para programação em tempo de compilação em C++ .

Ele tem alguns elementos em comum com o pacote Go reflect e minha proposta anterior para funções de tempo de compilação em Go .

Oi.
Escrevi uma proposta de genéricos com restrições para Go. Você pode lê-lo aqui . Talvez possa ser adicionado como um documento de 15292. É principalmente sobre restrições e é lido como uma emenda aos Parâmetros de tipo de Taylor em Go .
Ele pretende ser um exemplo de uma maneira viável (eu acredito) de fazer genéricos 'tipo seguro' em Go, - espero que possa adicionar algo a essa discussão.
Observe que, embora eu tenha lido (a maioria) este tópico muito longo, não segui todos os links nele, portanto, outros podem ter feito sugestões semelhantes. Se for o caso, peço desculpas.

br. Chr.

Sintaxe bikeshedding:

constraint[T] Array {
    :[#]T
}

poderia ser

type [T] Array constraint {
    _ [...]T
}

que se parece mais com Go to me. :-)

Vários elementos aqui.

Uma coisa é substituir : por _ e substituir # por ... .
Suponho que você poderia fazer isso se preferir.

Outra coisa é substituir constraint[T] Array por type[T] Array constraint .
Isso parece indicar que as restrições são tipos, o que não acho correto. Formalmente, uma restrição é um _predicado_ no conjunto de todos os tipos, ou seja. um mapeamento do conjunto de tipos para o conjunto { true , false }.
Ou, se preferir, você pode pensar em uma restrição simplesmente como _um conjunto de_ tipos.
Não é do tipo _a_.

br. Chr.

Por que constraint não é apenas um interface ?

type [T io.Writer] List struct { 
    element T; 
    next *List[T];
}

Uma interface seria um pouco mais útil como restrição com a seguinte proposta: #23796 que por sua vez também daria algum mérito à própria proposta.

Além disso, se a proposta de tipos de soma for aceita de alguma forma (#19412), eles devem ser usados ​​para restringir o tipo.

Embora eu acredite na palavra-chave constraint, algo parecido deve ser adicionado, para não repetir grandes restrições e evitar erros devido à distração.

Finalmente, para a parte do bikeshedding, acho que as restrições devem ser listadas no final de uma definição, para evitar superlotação (ferrugem parece ter uma boa ideia aqui):

// similar to the map[T]... syntax
// also no constraint
type List[T] struct {
    element T
    next *List[T]
}

// with constraint
type List[T] struct {
    element T
    next *List[T]
} where T is io.Writer | encoding.BinaryMarshaler

type BigConstraint constraint {
     io.Writer
     SomeFunc() int
     AnotherFunc()
     AField int64
     StringField string
}


// with predefined constraint
type List[T, U] struct {
    element T
    val U
    next *List[T, U]
} where T is BigConstraint | encoding.BinaryMarshaler,
    U is io.Reader

@urandom : Acho que é uma grande vantagem ter interfaces implementadas implicitamente em vez de explicitamente. A proposta @surlykke neste comentário eu acho que é muito mais próxima de outra sintaxe Go em espírito.

@surlykke Peço desculpas se a proposta tiver a resposta para alguma delas.

Um uso de genéricos é permitir funções de estilo internas. Como você implementaria o len no nível do aplicativo com isso? O layout da memória é diferente para cada entrada permitida, então como isso é melhor do que uma interface?

A “escolha” descrita anteriormente tem um problema semelhante em que a indexação em um mapa versus a indexação em uma fatia são diferentes. No caso do mapa, se houve uma conversão para slice primeiro, o mesmo código de picking pode ser usado, mas como isso é feito?

Coleções é outro uso:

// An unordered collection of comparable items.
type [T Comparable] Set []T

func (a Set) Diff(from Set) Set {
    // the implementation is the same as one with
    //     type Comparable interface { Equal(Comparable) bool }
    //     type Set []Comparable
}

// compile error
d := Set[int]{1, 2}.Diff(Set[string]{“abc”, “def”})

// Go 1, easier to read but runtime error
d := Set{1, 2}.Diff(Set{“abc”, “def”})

Para o caso do tipo de coleção, não estou convencido de que isso seja uma grande vitória sobre os genéricos do Go 1, pois há compensações de legibilidade.

Eu concordo que os parâmetros de tipo devem ter algum tipo de restrição. Caso contrário, estaremos repetindo os erros dos modelos C++. A questão é: quão expressivas devem ser as restrições?

Em uma extremidade, poderíamos apenas usar interfaces. Mas, como você aponta, muitos padrões úteis não podem ser capturados dessa maneira.

Depois, há sua ideia, e outras semelhantes, que tentam criar um conjunto de restrições úteis e fornecer uma nova sintaxe para expressá-las. Além do problema de adicionar ainda mais sintaxe, não está claro onde parar. Como você aponta, sua proposta captura muitos padrões, mas não todos.

No outro extremo está a ideia que proponho neste documento . Ele usa o próprio código Go como a linguagem de restrição. Você pode capturar praticamente qualquer restrição dessa maneira e não requer uma nova sintaxe.

@jba
É um pouco verboso. Talvez se Go tivesse uma sintaxe lambda seria um pouco mais palatável. Por outro lado, parece que o maior problema que está tentando resolver é verificar se um tipo suporta algum tipo de operador. Poderia ser mais fácil se o Go tivesse interfaces predefinidas para vários operadores:

func equal[T](x, y T) bool
    where T is runtime.Equitable {
    return x == y
}

func copyable[T](x, y []T) int {
    return copy(x, y)
}

ou algo nesse sentido.

Se o problema for com a extensão de builtins, talvez o problema esteja na maneira como a linguagem cria tipos de adaptadores. Por exemplo, o inchaço associado a sort.Interface não é a razão por trás de https://github.com/golang/go/issues/16721 e sort.Slice?
Olhando para https://github.com/golang/go/issues/21670#issuecomment -325739411, a ideia de @Sajmani de ter literais de interface pode ser o ingrediente necessário para que os parâmetros de tipo funcionem facilmente com builtins.
Veja a seguinte definição de Iterador:

type [T] Iterator interface {
    Next() (elem T, done bool)
}

Se print for uma função que simplesmente itera sobre uma lista e imprime seu conteúdo, o exemplo a seguir usa literais de interface para construir uma interface satisfatória para print .

func SliceIterator(slice []T) Iterator {
    i := 0
    return Iterator{
        Next: func() (elem int, done bool) {
            v := slice[i]
            if i+1 == len(slice) {
                return v, true
            }
            i++
            return v, false
        },
    }
}

func main() {
    arr := []int{1,2,3,4,5}
    // SliceIterator works for an arbitrary slice
    print(SliceIterator(arr))
}

Já se pode fazer isso se eles declararem globalmente tipos cuja única responsabilidade é satisfazer uma interface. No entanto, essa conversão de uma função para um método torna as interfaces (e, portanto, as "restrições") mais fáceis de satisfazer. Não poluímos declarações de nível superior com adaptadores simples (como "widgetsByName" na classificação).
Os tipos definidos pelo usuário obviamente também podem aproveitar esse recurso, como visto neste exemplo de LinkedList:

type ListNode struct {
    v string
    next *ListNode
}
func (l *ListNode) Iterator() Iterator {
    ptr := l
    return Iterator{
        Next: func() (elem int, done bool) {
            v := ptr.v
            if ptr.next == nil {
                return v, true
            }
            ptr = ptr.next
            return v, false
        },
    }
}

@geovanisouza92 : Restrições como as descrevi são mais expressivas do que interfaces (campos, operadores). Eu considerei brevemente estender interfaces em vez de introduzir restrições, mas acho que seria uma mudança muito intrusiva para um elemento existente do Go.

@pciet Não tenho certeza do que você quer dizer com 'nível de aplicativo'. Go tem uma função len embutida que pode ser aplicada a array, ponteiro para array, slice, string e canal, então, na minha proposta, se um parâmetro de tipo é restrito a ter um desses como tipo subjacente , len pode ser aplicado a ele.

@pciet Sobre o seu exemplo com Comparable constraint/interface. Observe que, se você definir (a variante de interface):

type Comparable interface { Equal(Comparable) bool }
type Set []Comparable

Então você pode colocar qualquer coisa que implemente Comparable em Set . Compare isso com:

constraint [T] Comparable { Equal(t T) bool }
type [T Comparable[T]] Set []T
...
type FooSet Set[Foo] // Where Foo satisfies constraint Comparable

onde você só pode colocar valores do tipo Foo em FooSet . Essa é a segurança do tipo mais forte.

@urandom Novamente, não sou fã de:

type MyConstraint constraint {....}

pois não acredito que uma restrição seja um tipo. Além disso, eu definitivamente não permitiria:

var myVar MyConstraint

o que não faz sentido para mim. Outra indicação de que as restrições não são tipos.

@urandom Em bikeshedding: acredito que as restrições devem ser declaradas apenas ao lado dos parâmetros de tipo. Considere uma função comum, definida assim:

func MyFunc(i) {
     if (i>0) fmt.Println("It's positive")
} with i being an integer

Você não pode ler isso da esquerda para a direita. Em vez disso, você primeiro leria func MyFunc(i) para determinar que é uma definição de função. Então você teria que pular para o final para descobrir o que é i , e então voltar para o corpo da função. Não é o ideal, OMI. E não vejo como as definições genéricas devam ser diferentes.
Mas, obviamente, essa discussão é ortogonal àquela sobre se Go deve ter restrições ou genéricos.

@surlykke
Eu estou bem com isso não sendo um tipo. O mais importante é que eles tenham um nome para que possam ser referidos por vários tipos.

Para funções, se seguirmos a sintaxe de ferrugem, seria:

func MyFunc[I](i I) int64
     where I is being an integer {
   return 42
}

Portanto, ele não ocultará coisas como o nome da função ou seus parâmetros, e você não precisaria ir até o final do corpo da função para ver quais são as restrições nos tipos genéricos

@surlykke para a posteridade, você poderia localizar onde sua proposta poderia ser adicionada:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

É um ótimo lugar para "compilar" todas as propostas.

Outra questão que coloco a todos vocês é como lidar com a especialização de diferentes instanciações de um tipo genérico. Na proposta de parâmetros de tipo , a maneira de fazer isso é gerar a mesma função de modelo para cada tipo instanciado, substituindo o parâmetro de tipo pelo nome do tipo. Para ter uma funcionalidade separada para diferentes tipos, execute uma troca de tipo no parâmetro de tipo.

É seguro supor que, quando o compilador vê uma chave de tipo em um parâmetro de tipo, é permitido gerar uma implementação separada para cada asserção? Ou isso está muito envolvido em uma otimização, já que parâmetros de tipo aninhados nas estruturas declaradas podem criar um aspecto paramétrico para a geração de código?

Na proposta de funções de tempo de compilação , como sabemos que essas declarações são geradas em tempo de compilação, uma troca de tipo não representa nenhum custo de tempo de execução.

Um cenário prático: Se considerarmos um caso do pacote math/bits , executar uma declaração de tipo para chamar OnesCount para cada uintXX superaria o ponto de ter uma biblioteca de manipulação de bits eficiente. Se, no entanto, as asserções de tipo forem transformadas nas seguintes

func OnesCount(x T) int {
    switch x.(type) {
    case uint:
        // separate uint functionality...
    case uint8:
        // separate uint8 functionality...
    case uint16:
        // separate uint16 functionality...
    case uint32:
        // separate uint32 functionality...
    case uint64:
        // separate uint64 functionality...
    }
}

Uma chamada para

var x uint8 = 255
bits.OnesCount(x)

chamaria a seguinte função gerada (o nome não é importante aqui):

func $OnesCount_uint8(x uint8) {
    // separate uint8 functionality...
}

@jba Essa é uma proposta interessante, mas para mim destaca principalmente o fato de que a definição da função paramétrica em si geralmente é suficiente para definir suas restrições.

Se você for usar “operadores usados ​​em uma função” como as restrições, então qual a vantagem de escrever uma segunda função contendo um subconjunto dos operadores usados ​​na primeira?

@bcmills Um deles é uma especificação e o outro é a implementação. É a mesma vantagem da digitação estática: você pode detectar erros mais cedo.

Se a implementação for a especificação, à la C++ templates, então qualquer mudança na implementação potencialmente quebra os dependentes. Isso pode não ser descoberto até muito mais tarde, quando os dependentes recompilarem e os descobridores não tiverem contexto para entender a mensagem de erro. Com a especificação no mesmo pacote, você pode detectar a quebra localmente.

@mandolyte Não tenho certeza de onde adicioná-lo - talvez um parágrafo em 'Abordagens genéricas' chamado 'Genéricos com restrições'?
O documento não parece conter muito sobre a restrição de parâmetros de tipo, portanto, se você adicionasse um parágrafo onde minha proposta seria mencionada, outras abordagens para restrições também poderiam ser listadas lá.

@surlykke a abordagem geral do documento é fazer uma mudança no que parece certo e tentarei aceitar, incorporar e organizar isso com o restante do documento. Eu adicionei uma seção aqui . Sinta-se livre para adicionar coisas que eu perdi.

@egonelbre Isso é muito bom. Obrigado!

@jba
Eu gosto da sua proposta, mas acho que é muito pesada para golang. Isso me lembra muitos modelos em c++. O principal problema que eu acho é que você pode escrever um código realmente complexo com ele.
Decidir se duas instâncias de interface genéricas se sobrepõem porque o conjunto restrito de tipos se sobrepõe seria uma tarefa difícil, causando tempos de compilação mais lentos. O mesmo para geração de código.

Eu acho que as restrições propostas são mais leves para ir. Pelo que ouvi é que as restrições aka typeclasses podem ser implementadas ortogonalmente ao sistema de tipos de uma linguagem.

Eu tenho que concordar fortemente que não devemos ir com restrições implícitas do corpo da função. Eles são amplamente considerados uma das falhas mais significativas dos modelos C++:

• As restrições não são facilmente visíveis. Embora o godoc teoricamente possa enumerar todas as restrições na documentação, elas não são visíveis no código-fonte, exceto implicitamente.
• Por isso, é possível incluir acidentalmente uma restrição adicional que só fica visível quando você tenta usar a função de uma forma não esperada. Ao exigir a especificação explícita das restrições, o programador deve saber exatamente quais restrições estão introduzindo.
• Ele toma a decisão sobre quais tipos de restrições são permitidos muito mais ad hoc. Por exemplo, posso definir a seguinte função? Quais são as restrições reais em T, U e V aqui? Se exigirmos que o programador especifique explicitamente as restrições, então seremos conservadores no tipo de restrições que permitimos (nos deixando expandir isso lenta e deliberadamente). Se tentarmos ser conservadores de qualquer maneira, como damos uma mensagem de erro para uma função como essa? "Erro: não é possível atribuir uv() a T porque impõe uma restrição ilegal"?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

• Chamar funções genéricas em outras funções genéricas piora as situações acima, pois agora você precisa examinar todas as restrições dos destinatários para entender as restrições da função que está escrevendo ou lendo.
• A depuração pode ser muito difícil, porque as mensagens de erro não devem fornecer informações suficientes para encontrar a origem da restrição ou devem vazar detalhes internos da função. Por exemplo, se F tiver algum requisito em um tipo T e o autor de F estiver tentando descobrir de onde veio esse requisito, eles gostariam que o compilador alertá-los para exatamente qual instrução dá origem à restrição (especialmente se vier de um callee genérico). Mas um usuário de F não quer essa informação e, de fato, se ela estiver incluída nas mensagens de erro, estaremos vazando detalhes de implementação de F nas mensagens de erro de seus usuários, o que são uma experiência de usuário terrível.

@alercah

Por exemplo, posso definir a seguinte função?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

Não. u.v(V) é um erro de sintaxe porque V é um tipo e a variável t não é usada.

No entanto, você pode definir esta função, que pode ser a que você pretendia:

func[T, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

Quais são as restrições reais em T, U e V aqui?

• O tipo V é irrestrito.
• O tipo U deve ter um método v que aceite um único parâmetro ou varargs de algum tipo atribuível de V , porque u.v é invocado com um único argumento do tipo V .
  
  
  
  • U.v poderia ser um campo do tipo função, mas sem dúvida isso deveria implicar um método; veja #23796.
  
  
• O tipo retornado por U.v deve ser numérico, pois a constante 1 é adicionada a ele.
• O tipo de retorno U.v deve ser atribuído a T , porque u.v(…) + 1 é atribuído a uma variável do tipo T .
• O tipo T deve ser numérico, porque o tipo de retorno de U.v é numérico e atribuível a T .

(Um aparte: você poderia argumentar que U e V deveriam ter a restrição “copiável” porque os argumentos desses tipos são passados ​​por valor, mas o sistema de tipos não genéricos existente não impõe essa restrição também. Isso é assunto para uma proposta separada.)

Se exigirmos que o programador especifique explicitamente as restrições, então seremos conservadores no tipo de restrições que permitimos (nos deixando expandir isso lenta e deliberadamente).

Sim, isso é verdade: mas omitir uma restrição seria um defeito sério, independentemente de essas restrições serem implícitas ou não. IMO, o papel mais importante das restrições é resolver a ambiguidade. Por exemplo, nas restrições acima, o compilador deve estar preparado para instanciar u.v como um método de argumento único ou variável.

A ambiguidade mais interessante ocorre para literais, onde precisamos desambiguar entre tipos struct e tipos compostos:

func[T] Foo() (t T) {
    x := 42;
    t = T{x: "some string"}  // Is x an index, or a field name?
    _ = x
}

Se tentarmos ser conservadores de qualquer maneira, como damos uma mensagem de erro para uma função como essa? "Erro: não é possível atribuir uv() a T porque impõe uma restrição ilegal"?

Não tenho certeza do que você está perguntando, pois não vejo restrições conflitantes para este exemplo. O que você quer dizer com “restrição ilegal”?

A depuração pode ser muito difícil, porque as mensagens de erro não devem fornecer informações suficientes para encontrar a origem da restrição ou devem vazar detalhes internos da função.

Nem todas as restrições relevantes podem ser expressas pelo sistema de tipos (consulte também https://github.com/golang/go/issues/22876#issuecomment-347035323). Algumas restrições são impostas por pânicos em tempo de execução; alguns são reforçados pelo detector de corrida; as restrições mais perigosas são meramente documentadas e não são detectadas.

Todos esses “detalhes internos vazam” até certo ponto. (Veja também https://xkcd.com/1172/.)

Por exemplo, se […] o autor de F está tentando descobrir de onde veio esse requisito, eles gostariam que o compilador os alertasse sobre exatamente qual declaração dá origem à restrição (especialmente se vier de um callee genérico). Mas um usuário de F não quer essa informação[.]

Pode ser? É assim que os autores de API usam anotações de tipo em linguagens inferidas por tipo, como Haskell e ML, mas também leva a um buraco de coelho de tipos profundamente paramétricos (“ordem superior”) em geral.

Por exemplo, suponha que você tenha esta função:

func [F, Arg, Result] InvokeAsync(f F, x Arg) (<-chan Result) {
    c := make(chan result, 1)
    go func() { c <- f(x) }()
    return c
}

Como você expressa as restrições explícitas no tipo Arg ? Eles dependem da instanciação específica de F . Esse tipo de dependência parece estar faltando em muitas das propostas recentes de restrições.

Não. uv(V) é um erro de sintaxe porque V é um tipo e a variável t não é usada.

No entanto, você pode definir esta função, que pode ser a que você pretendia:

Sim, essa era a intenção, minhas desculpas.

O tipo T deve ser numérico, porque o tipo de retorno de U.v é numérico e atribuível a T .

Devemos realmente considerar isso uma restrição? É dedutível das outras restrições, mas é mais ou menos útil chamar isso de restrição distinta? As restrições implícitas fazem essa pergunta de uma maneira que as restrições explícitas não fazem.

Sim, isso é verdade: mas omitir uma restrição seria um defeito sério, independentemente de essas restrições serem implícitas ou não. IMO, o papel mais importante das restrições é resolver a ambiguidade. Por exemplo, nas restrições acima, o compilador deve estar preparado para instanciar uv como um método de argumento único ou variável.

Eu quis dizer "restrições que permitimos", como na linguagem. Com restrições explícitas, é muito mais fácil decidir que tipo de restrições estamos dispostos a permitir que os usuários escrevam, em vez de apenas dizer que a restrição é "o que quer que faça as coisas compilarem". Por exemplo, meu exemplo Foo acima envolve um tipo adicional implícito separado de T , U ou V , já que devemos considerar o tipo de retorno de u.v . Este tipo não é explicitamente referido de forma alguma na declaração de f ; as propriedades que ele deve ter são completamente implícitas. Da mesma forma, estamos dispostos a permitir tipos de classificação mais alta ( forall )? Não consigo criar um exemplo de cabeça, mas também não consigo me convencer de que você não pode escrever implicitamente um limite de tipo de classificação mais alta.

Outro exemplo é se devemos permitir que uma função aproveite a sintaxe sobrecarregada. Se uma função implicitamente restrita fizer for i := range t para algum t do tipo genérico T , a sintaxe funcionará se T for qualquer array, slice, channel, ou mapa. Mas a semântica é bem diferente, especialmente se T for um tipo de canal. Por exemplo, se t == nil (o que pode acontecer desde que T seja uma matriz), a iteração não faz nada, pois não há elementos em uma fatia ou mapa nulo, ou bloqueia para sempre já que é isso que os canais nil fazem. Esta é uma grande arma esperando para acontecer. Da mesma forma está fazendo m[i] = ... ; se eu pretendo que m seja um mapa, precisarei me proteger contra ele ser realmente uma fatia, pois o código pode entrar em pânico em uma atribuição fora do alcance, caso contrário.

Na verdade, acho que isso se presta a outro argumento contra restrições implícitas: os autores de API podem escrever instruções artificiais apenas para adicionar restrições. Por exemplo for _, _ := range t { break } previne um canal enquanto ainda permite mapas, slices e arrays; x = append(x) força x a ter o tipo de fatia. var _ = make(T, 0) permite fatias, mapas e canais, mas não matrizes. Haverá um livro de receitas de como adicionar restrições implicitamente para que alguém não possa chamar sua função com um tipo para o qual você não escreveu o código correto. Não consigo nem pensar em uma maneira de escrever código que compile apenas para tipos de mapa, a menos que eu também conheça o tipo de chave. E não acho que isso seja hipotético; mapas e fatias se comportam de maneira bastante diferente para a maioria das aplicações

Não tenho certeza do que você está perguntando, pois não vejo restrições conflitantes para este exemplo. O que você quer dizer com “restrição ilegal”?

Refiro-me a uma restrição que não é permitida pela linguagem, como se a linguagem decidir não permitir restrições de classificação mais alta.

Nem toda restrição relevante pode ser expressa pelo sistema de tipos (veja também #22876 (comentário)). Algumas restrições são impostas por pânicos em tempo de execução; alguns são reforçados pelo detector de corrida; as restrições mais perigosas são meramente documentadas e não são detectadas.

Todos esses “detalhes internos vazam” até certo ponto. (Veja também https://xkcd.com/1172/.)

Eu realmente não vejo como #22876 entra nisso; que está tentando usar o sistema de tipos para expressar um tipo diferente de restrição. Sempre será verdade que não podemos expressar algumas restrições em valores, ou em programas, mesmo com um sistema de tipos de complexidade arbitrária. Mas estamos falando apenas sobre restrições de tipos aqui. O compilador precisa ser capaz de responder à pergunta "Posso instanciar este genérico com o tipo T ?" o que significa que ele deve entender as restrições, sejam elas implícitas ou explícitas. (Observe que algumas linguagens, como C++ e Rust, não podem decidir essa questão em geral porque ela pode depender de computação arbitrária e, portanto, se volta para o Problema da Parada, mas elas ainda expressam as restrições que precisam ser satisfeitas.)

O que quero dizer é mais como "qual mensagem de erro o exemplo a seguir deve fornecer?"

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

Podemos dizer Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Essa mensagem de erro é útil para um usuário de IndirectlyConstrained , porque define claramente a restrição que está faltando. Mas não fornece nenhuma informação para alguém tentando depurar por que IndirectlyConstrained tem essa restrição, o que é um grande problema de usabilidade se for uma função grande. Poderíamos adicionar Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , mas agora estamos vazando detalhes da implementação de IndirectlyConstrained . Além disso, não explicamos por que IndirectlyConstrained tem a restrição, então adicionamos outro Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M ? E se a restrição implícita vier de algum chamado quatro níveis abaixo da pilha de chamadas?

Além disso, como formatamos essas mensagens de erro para tipos que não estão explicitamente listados como parâmetros? Por exemplo, se no exemplo acima, IndirectlyConstrained chama DirectlyConstrained(t.U()) . Como nos referimos ao tipo? Neste caso poderíamos dizer the type of t.U() , mas o valor não será necessariamente o resultado de uma única expressão; ele pode ser construído sobre várias instruções. Então precisaríamos sintetizar uma expressão com os tipos corretos para colocar na mensagem de erro, uma que nunca aparece no código, ou precisaríamos encontrar outra maneira de se referir a ela que seria menos clara para o pobre chamador que violou a restrição.

Como você expressa as restrições explícitas no tipo Arg? Eles dependem da instanciação específica de F. Esse tipo de dependência parece estar faltando em muitas das propostas recentes de restrições.

Solte F e faça com que o tipo de f seja func (Arg) Result . Sim, ele ignora funções variádicas, mas o resto do Go também. Uma proposta para fazer varargs funcs atribuíveis a assinaturas compatíveis poderia ser feita separadamente.

Para casos em que realmente exigimos limites de tipo de ordem superior, pode ou não fazer sentido incluí-los em genéricos v1. Restrições explícitas nos forçam a decidir explicitamente se queremos dar suporte a tipos de ordem superior e como. A falta de consideração até agora é um sintoma, eu acho, do fato de que Go atualmente não tem como se referir a propriedades de tipos internos. É uma questão geral aberta de como qualquer sistema genérico permitirá funções genéricas sobre todos os tipos numéricos, ou todos os tipos inteiros, e a maioria das propostas não se concentrou muito nisso.

Por favor, avalie minha implementação de genéricos em seu próximo projeto
http://go-li.github.io/

Podemos dizer Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Esta mensagem de erro […] não fornece nenhuma informação para alguém tentando depurar porque IndirectlyConstrained tem essa restrição, que é um grande problema de usabilidade se for uma função grande.

Eu quero apontar uma grande suposição que você está fazendo aqui: que a mensagem de erro de go build é a ferramenta _only_ que o programador tem disponível para diagnosticar o problema.

Para usar uma analogia: se você encontrar um error em tempo de execução, você tem várias opções para depuração. O erro em si contém apenas uma mensagem simples, que pode ou não ser adequada para descrever o erro. Mas não é a única informação que você tem disponível: por exemplo, você também tem quaisquer declarações de log que o programa emitiu, e se for um bug muito complicado você pode carregá-lo em um depurador interativo.

Ou seja, a depuração em tempo de execução é um processo interativo. Então, por que devemos assumir depuração não interativa para erros de tempo de compilação? Como uma alternativa, poderíamos ensinar a ferramenta guru sobre restrições de tipo. Então, a saída do compilador seria algo como:

somefile.go:123: Argument `4` to DirectlyConstrained has type `int`,
    but DirectlyConstrained requires a type `T` with method `DoSomething()`.
    (For more detail, run `guru contraints path/to/somefile.go:#1033`.)

Isso fornece ao usuário do pacote genérico as informações necessárias para depurar o site de chamada imediata, mas _também_ fornece uma trilha para o mantenedor do pacote (e, mais importante, seu ambiente de edição!) para investigar mais.

Poderíamos adicionar Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , mas agora estamos vazando detalhes da implementação de IndirectlyConstrained .

Sim, isso é o que quero dizer sobre informações vazando de qualquer maneira. Você já pode usar guru describe para espiar dentro de uma implementação. Você pode espiar dentro de um programa em execução usando um depurador, e não apenas procurar na pilha, mas também descer para funções de baixo nível arbitrariamente.

Concordo absolutamente que devemos ocultar informações provavelmente irrelevantes _por padrão_, mas isso não significa que devemos escondê-las em absoluto.

Se uma função restrita implicitamente faz i := range t para algum t do tipo genérico T , a sintaxe funciona se T for qualquer array, slice, channel , ou mapa. Mas a semântica é bem diferente, especialmente se T for um tipo de canal.

Acho que esse é o argumento mais convincente para restrições de tipo, mas isso não exige que as restrições explícitas sejam tão detalhadas quanto o que algumas pessoas estão propondo. Para desambiguar os sites de chamada, parece suficiente restringir os parâmetros de tipo por algo mais próximo de reflect.Kind . Não precisamos descrever operações que já estão claras no código; em vez disso, só precisamos dizer coisas como “ T é um tipo de fatia”. Isso leva a um conjunto muito mais simples de restrições:

• um tipo sujeito a operações de índice precisa ser rotulado como linear ou associativo,
• um tipo sujeito a operações range precisa ser rotulado como nil-empty ou nil-blocking,
• um tipo com literais precisa ser rotulado como tendo campos ou índices, e
• (talvez) um tipo com operações numéricas precise ser rotulado como ponto fixo ou flutuante.

Isso leva a uma linguagem de restrição muito mais estreita, talvez algo como:

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

com exemplos como:

func[T:integer, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

func [S:sliceable, T] append(s S, x ...T) S {
    dst := s
    if cap(s) - len(s) < len(x) {
        dst = make(S, len(s), nextSizeClass(cap(s)))
        copy(dst, s)
    }
    copy(dst[len(s):cap(s)], x)
    return dst[:len(s)+len(x)]
}

Sinto que demos um grande passo em direção ao genérico personalizado ao introduzir o alias de tipo.
O alias de tipo possibilita supertipos (tipo de tipos).
Podemos tratar tipos como valores em using.

Para tornar as explicações mais simples, podemos adicionar um novo elemento de código, genre .
A relação entre gêneros e tipos é como a relação entre tipos e valores.
Em outras palavras, um gênero significa um tipo de tipos.

Cada tipo de tipo, exceto os tipos struct e interface e função, corresponde a um gênero pré-declarado.

• Bool
• Corda
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• Float32, Float64
• Complexo64, Complexo128
• Matriz, Fatia, Mapa, Canal, Ponteiro, UnsafePointer

Existem alguns outros gêneros pré-declarados, como Comaprable, Numérico, Interger, Float, Complex, Container, etc. Podemos usar Type ou * denota o gênero de todos os tipos.

Os nomes de todos os gêneros integrados começam com uma letra maiúscula.

Cada tipo de estrutura e interface e função corresponde a um gênero.

Também podemos declarar gêneros personalizados:

genre Addable = Numeric | String
genre Orderable = Interger | Float | String
genre Validator = func(int) bool // each parameter and result type must be a specified type.
genre HaveFieldsAndMethods = {
    width  int // we must use a specific type to define the fields.
    height int // we can't use a genre to define the fields.
    Load(v []byte) error // each parameter and result type must be a specified type.
    DoSomthing()
}
genre GenreFromStruct = aStructType // declare a genre from a struct type
genre GenreFromInterface = anInterfaceType // declare a genre from an interface type
genre GenreFromStructInterface = aStructType + anInterfaceType
genre ComparableStruct = HaveFieldsAndMethods & Comprable
genre UncomparableStruct = HaveFieldsAndMethods &^ Comprable

Para tornar a explicação a seguir consistente, é necessário um modificador de gênero.
O modificador de gênero é indicado por Const . Por exemplo:

• Const Integer é um gênero (diferente de Integer ) e sua instância deve ser um valor constante cujo tipo deve ser um inteiro. No entanto, o valor constante pode ser visto como um tipo especial.
• Const func(int) bool é um gênero (diferente de func(int) bool ) e sua instância deve ser um valor de função delcared. No entanto, a declaração da função pode ser vista como um tipo especial.

(A solução do modificador é um pouco complicada, talvez existam outras soluções de design melhores.)

Ok, vamos continuar.
Precisamos de outro conceito. Encontrar um bom nome para ele não é fácil,
Vamos chamá-lo crate .
Geralmente, a relação entre engradados e gêneros é como a relação entre funções e tipos.
Uma caixa pode receber tipos como parâmetros e tipos de retorno.

Uma declaração de grade (suponha que o código a seguir seja declarado no pacote lib ):

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

Usando a caixa acima.

import "lib"

// We can use AddFunc as a normal delcared function.
// Its genre is "Const func (a, b T) T"
type Rect, AddFunc, Array = lib.Example[float32, struct{x, y float32}, 100]

func demo() {
    var r Rect
    a, p = r.Area(), r.Perimeter()
    _ = AddFunc(a, p)
}

Minhas ideias absorvem muitas ideias de outras mostradas acima.
Eles não estão muito maduros agora.
Eu as coloco aqui só porque eu acho que elas são interessantes,
e eu não quero melhorá-lo mais.
Tantas células cerebrais foram mortas ao consertar os buracos nas ideias.
Espero que essas idéias possam trazer algumas inspirações para outros esquilos.

O que você chama de “gênero” é na verdade chamado de “tipo”, e é bem conhecido no
comunidade de programação funcional. O que você chama de engradado é um restrito
tipo de functor ML.

Em quarta-feira, 4 de abril de 2018, 12h41, dotaheor [email protected] escreveu:

Sinto que demos um grande passo em direção ao genérico personalizado ao introduzir
tipo alias.
O alias de tipo possibilita supertipos (tipo de tipos).
Podemos tratar tipos como valores em using.

Para tornar as explicações mais simples, podemos adicionar um novo elemento de código, gênero.
A relação entre gêneros e tipos é como a relação entre tipos
e valores.
Em outras palavras, um gênero significa um tipo de tipos.

Cada tipo de tipo, exceto tipos de estrutura e interface e função,
corresponde a um gênero pré-declarado.

• Bool
• Corda
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  & Float32, Float64
• Complexo64, Complexo128
• Matriz, Fatia, Mapa, Canal, Ponteiro, UnsafePointer

Existem alguns outros gêneros pré-declarados, como Comaprable, Numérico,
Interger, Float, Complex, Container, etc. Podemos usar Type ou * denota
o gênero de todos os tipos.

Os nomes de todos os gêneros integrados começam com uma letra maiúscula.

Cada tipo de estrutura e interface e função corresponde a um gênero.

Também podemos declarar gêneros personalizados:

gênero Adicável = Numérico | Corda
gênero Ordenável = Interger | Flutuar | Corda
gene Validator = func(int) bool // cada parâmetro e tipo de resultado deve ser um tipo especificado.
genero HaveFieldsAndMethods = {
largura int // devemos usar um tipo específico para definir os campos.
height int // não podemos usar um gênero para definir os campos.
Load(v []byte) error // cada parâmetro e tipo de resultado deve ser um tipo especificado.
Fazer Algo()
}
gênero GenreFromStruct = aStructType // declara um gênero de um tipo struct
gênero GenreFromInterface = anInterfaceType // declara um gênero de um tipo de interface
gênero GenreFromStructInterface = aStructType | um Tipo de Interface

Para tornar a explicação a seguir consistente, é necessário um modificador de gênero.
O modificador de gênero é denotado por Const. Por exemplo:

• Const Integer é um gênero e sua instância deve ser um valor constante
  qual tipo deve ser um número inteiro.
  No entanto, o valor constante pode ser visto como um tipo especial.
• Const func(int) bool é um gênero e sua instância deve ser um delcared
  valor da função.
  No entanto, a declaração da função pode ser vista como um tipo especial.

(A solução do modificador é um pouco complicada, talvez haja outro design melhor
soluções.)

Ok, vamos continuar.
Precisamos de outro conceito. Encontrar um bom nome para ele não é fácil,
Vamos chamá-lo de caixa.
Geralmente, a relação entre caixas e gêneros é como a relação
entre funções e tipos.
Uma caixa pode receber tipos como parâmetros e tipos de retorno.

Uma declaração de grade (suponha que o código a seguir seja declarado em lib
pacote):

Exemplo de caixa [T Flutuante, S {largura, altura T}, N Const Integer] [*, *, *] {
digite MyArray [N]T

func Adicionar(a, b T) T {
retornar a+b
}

// Um ​​gênero de escopo de caixa. Só pode ser usado na caixa.

// M é um tipo de gênero G
tipo M estrutura {
xT
y S
}

func (m *M) Área() T {
m.DoSomthing()
return mywidth * myheight
}

func (m *M) Perímetro() T {
return 2 * Add(mywidth, myheight)
}

exportar M, Adicionar, MeuArray
}

Usando a caixa acima.

importar "lib"

// Podemos usar AddFunc como uma função delcared normal.
digite Rect, AddFunc, Array = lib.Example(float32, struct{x, y float32})

demonstração funcional() {
var r Rect
a, p = r.Área(), r.Perímetro()
_ = AdicionarFunc(a, p)
}

Minhas ideias absorvem muitas ideias de outras mostradas acima.
Eles não estão muito maduros agora.
Eu as coloco aqui só porque eu acho que elas são interessantes,
e eu não quero melhorá-lo mais.
Tantas células cerebrais foram mortas ao consertar os buracos nas ideias.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-378665695 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
.

Eu sinto que há algumas diferenças entre Kind e Genre.

A propósito, se um engradado retornar apenas um tipo, podemos usar sua chamada como um tipo diretamente.

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

use-o:

import "lib"

var l lib.List[int]

Haveria algumas regras de "dedução de gênero", assim como "dedução de tipo" no sistema atual.

@dotaheor , @DemiMarie está correto. Seu conceito de “gênero” soa exatamente como o “tipo” da teoria dos tipos. (Sua proposta exige uma regra de subclassificação, mas isso não é incomum.)

A palavra-chave genre em sua proposta define novos tipos como supertipos de tipos existentes. A palavra-chave crate define objetos com “assinaturas de engradados”, que são um tipo que não é um subtipo de Type .

Como um sistema formal, sua proposta parece ser algo como:

Caixa ::= χ | ⋯
Digite ::= τ | χ | int | bool | ⋯ | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

CrateSig ::= [κ₁, …] ⇒ [κₙ, …]
Tipo ::= κ | exactly τ | kindOf κ | Map | Chan | ⋯ | Const κ | Type | CrateSig

Para abusar de alguma notação da teoria dos tipos:

• Leia “⊢” como “implica”.
• Leia “ k1 ⊑ k2 ” como “ k1 é um subtipo de k2 ”.
• Leia “:” como “é do tipo”.

Então as regras são algo como:

⊢ τ : exactly τ
⊢ exactly τ ⊑ kindOf exactly τ
⊢ kindOf exactly τ ⊑ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ : κ₂

τ₁ : Type ∧ τ₂ : Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
⊢ Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
(E assim por diante, para todos os tipos integrados)

As definições de tipo conferem tipos, e os tipos subjacentes são reduzidos aos tipos de tipos internos:

type τ₁ τ₂ ∧ τ₂ : κ ⊢ τ₁ : kindOf κ

⊢ kindOf kindOf κ ⊑ kindOf κ
⊢ kindOf Map ⊑ Map
[…]

genre define novos relacionamentos de subtipo:
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

(Você pode definir Numeric e similares em termos de | .)

genre κ = κ₁ & κ₂ ∧ ( κ₃ ⊑ κ₁ ) ∧ ( κ₃ ⊑ κ₂ ) ⊢ κ₃ ⊑ κ

A regra de expansão da caixa é semelhante:
type τₙ, … = χ[τ₁, …] ∧ ( χ : [κ₁, …] ⇒ [κₙ, …] ) ∧ ( τ₁ : κ₁ ) ∧ ⋯ ⊢ τₙ : κₙ

Isso tudo é apenas falando sobre os tipos, é claro. Se você quiser transformá-lo em um sistema de tipos, também precisará de regras de tipo. 🙂

Então, o que você está descrevendo é uma forma muito bem compreendida de parametricidade. Isso é bom, pois é bem compreendido, mas decepcionante, pois não ajuda a resolver os problemas únicos que o Go apresenta.

Os problemas realmente interessantes e complicados que o Go apresenta são principalmente em torno da inspeção de tipo dinâmico. Como os parâmetros de tipo devem interagir com as declarações de tipo e reflexão?

(Por exemplo, deveria ser possível definir interfaces com métodos de tipos paramétricos? Em caso afirmativo, o que acontece se você digitar um valor dessa interface com um novo parâmetro em tempo de execução?)

Em uma nota relacionada, houve uma discussão sobre como tornar o código genérico sobre tipos internos e definidos pelo usuário? Como fazer código que pode lidar com bigints e inteiros primitivos?

Em uma nota relacionada, houve uma discussão sobre como tornar o código genérico sobre tipos internos e definidos pelo usuário? Como fazer código que pode lidar com bigints e inteiros primitivos?

Mecanismos baseados em classe de tipo, como em Genus e Familia, podem fazer isso com eficiência. Consulte nosso artigo PLDI 2015 para obter detalhes.

@DemiMarie
Eu acho que "gênero" == "conjunto de traços".

[editar]
Talvez traits seja uma palavra-chave melhor.
Podemos ver que cada tipo também é um conjunto de características.

A maioria das características são definidas para um único tipo apenas.
Mas um traço mais complexo pode definir uma relação entre dois tipos.

[editar 2]
supondo que existam dois conjuntos de características A e B, podemos fazer as seguintes operações:

A + B: union set
A - B: difference set
A & B: intersection set

O conjunto de características de um tipo de argumento deve ser um superconjunto do gênero de parâmetro correspondente (um conjunto de características).
O conjunto de características de um tipo de resultado deve ser um subconjunto do gênero de resultado correspondente (um conjunto de características).

(NA MINHA HUMILDE OPINIÃO)

Ainda acho que religar Type Aliases é o caminho a seguir, para adicionar genéricos ao Go. Não precisa de uma grande mudança na linguagem. Pacotes que são generalizados desta forma, ainda podem ser usados ​​no Go 1.x. E não há necessidade de adicionar restrições porque é possível fazer isso definindo o tipo padrão para o alias de tipo, para algo que já atende a essas restrições. E o aspecto mais importante da religação de aliases de tipo é que os tipos compostos internos (fatias, mapas e canais) não precisam ser alterados e generalizados.

@dc0d

Como os aliases de tipo devem substituir os genéricos?

@sighoya Rebinding Type Aliases pode substituir genéricos (não apenas aliases de tipo). Vamos supor que um pacote introduz alguns aliases de tipo de nível de pacote como:

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

Se Type Alias ​​Rebinding (e recursos do compilador) for fornecido, é possível usar este pacote, para criar listas vinculadas para diferentes tipos concretos, em vez de interface vazia:

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

Se usarmos alias como tal, a maneira a seguir é mais limpa.

// pkg.go
package pkg

type ListNode struct {
    prev, next *ListNode
    element    ?Element
}

func Add(x, y ?T) ?T {
    return x+y
}



// main.go
package main

import "pkg"

type intList = pkg.ListNode[Element=int]
func stringAdd = pkg.Add[T=string]

func main() {
}

@dc0d e como exatamente isso seria implementado? O código é bom, mas não diz nada sobre como ele realmente funciona por dentro. E, olhando para a história das propostas de genéricos, para Go é muito importante, não apenas como parece e se sente.

@dotaheor Isso é incompatível com o Go 1.x.

@creker Implementei uma ferramenta (chamada goreuse ) que usa essa técnica para gerar código e nasceu como um conceito para Type Alias ​​Rebinding.

Ele pode ser encontrado aqui . Há um vídeo de 15 minutos que explica a ferramenta.

@dc0d para que funcione como modelos C++ gerando implementações especializadas. Eu não acho que seria aceito como equipe Go (e, francamente, eu e muitas outras pessoas aqui) parece ser contra qualquer coisa semelhante aos modelos C++. Aumenta os binários, retarda a compilação, possivelmente não seria capaz de produzir erros significativos. E, além disso, não é compatível com pacotes somente binários que o Go suporta. É por isso que o C++ optou por escrever modelos em arquivos de cabeçalho.

@creker

por isso funciona como modelos C++ gerando implementações especializadas para cada tipo usado.

Eu não sei (Faz cerca de 16 anos desde que escrevi qualquer C++). Mas pela sua explicação parece que sim. No entanto, não tenho certeza se ou como eles são os mesmos.

Eu não acho que seria aceito como equipe Go (e, francamente, eu e muitas outras pessoas aqui) parece ser contra qualquer coisa semelhante aos modelos C++.

Claro que todos aqui têm boas razões para suas preferências com base em suas prioridades. O primeiro da minha lista é a compatibilidade com o Go 1.x.

Aumenta binários,

Pode.

retarda a compilação,

Eu duvido muito disso (como pode ser experimentado com goreuse ).

E, além disso, não é compatível com pacotes somente binários que o Go suporta.

Não tenho certeza. Outras formas de implementação de genéricos suportam isso?

possivelmente não seria capaz de produzir erros significativos.

Isso pode ser um pouco problemático. Ainda assim, isso acontece em tempo de compilação e pode ser compensado, empregando algumas ferramentas, em grande parte. Além disso, se o alias de tipo que atua como parâmetro de tipo para o pacote for uma interface, pode simplesmente ser verificado se é atribuível a partir do tipo fornecido concreto. Embora o problema para tipos primitivos como int e string e structs permaneça.

@dc0d

Eu penso um pouco sobre isso.
Além de ser estabelecido internamente nas interfaces, o 'T' no seu exemplo

type T=interface{}

é tratado como uma variável de tipo mutável, mas deve ser um alias para um tipo específico, ou seja, const referência a um tipo.
O que você quer é o tipo T, mas isso implicaria na introdução de genéricos.

@sighoya Não tenho certeza se entendi o que você disse.

É estabelecido internamente em interfaces

Não é verdade. Conforme descrito no meu comentário original, é possível usar tipos específicos que atendem a uma restrição. Por exemplo, o alias de tipo de parâmetro de tipo pode ser declarado como:

type T = int

E apenas os tipos que possuem o operador + (ou - ou * ; depende se esse operador é usado no corpo do pacote) podem ser usados ​​como valor de tipo que fica nesse parâmetro de tipo.

Portanto, não são apenas as interfaces que podem ser usadas como espaços reservados para parâmetros de tipo.

mas isso implicaria a introdução de genéricos.

Esta _é_ uma forma de introduzir/implementar genéricos na própria linguagem Go.

@dc0d

Para fornecer polimorfismo, você usará a interface{}, pois isso permite definir T para qualquer tipo posteriormente.

Definir 'tipo T=Int' não ganharia muito.

Se você disser que 'tipo T' é não declarado/indefinido primeiro, o que pode ser definido mais tarde, então você tem algo como genéricos.

O problema com isso é que 'T' mantém o módulo/pacote amplo e não é local para nenhuma função ou estrutura (tudo bem, talvez uma declaração de tipo aninhado em uma estrutura que pode ser acessada de fora).

Por que não escrever em vez disso?:

fun<type T>(t T)

ou

fun[type T](t T)

Além disso, precisamos de algum mecanismo de inferência de tipos para deduzir os tipos corretos ao chamar uma função genérica ou struct sem especialização de parâmetro de tipo em primeiro lugar.

@dc0d escreveu

E apenas os tipos que têm o operador + (ou - ou *; depende se esse operador é usado no corpo do pacote) podem ser usados ​​como um valor de tipo que fica nesse parâmetro de tipo.

Você pode elaborar mais sobre isso?

@sighoya

Para fornecer polimorfismo, você usará a interface{}, pois isso permite definir T para qualquer tipo posteriormente.

O polimorfismo não é alcançado por ter tipos compatíveis, ao religar aliases de tipo. A única restrição real é o corpo do pacote genérico. Devem ser compatíveis mecanicamente.

Você pode elaborar mais sobre isso?

Por exemplo, se um alias de tipo de parâmetro de tipo de nível de pacote for definido como:

package genericadd

type T = int

func Add(a, b T) T { return a + b }

Então praticamente todos os tipos numéricos podem ser atribuídos a T , como:

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

No entanto, não tenho certeza se ou como eles são os mesmos.

Eles são os mesmos no sentido de que funcionam de maneira praticamente idêntica pelo que vejo. Para cada compilador de instanciação de modelo de classe geraria uma implementação exclusiva se for a primeira vez que ele vê o uso da combinação específica de modelo de classe e sua lista de parâmetros. Isso aumenta o tamanho do binário, pois agora você tem várias implementações do mesmo modelo de classe. Retarda a compilação, pois o compilador agora precisaria gerar essas implementações e fazer todos os tipos de verificações. No caso de C++, o aumento no tempo de compilação pode ser enorme. Seus exemplos de brinquedos são rápidos, mas os de C++ também.

Não tenho certeza. Outras formas de implementação de genéricos suportam isso?

Outras linguagens não têm problema com isso. Em particular, C# é o mais familiar para mim. Mas ele usa geração de código em tempo de execução que a equipe Go descarta completamente. Java também funciona, mas sua implementação não é a melhor, para dizer o mínimo. Algumas das propostas do ianlancetaylor podem lidar com pacotes somente binários pelo que eu entendo.

A única coisa que não entendo é se os pacotes somente binários devem ser suportados. Não os vejo mencionados explicitamente nas propostas. Eu realmente não me importo com eles, mas ainda assim, é um recurso de linguagem.

Apenas para testar meu entendimento... considere este repositório de algoritmos de copiar/colar [ aqui ]. A menos que você queira usar "int", o código não pode ser usado diretamente. Deve ser copiado, colado e modificado para funcionar. E por modificações, quero dizer que cada instância de "int" deve ser alterada para qualquer tipo que você realmente precise.

A abordagem de alias de tipo faria as modificações uma vez para, digamos, T, e inseriria uma linha "tipo T int". Então o compilador precisaria religar T a outra coisa, digamos float64.

Portanto:
a) Eu diria que não haveria lentidão do compilador a menos que você realmente usasse essa técnica. Então é sua escolha.
b) Dado o novo material vgo, onde várias versões do mesmo código podem ser usadas... o que significa que deve haver algum método de esconder as fontes usadas, então certamente o compilador pode acompanhar se dois usos da mesma reencadernação são usados ​​e evitam a duplicação. Então eu acho que o excesso de código seria o mesmo que as técnicas atuais de copiar/colar.

Parece-me que entre os aliases de tipo e o vgo vindouro, as bases para essa abordagem aos genéricos estão quase completas ...

Existem alguns "desconhecidos" listados na proposta [ aqui ]. Então seria bom aprofundar um pouco mais.

@mandolyte você pode adicionar outro nível de indireção envolvendo tipos especializados em algum contêiner geral. Dessa forma, sua implementação pode permanecer a mesma. O compilador fará então toda a mágica. Acho que a proposta de parâmetros de tipo de Ian funciona dessa maneira.

Acho que o usuário precisa de uma escolha entre o apagamento de tipo e a monomorfização.
O último é o motivo pelo qual o Rust fornece abstrações de custo zero. Vá também.

Em segunda-feira, 9 de abril de 2018, 8h32 Antonenko Artem [email protected]
escreveu:

@mandolyte https://github.com/mandolyte você pode adicionar outro nível de
indireção envolvendo tipos especializados em algum contêiner geral. que
como sua implementação pode permanecer a mesma. O compilador fará então tudo
a mágica. Acho que a proposta de parâmetros de tipo de Ian funciona dessa maneira.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-379735199 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
.

Parece-me que há uma confusão compreensível nesta discussão sobre a troca entre modularidade e desempenho. A técnica C++ de redigitalização e instanciação de código genérico em cada tipo para o qual é usado é ruim para modularidade, ruim para distribuições binárias e, devido ao excesso de código, ruim para desempenho. A parte boa dessa abordagem é que ela especializa automaticamente o código gerado para os tipos que estão sendo usados, o que é particularmente útil quando os tipos usados ​​são tipos primitivos como int . Java traduz homogeneamente o código genérico, mas paga um preço pelo desempenho, principalmente quando o código usa o tipo T[] .

Felizmente, existem algumas maneiras de resolver isso sem a não modularidade do C++ e sem a geração de código em tempo de execução completo:

1. Gere instanciações especializadas para tipos primitivos. Isso pode ser feito automaticamente ou por diretiva do programador. Algum despacho é necessário para acessar a instanciação correta, mas pode ser dobrado no despacho já necessário por uma tradução homogênea. Isso funcionaria de maneira semelhante ao C#, mas não requer geração de código em tempo de execução completo; um pouco de suporte extra pode ser desejável no tempo de execução para configurar tabelas de despacho como carregamentos de código.
2. Use uma única implementação genérica na qual um array de T é realmente representado como um array de um tipo primitivo quando T é instanciado como um tipo primitivo. Essa abordagem, que usamos no PolyJ, Genus e Familia, melhora muito o desempenho em relação à abordagem Java, embora não seja tão rápida quanto uma implementação totalmente especializada.

@dc0d

O polimorfismo não é alcançado por ter tipos compatíveis, ao religar aliases de tipo. A única restrição real é o corpo do pacote genérico. Devem ser compatíveis mecanicamente.

Tipo aliases é o caminho errado, porque deve ser uma referência constante.
É melhor escrever 'T Type' diretamente e então você verá que usa de fato genéricos.

Por que você deseja usar uma variável de tipo global 'T' para todo o pacote/módulo, o tipo local vars em <> ou [] é mais modular.

@creker

Em particular, C# é o mais familiar para mim. Mas ele usa geração de código em tempo de execução que a equipe Go descarta completamente.

Para tipos de referência, mas não para tipos de valor.

@DemiMarie

Acho que o usuário precisa de uma escolha entre o apagamento de tipo e a monomorfização.
O último é o motivo pelo qual o Rust fornece abstrações de custo zero. Vá também.

"Type Erasure" é ambíguo, vou assumir que você quer dizer Type Parameter Erasure, o que o Java fornece que também não é bem verdade.
Java tem monomorfização, mas monomorfiza (semi) constantemente para o limite superior na restrição genérica que é principalmente Object.
Para fornecer métodos e campos de outros tipos, o limite superior é convertido internamente para o seu tipo apropriado, o que é bastante feio.
Se o projeto Valhalla for aceito, as coisas mudarão para tipos de valor, mas infelizmente não para tipos de referência.

Go não precisa seguir o Java Way porque:

"A compatibilidade binária para pacotes compilados não é garantida entre versões"

enquanto isso não é possível em Java.

Parece-me que há uma confusão compreensível nesta discussão sobre a troca entre modularidade e desempenho. A técnica C++ de redigitalização e instanciação de código genérico em cada tipo para o qual é usado é ruim para modularidade, ruim para distribuições binárias e, devido ao excesso de código, ruim para desempenho.

De que tipo de performance você está falando aqui?

Se por “ingestão de código” e “desempenho” você quer dizer “tamanho binário” e “pressão de cache de instrução”, então o problema é bastante simples de resolver: contanto que você não retenha informações de depuração para cada especialização, você pode recolher funções com os mesmos corpos na mesma função no momento do link (o chamado “modelo Borland” ). Isso trata trivialmente as especializações para tipos primitivos e tipos sem chamadas para métodos não triviais.

Se por “ingestão de código” e “desempenho” você quer dizer “tamanho de entrada do vinculador” e “tempo de vinculação”, o problema também é bastante direto, se você puder fazer certas suposições (razoáveis) sobre seu sistema de compilação. Em vez de emitir cada especialização em cada unidade de compilação, você pode emitir uma lista de especializações necessárias e fazer com que o sistema de compilação instancie cada especialização exclusiva exatamente uma vez antes da vinculação (o “modelo Cfront”). IIRC, este é um dos problemas que os módulos C++ tentam resolver.

Portanto, a menos que você queira dizer um terceiro tipo de “inchaço de código” e “desempenho” que eu perdi, parece que você está falando sobre um problema com a implementação, não com a especificação: _contanto que a implementação não retenha depuração em excesso informações,_ os problemas de desempenho são bastante simples de resolver.

O maior problema para Go é que, se não formos cuidadosos, torna-se possível usar asserções de tipo ou reflexão para produzir uma nova instância de um tipo parametrizado em tempo de execução, o que nenhuma quantidade de inteligência de implementação – a não ser um todo caro. – análise de programa – pode corrigir.

Isso é realmente uma falha de modularidade, mas não tem nada a ver com o excesso de código: em vez disso, vem do fato de que os tipos de funções (e métodos) Go não capturam um conjunto completo de restrições em seus argumentos.

@sighoya

Para tipos de referência, mas não para tipos de valor.

Pelo que li, C# JIT faz especialização em tempo de execução para cada tipo de valor e uma vez para todos os tipos de referência. Não há especialização em tempo de compilação (tempo IL). É por isso que a abordagem C# é completamente ignorada - a equipe Go não quer depender da geração de código em tempo de execução, pois limita as plataformas nas quais Go pode ser executado. Em particular, no iOS, você não tem permissão para gerar código em tempo de execução. Funciona e eu realmente fiz um pouco disso, mas a Apple não permite isso na AppStore.

Como você fez isso?

Em segunda-feira, 9 de abril de 2018, 15h41 Antonenko Artem [email protected]
escreveu:

@sighoya https://github.com/sighoya

Para tipos de referência, mas não para tipos de valor.

Pelo que li, C# JIT faz especialização em tempo de execução para cada valor
type e uma vez para todos os tipos de referência. Não há tempo de compilação
especialização. É por isso que a abordagem C# é completamente ignorada - Equipe Go
não quer depender da geração de código em tempo de execução, pois limita as plataformas Go
pode correr. Em particular, no iOS, você não tem permissão para gerar código
em tempo de execução. Funciona e eu fiz um pouco disso, mas a Apple não permite
na AppStore.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-379870005 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
.

@DemiMarie lançou meu antigo código de pesquisa apenas para ter certeza (essa pesquisa foi descartada por outros motivos). Mais uma vez, o depurador me enganou. Eu aloco uma página, escrevo algumas instruções para ela, protejo-a com PROT_EXEC e pulo para ela. No depurador funciona. Sem o aplicativo depurador é SIGKILLed com mensagem CODESIGN no log de falhas, conforme o esperado. Então, não funciona mesmo sem AppStore. Argumento ainda mais forte contra a geração de código em tempo de execução se o iOS for importante para o Go.

Primeiro, seria útil refletir mais uma vez sobre as 5 Regras de Programação de Rob Pike .

Segundo (IMHO):

Sobre compilação lenta e tamanho binário, quantos tipos genéricos são usados ​​em tipos comuns de aplicativos que estão sendo desenvolvidos usando Go (_n geralmente é pequeno_ da Regra 3)? A menos que o problema precise de um alto nível de cardinalidade em conceitos concretos (grande número de tipos), essa sobrecarga pode ser ignorada. Mesmo assim, eu argumentaria que algo está errado com essa abordagem. Ao implementar um sistema de e-commerce, ninguém define um tipo separado para cada tipo de produto e suas variações e talvez as possíveis customizações.

Verbosidade é uma boa forma de simplicidade e familiaridade (por exemplo, na sintaxe) que torna as coisas mais óbvias e limpas. Embora eu duvide que o excesso de código seja maior usando o Type Alias ​​Rebinding, gosto da sintaxe familiar do Go-ish e da verbosidade óbvia que a acompanha. Um dos objetivos do Go é ser fácil de ler (embora eu pessoalmente ache relativamente fácil e agradável escrever também).

Eu não entendo como isso pode prejudicar o desempenho porque em tempo de execução, apenas tipos limitados concretos estão sendo usados, os quais foram gerados em tempo de compilação. Não há sobrecarga de tempo de execução.

A única preocupação com o Type Alias ​​Rebinding que vejo pode ser a distribuição binária.

@dc0d prejudicar o desempenho geralmente significa preencher o cache de instruções devido a diferentes implementações de modelos de classe. Como exatamente isso se relaciona com o desempenho real é uma questão em aberto, não conheço nenhum benchmark, mas teoricamente é um problema.

Quanto ao tamanho binário. É outra questão teórica que as pessoas geralmente trazem à tona (como fiz anteriormente), mas como o código real sofrerá com isso é, novamente, uma questão em aberto. Por exemplo, a especialização para todos os tipos de ponteiro e interface pode ser a mesma, eu acho. Mas a especialização para todos os tipos de valor seria única. E isso também inclui estruturas. O uso de contêineres genéricos para armazená-los é comum e causaria um volume significativo de código, pois as implementações de contêineres genéricos não são pequenas.

A única preocupação com o Type Alias ​​Rebinding que vejo pode ser a distribuição binária.

Aqui ainda não tenho certeza. A proposta de genéricos tem que suportar pacotes somente binários ou podemos apenas mencionar que pacotes somente binários não suportam genéricos. Seria muito mais fácil, com certeza.

Como foi mencionado anteriormente, se não for necessário dar suporte à depuração, um
pode combinar instanciações de template idênticas.

Em terça-feira, 10 de abril de 2018, 5h46 Kaveh Shahbazian [email protected]
escreveu:

Primeiro, seria útil refletir sobre as 5 regras de programação de Rob Pike
https://users.ece.utexas.edu/%7Eadnan/pike.html mais uma vez.

Segundo (IMHO):

Sobre compilação lenta e tamanho binário, quantos tipos genéricos são usados ​​em
tipos comuns de aplicativos que estão sendo desenvolvidos usando Go ( n égeralmente pequeno da Regra 3)? A menos que o problema precise de um alto nível de
cardinalidade em conceitos concretos (grande número de tipos) que a sobrecarga pode
ser esquecido. Mesmo assim, eu argumentaria que algo está errado com isso
aproximação. Ao implementar um sistema de e-commerce, ninguém define um
tipo para cada tipo de produto e suas variações e talvez as possíveis
personalizações.

Verbosidade é uma boa forma de simplicidade e familiaridade (por exemplo, em
sintaxe) o que torna as coisas mais óbvias e limpas. Enquanto eu duvido disso
código bloat seria maior usando Type Alias ​​Rebinding, eu gosto do
sintaxe Go-ish familiar e a verbosidade óbvia que a acompanha. Um de
os objetivos do Go é ser fácil de ler (enquanto eu pessoalmente acho
relativamente fácil e agradável de escrever também).

Eu não entendo como isso pode prejudicar o desempenho porque em tempo de execução, apenas
estão sendo usados ​​tipos delimitados de concreto que foram gerados em
tempo de compilação. Não há sobrecarga de tempo de execução.

A única preocupação com o Type Alias ​​Rebinding que vejo, pode ser o binário
distribuição.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-380040032 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
.

As instanciações nem precisam ser “idênticas” no sentido de “usar os mesmos argumentos”, ou mesmo “usar argumentos com o mesmo tipo subjacente”. Eles só precisam estar próximos o suficiente para resultar no mesmo código gerado. (Para Go, isso também implica “as mesmas máscaras de ponteiro”.)

@creker

Pelo que li, C# JIT faz especialização em tempo de execução para cada tipo de valor e uma vez para todos os tipos de referência. Não há especialização em tempo de compilação (tempo IL).

Bem, isso às vezes é um pouco complicado porque seu código de byte é interpretado apenas a tempo antes do código ser executado, então a geração de código é feita antes de executar o programa, mas após a compilação, então você está certo no sentido da vm que está sendo executada enquanto o código é gerado.

Eu acho que o sistema genérico de c# seria bom se, em vez disso, gerarmos código em tempo de compilação.
A geração de código de tempo de execução no sentido de c# não é possível com go, porque go não é uma vm.

@dc0d

A única preocupação com o Type Alias ​​Rebinding que vejo pode ser a distribuição binária.

Você pode elaborar um pouco.

@sighoya Meu erro; Eu quis dizer não distribuição binária, mas pacotes binários - que pessoalmente não tenho ideia de quão importante é.

@creker Belo resumo! (MO) A menos que uma razão forte seja encontrada, qualquer forma de sobrecarregar as construções da linguagem Go deve ser evitada. Uma razão para usar o Type Alias ​​Rebinding é evitar a sobrecarga de tipos compostos internos, como fatias ou mapas.

Verbosidade é uma boa forma de simplicidade e familiaridade (por exemplo, na sintaxe) que torna as coisas mais óbvias e limpas. Embora eu duvide que o excesso de código seja maior usando o Type Alias ​​Rebinding, gosto da sintaxe familiar do Go-ish e da verbosidade óbvia que a acompanha. Um dos objetivos do Go é ser fácil de ler (embora eu pessoalmente ache relativamente fácil e agradável escrever também).

Discordo dessa noção. Sua proposta forçará os usuários a fazer a coisa mais difícil conhecida por qualquer programador - nomear as coisas. Então, vamos acabar com um código cheio de notação húngara, que não só parece ruim, é desnecessariamente verboso e causa gagueira. Além disso, outras propostas também trazem uma sintaxe go-ish e, ao mesmo tempo, não apresentam esses problemas.

Existem três categorias de nomes que temos que inventar diariamente:

• Para Entidades/Lógicas de Domínio
• Tipos de dados/lógica do fluxo de trabalho do programa
• Serviços/Tipos de Dados de Interface/Lógica

Quantas vezes um programador conseguiu evitar nomear qualquer coisa em seu código, nunca?

Difícil ou não, precisa ser feito diariamente. E a maioria de seus obstáculos vem da incompetência na estruturação de uma base de código - não das dificuldades do próprio processo de nomenclatura. Essa citação - pelo menos em sua forma atual - fez um grande desserviço ao mundo da programação até agora. Ele simplesmente tenta enfatizar a importância da nomeação. Porque nos comunicamos por meio de nomes em nosso código.

E os nomes se tornam muito mais poderosos quando acompanham uma prática de estruturação de código; tanto em termos de layout de código (um arquivo, estrutura de diretórios, pacotes/módulos) quanto práticas (padrões de design, abstrações de serviços - como REST, gerenciamento de recursos - programação concorrente, acesso ao disco rígido, taxa de transferência/latência).

Quanto à sintaxe e à verbosidade, prefiro a verbosidade à concisão inteligente (pelo menos no contexto de Go) - novamente, Go deve ser fácil de ler, não necessariamente fácil de escrever (o que estranhamente também acho bom nisso) .

@jba veja https://github.com/golang/go/issues/8303 e https://github.com/golang/go/issues/8082

Li muitos relatos de experiência e propostas sobre o porquê e como implementar genéricos em Go.

Você se importa se eu tentar realmente implementá-los no meu interpretador Go gomacro ?

Tenho alguma experiência no assunto, tendo adicionado genéricos a dois idiomas no passado

1. uma linguagem agora abandonada que criei quando era ingênuo :) Transpilou para o código-fonte C
2. Common Lisp com minha biblioteca cl-parametric-types - também suporta especializações parciais e completas de tipos e funções genéricos

@cosmos72 daria um bom relato de experiência ver um protótipo de uma técnica que preservasse a segurança do tipo.

Acabei de começar a trabalhar nisso. Você pode acompanhar o progresso em https://github.com/cosmos72/gomacro/tree/generics-v1

No momento estou começando com uma mistura (ligeiramente modificada) da terceira e quarta proposta de Ian listada em https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal

@cosmos72 Há um resumo das propostas no link abaixo. Sua mistura é uma delas?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Eu li esse documento, ele resume muitas abordagens diferentes para genéricos por várias linguagens de programação.

No momento estou indo para a técnica de "especialização de tipo" usada por C++, Rust e outros, possivelmente com um pouco de "escopos de modelo parametrizado" porque a sintaxe mais geral do Go para novos tipos é type ( Foo ...; Bar ...) e estou estendendo para template[T1,T2...] type ( Foo ...; Bar ...) .
Além disso, estou mantendo a porta aberta para "Especialização restrita".

Eu gostaria também de implementar a "especialização de função polimórfica", ou seja, fazer com que a especialização seja inferida automaticamente pela linguagem no local da chamada se não for especificada pelo programador, mas acho que pode ser um pouco complexo de implementar. Vamos ver.

A mistura a que me referi é entre https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md e https://github.com/golang/proposal/blob/ master/design/15292/2013-12-type-params.md

Atualização: para evitar enviar spam para esta edição oficial do Go além do anúncio inicial, provavelmente é melhor continuar a discussão específica do gomacro na edição gomacro nº 24: adicionar genéricos

Atualização 2: primeiras funções de modelo compiladas e executadas com sucesso. Veja https://github.com/cosmos72/gomacro/tree/generics-v1

Só para constar, é possível reformular minha opinião (sobre genéricos e Type Alias ​​Rebinding):

Os genéricos devem ser adicionados como um recurso do compilador (geração de código, modelos, etc), não um recurso de linguagem (interferindo no sistema de tipos do Go em todos os níveis).

@dc0d
Mas os modelos C++ não são um compilador e um recurso de linguagem?

@sighoya A última vez que escrevi C++ profissionalmente foi por volta de 2001. Então, posso estar errado. Mas assumindo que as implicações da nomenclatura são precisas - a parte do "modelo" - sim (ou melhor, não); pode ser um recurso do compilador (e não um recurso de linguagem), acompanhado por algumas construções de linguagem, que provavelmente não estão sobrecarregando nenhuma construção de linguagem que esteja envolvida no sistema de tipos.

Eu apoio @dc0d. Se você considerar, esse recurso nada mais seria do que um gerador de código integrado.

Sim: o tamanho do binário pode e VAI aumentar, mas agora usamos geradores de código, que são praticamente os mesmos, mas como um recurso externo. Se eu tiver que criar meu modelo como:

type BinaryTreeOfStrings struct {
    left, right *BinaryTreeOfStrings;
    string content;
}

// Its methods here

type BinaryTreeOfBigInts struct {
    left, right *BinaryTreeOfBigInts;
    uint64 content;
}

// AGAIN the same methods but different type

... Eu realmente gostaria que, em vez de copiar ou usar uma ferramenta externa, esse recurso se tornasse parte do próprio compilador.

Observe:

• Sim, o código final seria duplicado. Certo como se usássemos um gerador. E o binário seria maior.
• Sim, a ideia não é original, mas emprestada do C++.
• Sim, funções de MyTypenão envolvendo nada com o tipo T (direta ou indiretamente) também seria repetido. Isso poderia ser otimizado (por exemplo, métodos que se referem a algo do tipo T - que não o ponteiro para o objeto de recebimento da mensagem - serão gerados para cada T ; métodos que contêm invocações para métodos que ser gerado para cada T , também será gerado para cada T , recursivamente - enquanto métodos onde sua única referência a T é *T no receptor, e outros métodos que chamem apenas aqueles métodos seguros e satisfaçam os mesmos critérios, podem ser feitos apenas uma vez). De qualquer forma, IMO este ponto é grande e menos direto: eu ficaria muito feliz mesmo que essa otimização não exista.
• Os argumentos de tipo devem ser explícitos na minha opinião. Especialmente quando um objeto satisfaz interfaces potencialmente infinitas. Novamente: um gerador de código.

Até agora em meu comentário, minha proposta é implementá-lo como está: como um gerador de código suportado por compilador , em vez de uma ferramenta externa.

Seria lamentável para Go seguir a rota C++. Muitas pessoas veem a abordagem C++ como uma bagunça que colocou os programadores contra toda a ideia de genéricos: dificuldade de depuração, falta de modularidade, excesso de código. Todas as soluções de "gerador de código" são realmente apenas substituição de macro - se é assim que você deseja escrever código, por que precisamos de suporte ao compilador?

@andrewcmyers Eu tive essa proposta Type Alias ​​Rebinding na qual escrevemos apenas pacotes normais e em vez de usar interface{} explicitamente, apenas o usamos como type T = interface{} como um parâmetro genérico em nível de pacote. E isso é tudo.

• Nós o depuramos como um pacote normal - é um código real, não uma criatura de meia-vida intermediária.
• Não há necessidade de se intrometer no sistema do tipo Go em todos os níveis - pense apenas na atribuição.
• É explícito. Nenhum mojo escondido. Claro que pode-se achar que não é possível encadear chamadas genéricas sem problemas, uma desvantagem. Eu vejo isso como um avanço! Alterando o tipo em duas chamadas consecutivas, em uma declaração não é Goish (IMO).
• E o melhor de tudo, é compatível com a série Go 1.x (x >= 8).

Embora a ideia não seja nova, a forma como Go permite implementá-la é pragmática e clara.

Bônus adicional: não há sobrecarga de operadores em Go. Mas definindo o valor padrão do alias de tipo como (por exemplo) type T = int , não os únicos tipos válidos que podem ser usados ​​para personalizar este pacote genérico, são tipos numéricos que possuem uma implementação interna para + operador.

Além disso, o parâmetro de tipo de alias pode ser forçado a preencher mais de uma interface apenas adicionando alguns tipos e instruções de validador.

Agora, isso seria muito feio usando qualquer notação explícita para um tipo genérico que tem um parâmetro que implementa as interfaces Error e Stringer e também é um tipo numérico que suporta o operador + !

agora usamos geradores de código, que são praticamente os mesmos, mas como um recurso externo.

A diferença é que a maneira amplamente aceita de gerar código (via go generate ) acontece em tempo de confirmação/desenvolvimento, não em tempo de compilação. Fazer isso em tempo de compilação implica que você precisa permitir a execução de código arbitrário no compilador, as bibliotecas podem aumentar os tempos de compilação em ordens de magnitude e/ou você terá dependências de compilação separadas (ou seja, o código não pode mais ser construído apenas com o Go ferramenta). Eu gosto de Go por empurrar a invocação de meta-programação para o desenvolvedor upstream.

Ou seja, como todas as abordagens para resolver esses problemas, essa abordagem também possui desvantagens e envolve trade-offs. Pessoalmente, eu diria que os genéricos reais com suporte no sistema de tipos não são apenas melhores (ou seja, têm um conjunto de recursos mais poderoso), mas também podem manter a vantagem de uma compilação previsível e segura.

Vou ler todas as coisas acima, eu prometo, e ainda adicionarei um pouco também - GoLang SDK para Apache Beam parece um exemplo / vitrine bastante brilhante de problemas que o designer de bibliotecas tem que suportar para fazer qualquer coisa _corretamente_ de alto nível.

Há pelo menos duas implementações experimentais para genéricos Go. No início desta semana eu passei algum tempo com (1). Fiquei satisfeito ao descobrir que o impacto na legibilidade do código era mínimo. E descobri que o uso de funções anônimas para fornecer testes de igualdade funcionou bem; então estou convencido de que a sobrecarga do operador não é necessária. O único problema que encontrei foi no tratamento de erros. O idioma comum de “return nil,err” não funcionará se o tipo for, digamos, um inteiro ou uma string. Existem várias maneiras de contornar isso, todas com um custo de complexidade. Posso ser um pouco estranho, mas gosto do tratamento de erros do Go. Portanto, isso me leva a observar que uma solução genérica Go deve ter uma palavra-chave universal para o valor zero de um tipo. O compilador simplesmente o substituiria por zero para tipos numéricos, uma string vazia para tipos de string e nil para structs.

Embora essa implementação não imponha uma abordagem em nível de pacote, certamente seria natural fazê-lo. E, é claro, essa implementação não abordou todos os detalhes técnicos sobre onde o código instanciado pelo compilador deve ir (se houver), como os depuradores de código funcionariam etc.

Foi muito bom usar o mesmo código de algoritmo para inteiros e algo como um Point:

type Point struct {
    x,y int
}

Veja (2) para meus testes e observações.

(1) https://github.com/albrow/fo; o outro é o mencionado https://github.com/cosmos72/gomacro#generics
(2) https://github.com/mandolyte/fo-experiments

@mandolyte Você pode usar *new(T) para obter o valor zero de qualquer tipo.

Uma construção de linguagem como default(T) ou zero(T) (o primeiro é aquele
em C# IIRC) seria claro, mas OTOH maior que *new(T) (embora mais
performer).

2018-07-06 9:15 GMT-05:00 Tom Thorogood [email protected] :

@mandolyte https://github.com/mandolyte Você pode usar *new(T) para obter o
valor zero de qualquer tipo.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-403046735 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
Este é um teste para assinaturas de correio a serem usadas no TripleMint

19642 é para discutir um valor zero genérico

@tmthrgd De alguma forma, perdi esse pequeno detalhe. Obrigado!

prelúdio

Os genéricos têm tudo a ver com construções personalizáveis ​​especializadas. Três categorias de especialização são:

• Tipos especializados, Type<T> - um _array_;
• Computações especializadas, F<T>(T) ou F<T>(Type<T>) - um _array classificável_;
• Notação especializada, _LINQ_ por exemplo - instruções select ou for em Go;

Claro que existem linguagens de programação que apresentam construções ainda mais genéricas. Mas linguagens de programação convencionais como _C++_, _C#_ ou _Java_ fornecem mais ou menos construções de linguagem limitadas a esta lista.

pensamentos

A primeira categoria de tipos/construtos genéricos deve ser independente de tipo.

A segunda categoria de tipos/construtos genéricos precisa _agir_ sobre uma _propriedade_ do parâmetro de tipo. Por exemplo, um _array classificável_ deve ser capaz de _comparar_ a _propriedade comparável_ de seus itens. Assumindo que T.(P) é uma propriedade de T e A(T.(P)) é um cálculo/ação que atua sobre essa propriedade, o (A, .(P)) pode ser aplicado a cada item individual ou ser declarado como uma computação especializada, passada para a computação personalizável original. Um exemplo do último caso em Go é a interface sort.Interface que também tem a função de contrapartida separada sort.Reverse .

A terceira categoria de tipos/construtos genéricos são notações de linguagem _tipo-especializadas_ - parece não ser uma coisa Go _em geral_.

perguntas

continua ...

Qualquer feedback mais descritivo do que um emoji é muito bem-vindo!

@dc0d Eu recomendaria estudar os "Elementos de programação" de Sepanov antes de tentar definir os genéricos. O TL;DR é escrever um código concreto para começar, digamos um algoritmo que ordena um array. Mais tarde, adicionamos outros tipos de coleção como um Btree, etc. Notamos que estamos escrevendo muitas cópias do algoritmo de classificação que são essencialmente as mesmas, então definimos algum conceito, digamos 'classificável'. Agora queremos categorizar os algoritmos de ordenação, talvez pelo padrão de acesso que eles requerem, digamos, apenas encaminhamento, passagem única (um fluxo), encaminhamento apenas passagem múltipla (uma lista vinculada simples), bidirecional (uma lista duplamente vinculada), acesso aleatório (uma variedade). Quando adicionamos um novo tipo de coleção, precisamos apenas indicar em qual categoria de "coordenada" ele se enquadra para obter acesso a todos os algoritmos de classificação relevantes. Essas categorias de algoritmos são muito parecidas com interfaces 'Go'. Eu estaria procurando estender interfaces em Go para suportar vários parâmetros de tipo e tipos abstratos/associados. Eu não acho que as funções precisam de parametrização de tipo ad-hoc.

@dc0d Como uma tentativa de dividir os genéricos em partes componentes, eu não havia considerado 3, "notação especializada", como sua própria parte separada antes. Talvez possa ser caracterizado como definindo DSLs utilizando restrições de tipo.

Eu poderia argumentar que seu 1 e 2 são "estruturas de dados" e "algoritmos", respectivamente. Com essa terminologia, fica um pouco mais claro por que pode ser difícil separá-los de forma limpa, pois geralmente são altamente dependentes um do outro. Mas sort.Interface é um bom exemplo de onde você pode traçar uma linha entre armazenamento e comportamento (com um pouco de açúcar recente para torná-lo mais agradável), uma vez que codifica os requisitos Indexable e Comparable no comportamento mínimo necessário para implementar o algoritmo de classificação com "swap" e "less" (e len). Mas isso parece quebrar em estruturas de dados mais complicadas, como árvores ou heaps, que atualmente exigem algumas contorções para mapear o comportamento puro como interfaces Go.

Eu poderia imaginar uma adição genérica relativamente pequena às interfaces (ou não) que poderia permitir que a maioria das estruturas de dados e algoritmos de livros didáticos fossem implementados de forma relativamente limpa, sem contorções (como sort.Interface é hoje), mas não é poderoso o suficiente para projetar DSLs. Se queremos nos limitar a uma implementação de genéricos tão restrita quando estamos tendo todo o trabalho de adicionar genéricos é uma questão diferente.

Estruturas de coordenadas @infogulch para árvores binárias são "coordenadas bifurcadas" e existem equivalentes para outras árvores. No entanto, você também pode projetar a ordenação de uma árvore por meio de uma das três ordens, pré-encomenda, em ordem e pós-encomenda. Tendo decidido por um deles, a árvore pode ser endereçada como uma coordenada bidirecional, e a família de algoritmos de classificação definida em coordenadas bidirecionais seria otimamente eficiente.

O ponto é que você categoriza os algoritmos de classificação por seus padrões de acesso. Há apenas um número finito de algoritmos de ordenação ótimos para cada padrão de acesso. Você não se importa com as estruturas de dados neste momento. Falar sobre estruturas mais complexas perde o foco, queremos categorizar a família de algoritmos de classificação e não as estruturas de dados. Quaisquer dados que você tenha, você terá que usar um dos algoritmos que existem para classificá-los, então a questão é qual das categorizações de padrões de acesso a dados disponíveis de algoritmos de classificação é ideal para as estruturas de dados que você possui.

(NA MINHA HUMILDE OPINIÃO)

@infogulch

Talvez possa ser caracterizado como definindo DSLs utilizando restrições de tipo

Você está certo. Mas como eles fazem parte do conjunto de construções de linguagem, a IMO chamá-los de DSLs seria um pouco impreciso.

1 e 2 ... muitas vezes são altamente dependentes

Novamente verdade. Mas há muitos casos em que há necessidade de um tipo de contêiner ser passado, enquanto o uso real ainda não está decidido - nesse ponto em um programa. É por isso que 1 é necessário para ser estudado por conta própria.

sort.Interface é um bom exemplo de onde você pode traçar uma linha entre _storage_ e _behavior_

Bem dito;

isso parece quebrar em estruturas de dados mais complicadas

Essa é uma das minhas perguntas: generalizar o parâmetro type e descrevê-lo em termos de restrições (como List<T> where T:new, IDisposable ) ou fornecer um _protocol_ generalizado aplicável a todos os itens (de um conjunto; de um determinado tipo)?

@keean

a questão torna-se qual das categorizações de padrões de acesso a dados disponíveis de algoritmos de classificação é ideal para as estruturas de dados que você possui

Verdadeiro. O acesso por índice é uma _propriedade_ de uma fatia (ou array). Portanto, o primeiro requisito para um contêiner classificável (ou contêiner _tree_ -able qualquer que seja o algoritmo _tree_) é fornecer um utilitário _access & mutate (swap)_. O segundo requisito é que os itens sejam comparáveis. Essa é a parte confusa (para mim) sobre o que você chama de algoritmos: os requisitos devem ser atendidos em ambos os lados (no contêiner e no parâmetro de tipo). Esse é o ponto que não consigo imaginar uma implementação pragmática de genéricos em Go. Cada lado do problema pode ser descrito perfeitamente em termos de interfaces. Mas como combinar esses dois em uma notação eficaz?

Os algoritmos @dc0d requerem interfaces, as estruturas de dados as fornecem. Isso é suficiente para a generalidade total, desde que as interfaces sejam suficientemente poderosas. As interfaces são parametrizadas por tipos, mas você precisa de variáveis ​​de tipo.

Tomando o exemplo 'sort', 'Ord' é uma propriedade do tipo armazenado no container, não o próprio container. O padrão de acesso é uma propriedade do contêiner. Padrões de acesso simples são 'iteradores', mas esse nome vem de C++, Stepanov prefere 'coordenadas', pois pode ser aplicado a contêineres multidimensionais mais complexos.

Tentando definir sort, queremos algo assim:

bubble_sort : forall T U I => T U -> T U requires
   ForwardIterator<T>, Readable<T>, Writable<T>,
   Ord<U>,  ValueType(T) == U, Distance type(T) == I

Nota: não estou sugerindo esta notação, apenas tentando puxar algum outro trabalho relacionado, a cláusula require está na sintaxe preferida por Stepanov, o tipo de função é de Haskell, cujas classes de tipos provavelmente representam uma boa implementação desses conceitos.

@keean
Talvez eu esteja entendendo mal você, mas não acho que você possa simplesmente restringir algoritmos apenas a interfaces, pelo menos da maneira como as interfaces são definidas agora.
Considere sort.Slice, por exemplo, estamos interessados ​​em classificar fatias, e não vejo como alguém construiria uma interface que representasse todas as fatias.

@urandom você abstrai os algoritmos e não as coleções. Então você pergunta quais padrões de acesso a dados existem em algoritmos de "classificação" e então os classifica. Portanto, não importa se o contêiner é uma "fatia", não estamos tentando definir todas as operações que você deseja realizar em uma fatia, estamos tentando determinar os requisitos de um algoritmo e usá-lo para definir uma interface. Uma fatia não é especial, é apenas um tipo T sobre o qual podemos definir um conjunto de operações.

Portanto, as interfaces estão relacionadas a bibliotecas de algoritmos e você pode definir suas próprias interfaces para suas próprias estruturas de dados para poder usar esses algoritmos. As bibliotecas podem vir com interfaces pré-definidas para os tipos internos.

@keean
Achei que era isso que você queria dizer. Mas no contexto do Go, isso provavelmente significaria que precisaria haver uma revisão significativa do que as interfaces podem definir. Eu imagino que várias operações internas, como iterações ou operadores, precisariam ser expostas por meio de métodos para que coisas como sort.Slice ou math.Max fossem genéricas nas interfaces.

Então você teria que ter suporte para a seguinte interface (pseudo-código):

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

e todas as fatias teriam então esses métodos?

@urandom Um iterador não é uma abstração de uma coleção, mas uma abstração da referência/ponteiro em uma coleção. Por exemplo, o iterador de encaminhamento pode ter um único método 'sucessor' (às vezes 'próximo'). Ser capaz de acessar dados no local de um iterador não é uma propriedade do iterador (caso contrário, você acabará com sabores de leitura/gravação/mutáveis ​​de iterador). É melhor definir "referências" separadamente como interfaces legíveis, graváveis ​​e mutáveis:

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

Nota: O tipo 'T' não é a fatia, mas o tipo do iterador na fatia. Isso poderia ser apenas um ponteiro simples, se adotarmos o estilo C++ de passar um iterador inicial e final para funções como sort.

Para um iterador de acesso aleatório, teríamos algo como:

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

Portanto, um iterador/coordenada é uma abstração da referência a uma coleção, não a coleção em si. O nome 'coordenada' expressa isso muito bem, se você pensar no iterador como a coordenada e na coleção como o mapa.

Não estamos vendendo o Go short por não alavancar fechamentos de função e funções anônimas? Ter funções/métodos como um tipo de primeira classe em Go pode ajudar. Por exemplo, usando a sintaxe de albrow/fo , um tipo de bolha pode ter esta aparência:

type SortableContainer[C,T] struct {
    Less func(C,T,T) bool
    Swap func(C,int,int)
    Next func(C) (T,bool)
}

func (bs *SortableContainer[C,T]) BubbleSort(container C, e1,e2 T) {    
    swapCount := 1
    var item1, item2 T
    item1, ok1 = bs.Next()
    if !ok1 {return}
    item2, ok2 = bs.Next()
    if !ok2 {return}
    for swapCount > 0 {
        swapCount = 0
        for {
            if Less(item2, item1) { 
                bs.Swap(C,item2,item1)
                swapCount += 1
            }
        }
    }
}

Por favor, ignore quaisquer erros... completamente não testado!

@mandolyte Não tenho certeza se isso foi endereçado a mim? Eu realmente não vejo nenhuma diferença entre o que eu estava sugerindo e seu exemplo, exceto que você está usando interfaces multiparâmetros, e eu estava dando exemplos usando tipos abstratos/associados. Para ser claro, acho que você precisa de interfaces multiparâmetros e tipos abstratos/associados para total generalidade, nenhum dos quais é atualmente suportado pelo Go.

Sugiro que suas interfaces sejam menos gerais do que as que propus, porque vinculam a ordem de classificação, o padrão de acesso e a acessibilidade na mesma interface, o que obviamente resultará na proliferação de interfaces, por exemplo, duas ordens (menos , maior), três tipos de acesso (somente leitura, somente gravação, mutável) e cinco padrões de acesso (passagem única direta, passagem múltipla direta, bidirecional, indexado, aleatório) levariam a 36 interfaces em comparação com apenas 11 se as preocupações forem mantidas separadas.

Você pode definir as interfaces que proponho com interfaces multiparâmetros em vez de tipos abstratos como este:

type I ForwardIterator interface {
   successor(x I) I
}
type R V Readable interface {
   source(x R) V
}
type V Ord interface {
   less(x V, y V) : bool
}

Observe que o único que precisa de dois parâmetros de tipo é a interface Readable. No entanto, perdemos a capacidade de um objeto iterador 'conter' o tipo dos objetos iterados, o que é um grande problema, pois agora temos que mover o tipo 'valor' no sistema de tipos e temos que corrigi-lo . Isso leva a uma proliferação de parâmetros de tipo que não é bom e aumenta a possibilidade de erros de codificação. Também perdemos a capacidade de definir o 'DistanceType' no iterador, que é o menor tipo de número necessário para contar os elementos na coleção, o que é útil para mapear para int8, int16, int32 etc, para fornecer o tipo que você precisa contar elementos sem estouro.

Isso está intimamente ligado ao conceito de 'dependência funcional'. Se um tipo for funcionalmente dependente de outro tipo, ele deve ser um tipo abstrato/associado. Somente se os dois tipos forem independentes, eles devem ser parâmetros de tipo separados.

Alguns problemas:

1. Não é possível usar a sintaxe f(x I) atual para interfaces multiparâmetros. Eu não gosto que essa sintaxe confunda interfaces (que são restrições de tipos) com tipos de qualquer maneira.
2. Seria necessário uma maneira de declarar tipos parametrizados.
3. Seria necessário haver uma maneira de declarar tipos associados para interfaces com um determinado conjunto de parâmetros de tipo.

@keean Não tenho certeza se entendi como ou por que a contagem de interfaces fica tão alta. Aqui está um exemplo completo de trabalho: https://play.folang.org/p/BZa6BdsfBgZ (baseado em fatia, não um contêiner geral, portanto, nenhum método Next() necessário).

Ele usa apenas uma estrutura de tipo, sem nenhuma interface. Eu tenho que fornecer todas as funções e encerramentos anônimos (provavelmente é aí que está a troca?). O exemplo usa o mesmo algoritmo de classificação de bolhas para classificar uma fatia de inteiros e uma fatia de pontos "(x,y)", em que a distância da origem é a base da função Less().

De qualquer forma, eu esperava mostrar como ter funções no sistema de tipos pode ajudar.

@mandolyte Acho que não entendi o que você estava propondo. Vejo que você está falando de "folang", que já possui alguns recursos de programação funcionais interessantes adicionados ao Go. O que você implementou é basicamente canalizar manualmente uma classe de tipos multiparâmetros. Você está passando o que é conhecido como dicionário de funções para a função de classificação. Isso está fazendo explicitamente o que uma interface faria implicitamente. Esses tipos de recursos provavelmente são necessários antes de interfaces multiparâmetros e tipos associados, mas você eventualmente terá problemas ao passar todos esses dicionários. Eu acho que as interfaces fornecem um código mais limpo e legível.

Classificar uma fatia é um problema resolvido. Aqui está o código para uma fatia quicksort.go implementada usando a linguagem go-li (golang melhorada) .

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

Você pode experimentar isso no playground

Exemplo completo que você pode colar no playground , pois importar o pacote quicksort não funciona no playground.

@go-li Tenho certeza de que você pode classificar uma fatia, seria um pouco ruim se não pudesse. O ponto é que, genericamente, você gostaria de poder classificar qualquer contêiner linear com o mesmo código, de modo que você só precise escrever um algoritmo de classificação uma vez, não importa qual contêiner (estrutura de dados) você esteja classificando e não importa qual o conteúdo é.

Quando você pode fazer isso, a biblioteca padrão pode fornecer funções de classificação universais e ninguém precisa escrever uma novamente. Há dois benefícios para isso, menos erros, pois é mais difícil do que você pensa escrever um algoritmo de classificação correto, Stepanov usa o exemplo de que a maioria dos programadores não pode definir corretamente o par 'min' e 'max', então que esperança temos que ser correto para algoritmos mais complexos. O outro benefício é que quando há apenas uma definição de cada algoritmo de ordenação, quaisquer melhorias na clareza ou desempenho que possam ser feitas beneficiam todos os programas que o utilizam. As pessoas podem gastar seu tempo tentando melhorar o algoritmo comum em vez de ter que escrever seu próprio para cada tipo de dado diferente.

@keean
Outra questão relacionada à nossa discussão anterior. Não consigo descobrir como alguém seria capaz de definir uma função de mapeamento que altera itens de um iterável, retornando um novo tipo iterável concreto cujos itens podem ser de um tipo diferente do original.

E imagino que um usuário de tal função gostaria de um tipo concreto retornado, não outra interface.

@urandom Supondo que não queremos fazer isso 'no local', o que seria inseguro, o que você deseja é uma função de mapa que tenha um 'iterador de leitura' de um tipo e um 'iterador de gravação' de outro tipo, que pode ser definido algo como:

map<I, O, U>(first I, last I, out O, fn U) requires
   ForwardIterator<I>, Readable<I>,
   ForwardIterator<O>, Writable<O>,
   UnaryFunction<U>, Domain(U) == ValueType(I), Codomain(U) == ValueType(O)

Para maior clareza, "ValueType" é um tipo associado das interfaces "Readable" e "Writable", "Domain" e "Codomain" são tipos associados da interface "UnaryFunction". Obviamente, ajuda muito se o compilador puder derivar automaticamente as interfaces para tipos de dados como "UnaryFunction". Embora isso pareça reflexão, não é, e tudo acontece em tempo de compilação usando tipos estáticos.

@keean Como modelar essas restrições de leitura e gravação no contexto das interfaces atuais do Go?

Quero dizer, quando temos um tipo A e queremos converter para o tipo B , a assinatura dessa UnaryFunction seria func (input A) B (certo?), mas como isso pode ser modelado usando apenas interfaces e como esse map genérico (ou filter , reduce , etc.) seria modelado para manter o pipeline de tipos?

@geovanisouza92 Acho que "Type Families" funcionaria bem, pois podem ser implementados como um mecanismo ortogonal no sistema de tipos e, em seguida, integrados à sintaxe das interfaces, como é feito em Haskell.

Uma família de tipos é como uma função restrita em tipos (um mapeamento). Como as implementações de interface são selecionadas por tipo, podemos fornecer um mapeamento de tipo para cada implementação.

Então, se definirmos:

ValueType MyIntArrayIterator -> Int

As funções são um pouco mais complicadas, mas uma função tem um tipo, por exemplo:

fn(x : Int) Float

Nós escreveríamos este tipo:

Int -> Float

É importante perceber que -> é apenas um construtor de tipo infixo, como '[]' para um Array é um construtor de tipo, poderíamos facilmente escrever isso;

Fn Int Float
Or
Fn<Int, Float>

Dependendo de nossa preferência por sintaxe de tipo. Agora podemos ver claramente como podemos definir:

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

Agora, embora possamos fornecer todas essas definições manualmente, elas podem ser facilmente derivadas pelo compilador.

Dadas essas famílias de tipos, podemos ver que a definição de mapa que dei acima requer apenas os tipos IO e U para instanciar o genérico, pois todos os outros tipos são funcionalmente dependentes deles. Podemos ver que esses tipos são fornecidos diretamente pelos argumentos.

Obrigado, @keean.

Isso funcionaria bem para funções internas/predefinidas. Você está dizendo que o mesmo conceito seria aplicado para funções definidas pelo usuário ou libs do usuário?

Essas "Famílias de Tipos" serão transportadas em tempo de execução, no caso de algum contexto de erro?

Que tal interfaces vazias, interruptores de tipo e reflexão?

EDIT: Estou apenas curioso, não reclamando.

@giovanisouza92 bem, ninguém se comprometeu a ter genéricos, então espero ceticismo. Minha abordagem é que, se você for fazer genéricos, deve fazê-los corretamente.

No meu exemplo, 'map' é definido pelo usuário. Não há nada de especial nisso, e dentro da função você simplesmente usa os métodos das interfaces que você exigiu nesses tipos exatamente como você faz no Go agora. A única diferença é que podemos exigir um tipo para satisfazer várias interfaces, as interfaces podem ter vários parâmetros de tipo (embora o exemplo do mapa não use isso) e também existem tipos associados (e restrições em tipos como a igualdade de tipo '==' mas isso é como uma igualdade Prolog e unifica os tipos). É por isso que existe a sintaxe diferente para especificar as interfaces exigidas por uma função. Observe que há outra diferença importante:

f(x I, y I) requires ForwardIterator<I>

Vs

f(x ForwardIterator, y ForwardIterator)

Observe que há uma diferença no último 'x' e 'y' podem ser tipos diferentes que satisfaçam a interface ForwardIterator, enquanto na sintaxe anterior 'x' e 'y' devem ser do mesmo tipo (que satisfaça o iterador de encaminhamento). Isso é importante para que as funções não sejam restritas e permita que tipos concretos sejam propagados muito mais durante a compilação.

Acho que não muda nada em relação a trocas de tipo e reflexão, porque estamos apenas estendendo o conceito de interfaces. Como go tem informações de tipo de tempo de execução, você não entra no mesmo problema que Haskell e exige tipos existenciais.

Pensando em Go, polimorfismo de tempo de execução e famílias de tipos, provavelmente gostaríamos de restringir a própria família de tipos a uma interface para evitar ter que tratar todos os tipos associados como uma interface vazia em tempo de execução, o que seria lento.

Então, à luz desses pensamentos, eu modificaria minha proposta acima para que, ao declarar uma interface, você declarasse uma interface/tipo para cada tipo associado que todas as implementações dessa interface teriam que fornecer um tipo associado que satisfizesse essa interface. Dessa forma, podemos saber que é seguro chamar qualquer método dessa interface nos tipos associados em tempo de execução sem ter que mudar de tipo de uma interface vazia.

@keean
Para avançar no debate, deixe-me esclarecer o equívoco que sinto é semelhante à síndrome não inventada aqui.

O iterador bidirecional (na sintaxe T func (*T) *[2]*T ) tem o tipo func (*) *[2]* na sintaxe go-li. Em palavras, ele pega um ponteiro para algum tipo e retorna um ponteiro para dois ponteiros para o elemento seguinte e anterior do mesmo tipo. É o tipo fundamental concreto fundamental usado por uma lista duplamente vinculada .

Agora você pode escrever o que chama de map, o que chamo de função genérica foreach. Não se engane, isso funciona não apenas na lista vinculada, mas em qualquer coisa que exponha um iterador bidirecional!

func Foreach(link func(*) *[2]*, list **, direction byte, f func(*)) {

    if nil == *list {
        return
    }

    var end *
    end = *list

    var e *
    e = (*link(*list))[direction]
    f(end)

    for (e != end) && ((*link(e))[direction] != nil) {
        var newe = (*link(e))[direction]
        f(e)
        e = newe
    }
    return
}

O Foreach pode ser usado de duas maneiras, você o usa com um lambda em uma iteração do tipo loop for sobre elementos de lista ou coleção.

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

Ou você pode usá-lo para mapear funcionalmente uma função para cada elemento da coleção.

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

É claro que o iterador bidirecional também pode ser modelado usando interfaces em go 1.
interface Iterator { Iter() [2]Iterator } Você precisa modelá-lo usando interfaces para envolver ("caixa") o tipo subjacente. O usuário do iterador, em seguida, digita afirma o tipo conhecido assim que localiza e deseja visitar um elemento de coleção específico. Isso é potencialmente inseguro em tempo de compilação.

O que você está descrevendo a seguir são as diferenças entre a abordagem herdada e a abordagem baseada em genéricos.

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

essa abordagem de tipo de tempo de compilação verifica se as duas coleções têm o mesmo tipo subjacente, em outras palavras, se os iteradores realmente retornam os mesmos tipos concretos

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

O mesmo que acima, mas usando o familiar T significa sintaxe de espaço reservado para o tipo

func legacy(x Iterator, y Iterator){}

Neste caso, o usuário pode passar, por exemplo, lista encadeada inteira como x e lista encadeada flutuante como y. Isso pode levar a possíveis erros de tempo de execução, pânico ou outras decoerências internas, mas tudo depende do que o legado faria com os dois iteradores.

Agora o equívoco. Você afirma que fazer iteradores e fazer classificações genéricas para classificar esses iteradores seria o caminho a seguir. Isso seria uma coisa realmente ruim de se fazer, eis por que

O iterador e a lista vinculada são dois lados da mesma moeda. Prova: qualquer coleção que exponha o iterador simplesmente se anuncia como uma lista vinculada. Digamos que você precise classificar isso. Fazer o que?

Obviamente, você exclui a lista vinculada de sua base de código e a substitui por uma árvore binária. Ou se você quer ser chique use uma árvore de busca balanceada como avl, red-black, como proposto não sei quantos anos atrás por Ian et all. Ainda isso não foi feito genericamente em Golang. Agora esse seria o caminho a seguir.

Outra solução é rapidamente em loop de tempo O(N) sobre o iterador, coletar os ponteiros para elementos em uma fatia de ponteiros genéricos, denotados []*T e classificar esses ponteiros genéricos usando a classificação de fatias ruim

Por favor, dê uma chance às ideias de outras pessoas

@go-li Se quisermos evitar a síndrome do não-inventado-aqui, devemos procurar uma definição de Alex Stepanov, pois ele praticamente inventou a programação genérica. Aqui está como eu o definiria, tirado da página 111 de "Elementos de programação" de Stepanov:

Bidirectional iterator<T> =
    ForwardIterator<T>
/\ predecessor : T -> T
/\ predecessor takes constant time
/\ (forall i in T) successor(i) is defined =>
        predecessor(successor(i)) is defined and equals i
/\ (forall i in T) predecessor(i) is defined =>
        successor(predecessor(i)) is defined and equals i

Isso depende da definição de ForwardIterator:

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

Então, essencialmente, temos uma interface que declara uma função successor e uma função predecessor , juntamente com alguns axiomas que eles devem cumprir para serem válidos.

Com relação legacy não é que o legado vá dar errado, obviamente não dá errado em Go atualmente, mas o compilador está perdendo oportunidades de otimização, e o sistema de tipos está perdendo a oportunidade de propagar tipos concretos ainda mais. Também está limitando os programadores a especificar sua intenção com precisão. Um exemplo seria uma função de identidade, que pretendo retornar exatamente o tipo que é passado:

id(x T) T

Talvez também valha a pena mencionar a diferença entre um tipo paramétrico e um tipo quantificado universalmente. Um tipo paramétrico seria id<T>(x T) T enquanto o quantificado universalmente é id(x T) T (normalmente omitimos o quantificador universal mais externo neste caso forall T ). Com tipos paramétricos, o sistema de tipos deve ter um tipo para T fornecido no site de chamada para id , com quantificação universal que não é necessária desde que T seja unificado com um tipo concreto antes da compilação terminar. Outra maneira de entender isso é que a função paramétrica não é um tipo, mas um modelo para um tipo, e só é um tipo válido depois que T for substituído por um tipo concreto. Com a função quantificada universalmente id na verdade tem um tipo forall T . T -> T que pode ser passado pelo compilador assim como Int .

@go-li

Obviamente, você exclui a lista vinculada de sua base de código e a substitui por uma árvore binária. Ou se você quer ser chique use uma árvore de busca balanceada como avl, red-black, como proposto não sei quantos anos atrás por Ian et all. Ainda isso não foi feito genericamente em Golang. Agora esse seria o caminho a seguir.

Ter estruturas de dados ordenadas não significa que você nunca precise classificar dados.

Se quisermos evitar a síndrome do não-inventado-aqui, devemos procurar uma definição de Alex Stepanov, já que ele praticamente inventou a programação genérica.

Eu contestaria qualquer afirmação de que a programação genérica foi inventada por C++. Leia o Liskov et al. Artigo CACM de 1977 se você quiser ver um modelo inicial de programação genérica que realmente funciona (tipo seguro, modular, sem excesso de código): https://dl.acm.org/citation.cfm?id=359789 (consulte a Seção 4 )

Acho que devemos parar com essa discussão e esperar que a equipe golang (russ) venha com algumas postagens no blog e depois implemente uma solução 👍 (veja vgo) Eles vão fazer isso 🎉

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

Espero que esta história sirva como um aviso para os outros: se você estiver interessado em fazer contribuições substanciais para o projeto Go, nenhuma due diligence independente pode compensar um design que não se origina da equipe principal.

Este tópico mostra como a equipe principal não está interessada em participar ativamente na busca de uma solução com a comunidade.

Mas no final, se eles puderem fazer uma solução sozinhos novamente, tudo bem para mim, apenas faça 👍

@andrewcmyers Bem, talvez "inventado" tenha sido um pouco exagerado, provavelmente é mais como David Musser em 1971, que mais tarde trabalhou com Stepanov em algumas bibliotecas genéricas para Ada.

Elements of Programming não é um livro sobre C++, os exemplos podem estar em C++, mas isso é uma coisa bem diferente. Eu acho que este livro é leitura essencial para quem quer implementar genéricos em qualquer idioma. Antes de dispensar Stepanov, você deve realmente ler o livro para ver do que se trata.

Esse problema já está sobrecarregando os limites da escalabilidade do GitHub. Por favor, mantenha a discussão aqui focada em questões concretas para as propostas do Go.

Seria lamentável para Go seguir a rota C++.

@andrewcmyers Sim, concordo plenamente, não use C++ para sugestões de sintaxe ou como referência para fazer as coisas corretamente. Em vez disso, dê uma olhada em D para se inspirar .

@nomad-software

Eu gosto muito de D, mas o go precisa dos poderosos recursos de metaprogramação de tempo de compilação que D oferece?

Eu não gosto da sintaxe do modelo, também em C++, decorrente da idade da pedra.

Mas e o ParametricType normalpadrão encontrado em Java ou C #, se necessário, também pode sobrecarregar isso com ParametricType

E mais, eu não gosto da sintaxe de chamada de template em D com seu símbolo bang, o símbolo bang é bastante usado hoje em dia para denotar acesso mutável ou imutável para os parâmetros de uma função.

@nomad-software Eu não estava sugerindo que a sintaxe C++ ou o mecanismo de modelo é o caminho certo para fazer genéricos. Mais do que "conceitos" como definidos por Stepanov tratam os tipos como uma álgebra, que é a maneira correta de fazer genéricos. Veja as classes de tipo Haskell para ver como isso pode ficar. As classes do tipo Haskell são muito próximas aos modelos e conceitos de C++ semanticamente, se você entender o que está acontecendo.

Portanto, +1 por não seguir a sintaxe de c++ e +1 por não implementar um sistema de modelo inseguro de tipo :-)

@keean A razão para a sintaxe D é evitar completamente <,> e aderir à gramática livre de contexto. Isso faz parte do meu ponto de usar D como inspiração. <,> é uma escolha muito ruim para a sintaxe de parâmetros genéricos.

@nomad-software Como apontei acima (em um comentário agora oculto), você precisa especificar os parâmetros de tipo para tipos paramétricos, mas não para tipos quantificados universalmente (daí a diferença entre Rust e Haskell, a maneira como os tipos são tratados é realmente diferente no sistema de tipos). Também conceitos C++ == classes de tipo Haskell == interfaces Go, pelo menos em um nível conceitual.

A sintaxe D é realmente preferível:

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

Por que isso é melhor que o estilo C++/Java/Rust:

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

Ou estilo Scala:

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

Eu fiz algumas reflexões sobre a sintaxe para parâmetros de tipo. Eu nunca fui fã de "colchetes angulares" em C++ e Java porque eles tornam a análise bastante complicada e, portanto, impedem o desenvolvimento de ferramentas. Os colchetes são, na verdade, uma escolha clássica (de CLU, System F e outras linguagens antigas com polimorfismo paramétrico).

No entanto, a sintaxe do Go é bastante delicada, talvez porque já seja tão concisa. Sintaxes possíveis baseadas em colchetes ou parênteses criam ambiguidades gramaticais ainda piores do que aquelas introduzidas por colchetes angulares. Então, apesar das minhas predisposições, os colchetes parecem ser a melhor escolha para o Go. (Claro, também existem colchetes angulares reais que não criariam nenhuma ambiguidade — ⟨⟩ — mas exigiriam o uso de caracteres Unicode).

Claro, a sintaxe precisa usada para parâmetros de tipo é menos importante do que acertar a semântica . Nesse ponto, a linguagem C++ é um modelo ruim. O trabalho do meu grupo de pesquisa sobre genéricos em Gênero (PLDI 2015) e Família (OOPSLA 2017) oferece outra abordagem que estende classes de tipos e as unifica com interfaces.

@andrewcmyers Eu acho que ambos os artigos são interessantes, mas eu diria que não é uma boa direção para Go, já que Genus é orientado a objetos e Go não é, e Familia unifica subtipagem e polimorfismo paramétrico, e Go não tem nenhum. Acho que Go deveria simplesmente adotar polimorfismo paramétrico ou quantificação universal, não precisa de subtipagem, e na minha opinião é uma linguagem melhor por não tê-la.

Acho que Go deveria estar procurando por genéricos que não exijam orientação a objetos e não exijam subtipagem. Go já tem interfaces, que eu acho que são um bom mecanismo para genéricos. Se você puder ver que interfaces Go == conceitos de c++ == classes de tipo Haskell, parece-me que a maneira de adicionar genéricos mantendo o sabor de 'Go' seria estender interfaces para receber vários parâmetros de tipo (eu como tipos associados em interfaces também, mas isso pode ser uma extensão separada, ajuda a aceitar vários parâmetros de tipo). Essa seria a mudança de chave, mas para habilitar isso, seria necessário haver uma sintaxe 'alternativa' para interfaces em assinaturas de função, para que você possa obter os vários parâmetros de tipo para as interfaces, que é onde entra toda a sintaxe de colchetes angulares .

As interfaces Go não são classes de tipo — são apenas tipos — mas unificar interfaces com classes de tipo é o que o Familia mostra uma maneira de fazer. Os mecanismos de Genus e Familia não estão vinculados ao fato de as linguagens serem totalmente orientadas a objetos. As interfaces Go já o tornam "orientado a objetos" da maneira que importa, então acho que as ideias podem ser adaptadas de forma ligeiramente simplificada.

@andrewcmyers

As interfaces Go não são classes de tipos — são apenas tipos

Eles não se comportam como tipos para mim, pois permitem polimorfismo. O objeto em uma matriz polimórfica como Addable[] ainda tem seu tipo real (visível por reflexão de tempo de execução), então eles se comportam exatamente como classes de tipo de parâmetro único. O fato de serem colocados no lugar de um tipo em assinaturas de tipo é simplesmente uma notação abreviada omitindo a variável de tipo. Não confunda a notação com a semântica.

f(x : Addable) == f<T>(x : T) requires Addable<T>

Essa identidade é, obviamente, válida apenas para interfaces de parâmetro único.

A única diferença significativa entre interfaces e classes de tipo de parâmetro único é que as interfaces são definidas localmente, mas isso é útil porque evita o problema de coerência global que Haskell tem com suas classes de tipo. Eu acho que este é um ponto interessante no espaço de design. As interfaces multiparâmetros dariam a você todo o poder das classes de tipos multiparâmetros com o benefício de serem locais. Não há necessidade de adicionar herança ou subtipagem à linguagem Go (que são os dois principais recursos que definem OO, eu acho).

NA MINHA HUMILDE OPINIÃO:

Ainda ter um tipo padrão seria preferível a uma DSL dedicada a expressar restrições de tipo. Como ter uma função f(s T fmt.Stringer) que é uma função genérica que aceita qualquer tipo que também seja/satisfaça a interface fmt.Stringer .

Desta forma é possível ter uma função genérica como:

func add(a, b T int) T int {
    return a + b
}

Agora a função add() funciona com qualquer tipo T que como int s suporta o operador + .

@ dc0d Concordo que parece atraente olhando para a sintaxe atual do Go. No entanto, não é 'completo', pois não pode representar todas as restrições necessárias para genéricos, e ainda haverá um esforço para estender isso ainda mais. Isso resultará em uma proliferação de diferentes sintaxes que eu vejo como em conflito com o objetivo da simplicidade. Minha opinião é que a simplicidade não é simples, tem que ser o mais simples, mas ainda oferecer o poder expressivo necessário. Atualmente, vejo que a principal limitação do Go no poder expressivo genérico é a falta de interfaces multiparâmetros. Por exemplo, uma interface de coleção pode ser definida como:

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Então isso faz sentido certo? Gostaríamos de escrever interfaces sobre coisas como coleções. Então a questão é como você usa essa interface em uma função. Minha sugestão seria algo como:

func[T, U] f(c T, e U) (Bool, T) requires Collection[T, U] {
   a := member(c, e)
   d := insert(c, e)
   return a, d
}

A sintaxe é apenas uma sugestão, no entanto, eu realmente não me importo com a sintaxe, desde que você possa expressar esses conceitos na linguagem.

@keean Não seria preciso se eu dissesse que não me importo com a sintaxe. Mas o ponto era a ênfase em ter um tipo padrão para cada parâmetro genérico. Nesse sentido, o exemplo fornecido para interface se tornará:

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Agora a parte (T interface{}, U interface{}) ajuda na definição de restrições. Por exemplo, se os membros devem satisfazer fmt.Stringer , a definição seria:

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@dc0d Isso seria novamente restritivo no sentido de que você deseja restringir por mais de um parâmetro de tipo, considere:

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

Acho que vejo de onde você está vindo com o posicionamento do parâmetro, você poderia ter:

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

Como eu disse, não sou muito preocupado com a sintaxe, pois posso me acostumar com a maioria das sintaxes. Pelo exposto, presumo que você prefira os parênteses '()' para interfaces multiparâmetros.

@keean Vamos considerar a interface heap.Interface . A definição atual na biblioteca padrão é:

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

Agora vamos reescrevê-lo como uma interface genérica, empregando o tipo padrão:

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

Isso não quebra nenhuma série de código Go 1.x por aí. Uma implementação seria minha proposta para Type Alias ​​Rebinding. Mas tenho certeza de que pode haver implementações melhores.

Ter tipos padrão nos permite escrever código genérico que pode ser usado com código de estilo Go 1.x. E a biblioteca padrão pode se tornar genérica, sem quebrar nada. Isso é grande vitória IMO.

@dc0d então você está sugerindo uma melhoria incremental? O que você está sugerindo parece bom para mim como uma melhoria incremental, mas ainda tem um poder expressivo genérico limitado. Como você implementaria as interfaces "Collection" e "OrderedCollection"?

Considere que várias extensões parciais de linguagem podem levar a um produto final mais complexo (com várias sintaxes alternativas) do que implementar a solução completa da maneira mais simples possível.

@keean Eu não entendo a parte requires Collection[T, U], Ord[U] . Como eles estão restringindo os parâmetros de tipo T e U ?

@dc0d Eles funcionam da mesma maneira que em uma função, mas se aplicam a tudo. Portanto, para qualquer par de tipos TU que seja uma OrderedCollection, exigimos que TU também seja uma instância de Collection e que U seja Ord. Portanto, em qualquer lugar que usamos OrderedCollection, podemos usar métodos de Collection e Ord conforme apropriado.

Se formos minimalistas, isso não é obrigatório, pois podemos incluir as interfaces extras nos tipos de função onde precisamos, por exemplo:

type OrderedCollection interface(T, U)
{
   first(c T) U
}

func[T] first(c T[]) T requires Collection(T[], T), Ord T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T), Collection(T[], T), Ord(T)
{...}

Mas isso pode ser mais legível:

type OrderedCollection interface(T, U) 
   requires Collection(T, U), Ord(U)
{
   first(c T) U
}

func[T] first(c T[]) T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T)
{...}

@keean (IMO) Enquanto houver um valor padrão obrigatório para os parâmetros de tipo, me sinto feliz. Dessa forma, é possível manter a compatibilidade retroativa com a série de códigos Go 1.x. Esse é o ponto principal que tentei fazer.

@keean

As interfaces Go não são classes de tipos — são apenas tipos

Eles não se comportam como tipos para mim, pois permitem polimorfismo.

Sim, eles permitem polimorfismo de subtipo . Go tem subtipagem por meio de tipos de interface. Ele não possui hierarquias de subtipo explicitamente declaradas, mas isso é amplamente ortogonal. O que faz com que Go não seja totalmente orientado a objetos é a falta de herança.

Alternativamente, você pode ver as interfaces como aplicações existencialmente quantificadas de classes de tipo. Acredito que seja isso que você tem em mente. Foi o que fizemos em Genus e Familia.

@andrewcmyers

Sim, eles permitem polimorfismo de subtipo.

Vá até onde eu sei que é invariável, não há covariância ou contravariância, isso fala fortemente que isso não é subtipagem. Sistemas de tipo polimórfico são invariáveis, então para mim parece que Go está mais próximo desse modelo, e tratar interfaces como classes de tipo de parâmetro único parece mais de acordo com a simplicidade de Go. A falta de covariância e contravariância é um grande benefício para os genéricos, basta olhar para a confusão que essas coisas criam em linguagens como C#:

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

Acho que Go deve evitar totalmente esse tipo de complexidade. Para mim, isso significa que não queremos genéricos e subtipagem no mesmo sistema de tipos.

Alternativamente, você pode ver as interfaces como aplicações existencialmente quantificadas de classes de tipo. Acredito que seja isso que você tem em mente. Foi o que fizemos em Genus e Familia.

Como Go possui informações de tipo em tempo de execução, não há necessidade de quantificação existencial. Em Haskell, os tipos são unboxed (como os tipos 'C' nativos) e isso significa que uma vez que colocamos algo em uma coleção existencial, não podemos (facilmente) recuperar o tipo do conteúdo, tudo o que podemos fazer é usar as interfaces fornecidas (classes de tipo ). Isso é implementado armazenando um ponteiro para as interfaces junto com os dados brutos. Em Go, o tipo de dados é armazenado, os dados são 'Boxed' (como em C# boxed e unboxed data). Como tal Go não se limita apenas às interfaces armazenadas com os dados, pois é possível (pelo uso de um type-case) recuperar o tipo dos dados na coleção, o que só é possível em Haskell implementando um 'Reflection' typeclass (embora seja difícil obter os dados, é possível serializar o tipo e os dados, para dizer strings, e depois desserializar fora da caixa existencial). Portanto, a conclusão que tenho é que as interfaces Go se comportam exatamente como as classes de tipo, se Haskell fornecesse a classe de tipo 'Reflection' como incorporada. Como tal, não há caixa existencial, e ainda podemos digitar o conteúdo das coleções, mas as interfaces se comportam exatamente como as classes de tipos. A diferença entre Haskell e Go está na semântica de dados encaixotados versus não encaixotados, e as interfaces são classes de tipo de parâmetro único. Com efeito, quando 'Go' trata uma interface como um tipo, o que está realmente fazendo é:

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

Provavelmente vale a pena notar que esta é a mesma maneira que "Trait Objects" funcionam em Rust.

Go pode evitar totalmente existenciais (sendo visível para o programador), covariância e contravariância, o que é uma coisa boa, e isso tornará os genéricos muito mais simples e poderosos na minha opinião.

Vá até onde eu sei que é invariável, não há covariância ou contravariância, isso fala fortemente que isso não é subtipagem.

Sistemas de tipo polimórfico são invariáveis, então para mim parece mais próximo a este modelo, e tratar interfaces como classes de tipo de parâmetro único parece mais de acordo com a simplicidade do Go.

Posso sugerir que ambos estão corretos? Em que as interfaces são equivalentes às classes de tipo, mas as classes de tipo são uma forma de subtipagem. As definições de subtipagem que encontrei até agora são bastante vagas e imprecisas e se resumem a "A é um subtipo de B, se um pode ser substituído pelo outro". Que, IMO, pode ser facilmente argumentado para ser satisfeito por classes de tipo .

Observe que o argumento de variação em si não está realmente funcionando IMO. A variação é uma propriedade de construtores de tipos, não uma linguagem. E é bastante normal que nem todos os construtores de tipo em uma linguagem sejam variantes (por exemplo, muitas linguagens com subtipagem têm matrizes mutáveis, que precisam ser invariantes para serem seguras para o tipo). Portanto, não vejo por que você não poderia ter subtipagem sem construtores de tipo variante.

Além disso, acredito que essa discussão é um pouco ampla demais para um problema no repositório Go. Não se trata de discutir os meandros das teorias de tipos, mas sobre se e como adicionar genéricos ao Go.

@Merovius Variance é uma propriedade associada à subtipagem. Em idiomas sem subtipagem, não há variação. Para que haja variação em primeiro lugar, você precisa ter subtipagem, que introduz o problema de covariância/contravariância aos construtores de tipo. Você está certo, porém, que em uma linguagem com subtipagem, é possível ter todos os construtores de tipo invariáveis.

Classes de tipo definitivamente não são subtipagem, porque uma classe de tipo não é um tipo. No entanto, podemos ver 'tipos de interface' em Go como o que Rust chama de 'objeto de traço' efetivamente um tipo derivado da classe de tipos.

A semântica de Go parece se encaixar em qualquer modelo no momento, porque não tem variação e tem 'objetos de traço' implícitos. Então, talvez Go esteja em um ponto de inflexão, genéricos e o sistema de tipos possam ser desenvolvidos ao longo das linhas de subtipagem, introduzindo variação e terminando com algo como genéricos em C#. Alternativamente, o Go poderia introduzir interfaces multiparâmetros, permitindo interfaces para coleções, e isso quebraria o vínculo imediato entre interfaces e 'tipos de interface'. Por exemplo, se você tiver:

type (T, U) Collection interface {
    member : (c T, e U) Bool
    insert: (c T, e U) T
}

member(c int32[], e int32) Bool {...}
insert(c int32[], e int32) int32[] {...}

member(c float32[], e float32) Bool {...}
insert(c float32[], e float32) float32[] {...}

Não há mais uma relação de subtipo óbvia entre os tipos T, U e a interface Collection. Portanto, você só pode visualizar a relação entre o tipo de instância e os tipos de interface como subtipagem para o caso especial de interfaces de parâmetro único, e não podemos expressar abstrações de coisas como coleções com interfaces de parâmetro único.

Eu acho que para genéricos você claramente precisa ser capaz de modelar coisas como coleções, então interfaces multiparâmetros são obrigatórias para mim. No entanto, acho que a interação entre covariância e contravariância em genéricos cria um sistema de tipos excessivamente complexo, portanto, gostaria de evitar a subtipagem.

@keean Como as interfaces podem ser usadas como tipos e as classes de tipos não são tipos, a explicação mais natural da semântica Go é que as interfaces não são classes de tipos. Eu entendo que você está argumentando para generalizar interfaces como classes de tipo; Acho que é uma direção razoável para seguir a linguagem e, de fato, já exploramos essa abordagem extensivamente em nosso trabalho publicado.

Para saber se Go tem subtipagem, considere o seguinte código:

package main

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = x

func main() {
    print("ok\n")
}

A atribuição de x a y demonstra que o tipo de y pode ser usado onde o tipo de x é esperado. Esta é uma relação de subtipagem, a saber: CloneableZ <: Cloneable , e também S <: CloneableZ . Mesmo se você explicasse as interfaces em termos de classes de tipo, ainda haveria um relacionamento de subtipagem em jogo aqui, algo como S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] .

Observe que seria perfeitamente seguro para Go permitir que a função Clone retornasse um S , mas Go impõe regras desnecessariamente restritivas para conformidade com interfaces: na verdade, as mesmas regras que Java originalmente imposta. A subtipagem não requer construtores de tipo não invariáveis, como observou o @Merovius .

@andrewcmyers O que acontece com interfaces multiparâmetros, como aquelas necessárias para abstrair coleções?

Além disso, a atribuição de x para y pode ser vista como uma demonstração de herança de interface sem subtipagem. Em Haskell (que claramente não tem subtipagem) você escreveria:

class Cloneable t => CloneableZ t where...

Onde temos x é um tipo que implementa CloneableZ que por definição também implementa Cloneable , então obviamente pode ser atribuído a y .

Para tentar resumir, você pode visualizar uma interface como um tipo e Go para ter subtipagem limitada sem construtores de tipo covariante ou contravariante, ou você pode vê-la como um "objeto de traço", ou talvez em Go nós o chamaríamos de " objeto de interface", que é efetivamente um contêiner polimórfico restrito por uma interface "typeclass". No modelo typeclass não há subtipagem e, portanto, não há razão para pensar em covariância e contravariância.

Se ficarmos com o modelo de subtipagem, não podemos ter tipos de coleção, é por isso que C++ teve que introduzir templates, porque a subtipagem orientada a objetos não é suficiente para definir genericamente conceitos como contêineres. Acabamos com dois mecanismos para abstração, objetos e subtipagem, e templates/traits e genéricos, e as interações entre os dois ficam complexas, veja C++, C# e Scala para exemplos. Haverá chamadas contínuas para introduzir construtores covariantes e contravariantes para aumentar o poder dos genéricos, de acordo com essas outras linguagens.

Se queremos coleções genéricas sem introduzir um sistema genérico separado, devemos pensar em interfaces como classes de tipos. Interfaces multiparâmetros significariam não pensar mais em subtipagem e, em vez disso, pensar em herança de interface. Se queremos melhorar os genéricos em Go e permitir abstrações de coisas como coleções, e não queremos a complexidade dos sistemas de tipos de linguagens como C++, C#, Scala etc, então interfaces multiparâmetros e herança de interface são o caminho. ir.

@keean

O que acontece com interfaces multiparâmetros, como aquelas necessárias para abstrair coleções?

Por favor, veja nossos artigos sobre Gênero e Família, que suportam restrições de tipo multiparâmetro. O Familia unifica essas restrições com interfaces e permite que interfaces restrinjam vários tipos.

Se ficarmos com o modelo de subtipagem, não podemos ter tipos de coleção

Não tenho certeza do que você quer dizer com "o modelo de subtipagem", mas está bem claro que Java e C# têm tipos de coleção, então essa afirmação não faz muito sentido para mim.

Onde temos x é um tipo que implementa CloneableZ que por definição também implementa Cloneable, então obviamente pode ser atribuído a y.

Não, no meu exemplo, x é uma variável e y é outra variável. Se eu sei que y é algum tipo CloneableZ e x é algum tipo Cloneable , isso não significa que eu possa atribuir de y a x. É isso que meu exemplo está fazendo.

Para esclarecer que a subtipagem é necessária para modelar Go, abaixo está uma versão aprimorada do exemplo cujo equivalente moral não verifica o tipo em Haskell. O exemplo mostra que a subtipagem permite a criação de coleções heterogêneas nas quais diferentes elementos possuem diferentes implementações. Além disso, o conjunto de implementações possíveis é aberto.

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

type T struct { x int }

func (t T) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = T{}
var a [2]Cloneable = [2]Cloneable{x, y}

@andrewcmyers

Não tenho certeza do que você quer dizer com "o modelo de subtipagem", mas está bem claro que Java e C# têm tipos de coleção, então essa afirmação não faz muito sentido para mim.

Veja por que o C++ desenvolveu templates, o modelo de subtipagem OO não era capaz de expressar os conceitos genéricos necessários para generalizar coisas como coleções. C# e Java também tiveram que introduzir um sistema genérico completo separado de objetos, subtipagem e herança, e então tiveram que limpar a bagunça das interações complexas dos dois sistemas com coisas como construtores de tipo covariante e contravariante. Com o benefício da retrospectiva, podemos evitar a subtipagem OO e, em vez disso, observar o que acontece se adicionarmos interfaces (classes de tipo) a uma linguagem simplesmente tipada. Isso é o que Rust fez, então vale a pena dar uma olhada, mas é claro que é complicado por toda a vida. Go tem GC então não teria essa complexidade. Minha sugestão é que Go possa ser estendido para permitir interfaces multiparâmetros e evitar essa complexidade.

Em relação à sua alegação de que você não pode fazer este exemplo em Haskell, aqui está o código:

{-# LANGUAGE ExistentialQuantification #-}

class ICloneable t where
    clone :: t -> t

class ICloneable t => ICloneableZ t where
    zero :: t

data S = S deriving Show

instance ICloneable S where
    clone x = x

data T = T Int deriving Show

instance ICloneable T where
    clone x = x

instance ICloneableZ T where
    zero = T 0

data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a

instance Show Cloneable where
    show (ToCloneable x) = show x

main = do
    x <- return S
    y <- return (T 27)
    a <- return [ToCloneable x, ToCloneable y]
    putStrLn (show a)

Algumas diferenças interessantes, Go deriva automaticamente este tipo data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a pois é assim que você transforma uma interface (que não tem armazenamento) em um tipo (que tem armazenamento), Rust também deriva esses tipos e os chama de "objetos de traço" . Em outras linguagens como Java, C# e Scala, descobrimos que você não pode instanciar interfaces, o que na verdade é "correto", interfaces não são tipos, elas não têm armazenamento, Go está derivando o tipo de um contêiner existencial automaticamente para você, para que você possa tratar a interface como um tipo, e Go esconde isso de você dando ao contêiner existencial o mesmo nome da interface da qual é derivado. A outra coisa a notar é que este [2]Cloneable{x, y} coage todos os membros a Cloneable , enquanto Haskell não tem tais coerções implícitas, e temos que coagir explicitamente os membros com ToCloneable .

Também me foi dito que não devemos considerar os subtipos S e T de Cloneable porque S e T não são estruturalmente compatível. Podemos literalmente declarar qualquer tipo uma instância de Cloneable (apenas declarando a definição relevante da função clone em Go) e esses tipos não precisam ter nenhuma relação entre si.

A maioria das propostas para Genéricos parecem incluir tokens adicionais que acho que prejudicam a legibilidade e a sensação simples de Go. Eu gostaria de propor uma sintaxe diferente que eu acho que poderia funcionar bem com a gramática existente do Go (até acontece de destacar a sintaxe muito bem no Github Markdown).

Os principais pontos da proposta:

• A gramática de Go parece sempre ter uma maneira fácil de determinar quando uma declaração de tipo terminou porque há algum token ou palavra-chave específica que estamos procurando. Se isso for verdade em todos os casos, argumentos de tipo podem simplesmente ser adicionados seguindo os próprios nomes de tipo.
• Como a maioria das propostas, o mesmo identificador significa o mesmo tipo em qualquer declaração de função. Esses identificadores nunca escapam da declaração.
• Na maioria das propostas, você precisa declarar argumentos de tipo genérico, mas nesta proposta está implícito. Algumas pessoas alegam que isso prejudica a legibilidade ou a clareza (a implícita é ruim) ou restringe a capacidade de nomear um tipo, as refutações seguem:
  
  
  
  • Quando se trata de prejudicar a legibilidade, acho que você pode argumentar de qualquer maneira, o extraou [T] prejudica a legibilidade ao fazer muito ruído sintático.
  
  
  • A implícita, quando usada corretamente, pode ajudar uma linguagem a ser menos detalhada. Eliminamos declarações de tipo com := o tempo todo porque a informação oculta por isso simplesmente não é importante o suficiente para ser explicada a cada vez.
  
  
  • Nomear um tipo concreto (não genérico) a ou t provavelmente é uma prática ruim, portanto, esta proposta pressupõe que é seguro reservar esses identificadores para atuar como argumentos de tipo genérico. Embora isso exigiria uma migração de correção, talvez?
  
  

package main

import "fmt"

type LinkedList a struct {
  Head *Node a
  Tail *Node a
}

type Node a {
  Next *Node a
  Prev *Node a

  Value a
}

func main() {
  // Not sure about how recursive we could get with the inference
  ll := LinkedList string {
    // The string bit could be inferred
    Head: Node string { Value: "hello world" },
  }
}

func (l *LinkedList a) Append(value a) {
  newNode := &Node{Value: value}

  if l.Tail == nil {
    l.Head = newNode
    l.Tail = l.Head
    return
  }

  l.Tail.Next = newNode
  l.Tail = l.Tail.Next
}

Isso é retirado de um Gist que tem um pouco mais de detalhes, bem como tipos de soma propostos aqui: https://gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

Esta não é uma proposta de genéricos totalmente liberada e não é para ser, há muitos problemas a serem resolvidos para poder adicionar genéricos ao Go. Este aborda apenas a sintaxe, e espero que possamos conversar sobre se o que é proposto é viável / desejável ou não.

@aarondl
Parece bom para mim, usando esta sintaxe, teríamos:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

@keean Você poderia explicar um pouco o tipo Collection . não consigo entender:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@dc0d Collection é uma interface que abstrai _all_ coleções, ou seja, árvores, listas, slices etc, para que possamos ter operações genéricas como member e insert que funcionarão em qualquer coleção contendo qualquer tipo de dado. No exemplo acima dei o exemplo de definição de 'inserir' para o tipo LinkedList no exemplo anterior:

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

Também poderíamos defini-lo para uma fatia

func insert(c []a, e a) []a {
   return append(c, e)
}

No entanto, nem precisamos do tipo de funções paramétricas com variáveis ​​de tipo como ilustrado por @aarondl com tipo polimórfico a para que isso funcione, pois você pode apenas definir para tipos concretos:

func insert(c *LinkedList int, e int) *LinkedList int {
   c.Append(e)
   return c
}

func insert(c *LinkedList float, e float) *LinkedList float {
   c.Append(e)
   return c
}

func insert(c int[], e int) int[] {
   return append(c, e)
}

func insert(c float[], e float) float[] {
   return append(c, e)
}

Portanto Collection é uma interface para generalizar tanto o tipo de um contêiner quanto o tipo de seu conteúdo, permitindo escrever funções genéricas que operam em todas as combinações de contêiner e conteúdo.

Não há razão para que você também não possa ter uma fatia de coleções []Collection onde o conteúdo seria todo de diferentes tipos de coleção com diferentes tipos de valores, desde que member e insert fossem definidos para cada combinação .

@aarondl Dado que type LinkedList a já é uma declaração de tipo válida, só posso ver duas maneiras de torná-la analisável de forma inequívoca: Tornando a gramática sensível ao contexto (entrando nos problemas de analisar C, ugh) ou usando lookahead ilimitado ( que a gramática go tende a evitar, por causa de mensagens de erro ruins no caso de falha). Eu posso estar entendendo mal alguma coisa, mas IMO que fala contra uma abordagem sem token.

@keean Interfaces em Go usam métodos, não funções. Na sintaxe específica que você sugeriu, não há nada que anexe insert a *LinkedList para o compilador (em Haskell isso é feito por meio de declarações instance ). Também é normal que os métodos alterem o valor em que estão operando. Nada disso é um Show-Stopper, apenas apontando que a sintaxe que você está sugerindo não funciona bem com Go. Provavelmente mais algo como

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

O que também demonstra mais algumas perguntas sobre como os parâmetros de tipo são definidos e como isso deve ser analisado.

@aarondl também tenho mais perguntas sobre sua proposta. Por exemplo, ele não permite restrições, então você só obtém polimorfismo irrestrito. O que, em geral, não é tão útil, pois você não tem permissão para fazer nada com os valores que está recebendo (por exemplo, você não pode implementar Collection com um mapa, pois nem todos os tipos são chaves de mapa válidas). O que deve acontecer quando alguém tenta fazer algo assim? Se for um erro em tempo de compilação, ele reclama da instanciação (mensagens de erro C++ adiante) ou da definição (não dá pra fazer basicamente nada, porque não há nada que funcione com todos os tipos)?

@keean Ainda não consigo entender como a está restrito a ser uma lista (ou fatia ou qualquer outra coleção). Esta é uma gramática especial dependente do contexto para coleções? Se sim qual o valor dela? Não é possível declarar tipos definidos pelo usuário dessa maneira.

@Merovius Isso significa que o Go não pode fazer despacho múltiplo e torna o primeiro argumento de uma 'função' especial? Isso sugere que os tipos associados seriam mais adequados do que as interfaces de vários parâmetros. Algo assim:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt(c Collection, e Collection.Element) {...}

No entanto, isso ainda tem problemas porque não há nada que restrinja as duas coleções a serem do mesmo tipo... Você acabaria precisando de algo como:

func[A] useIt(c A, e A.Element) requires A:Collection

Para tentar explicar a diferença, as interfaces multiparâmetros têm tipos _input_ extras que participam da seleção de instâncias (daí a conexão com despacho múltiplo), enquanto os tipos associados são tipos _output_, apenas o tipo receptor participa da seleção de instâncias e, em seguida, os tipos associados dependem do tipo do receptor.

@dc0d a e b são parâmetros de tipo da interface, assim como em uma classe de tipo Haskell. Para algo ser considerado um Collection tem que definir os métodos que correspondem aos tipos na interface onde a e b podem ser de qualquer tipo. No entanto, como o @Merovius apontou, as interfaces Go são baseadas em métodos e não suportam despacho múltiplo, portanto, interfaces com vários parâmetros podem não ser uma boa opção. Com o modelo de método de despacho único do Go, ter tipos associados em interfaces, em vez de parâmetros múltiplos, parece ser um ajuste melhor. No entanto, a falta de despacho múltiplo torna a implementação de funções como unify(x, y) difícil, e você tem que usar o padrão de despacho duplo que não é muito bom.

Para explicar um pouco mais a questão dos multiparâmetros:

type Cloneable[A] interface {
   clone(x A) A
}

Aqui a significa qualquer tipo, não importa o que seja, desde que as funções corretas sejam definidas, consideramos Cloneable . Consideraríamos as interfaces como restrições de tipos em vez de tipos em si.

func clone(x int) int {...}

então no caso de 'clone' nós substituímos a por int na definição da interface, e podemos chamar clone se a substituição for bem sucedida. Isso se encaixa muito bem com esta notação:

func[A] test(x A) A requires Cloneable[A] {...}

Isso é equivalente a:

type Cloneable interface {
   clone() Cloneable
}

mas declara uma função, não um método, e pode ser estendido com vários parâmetros. Se você tem uma linguagem com despacho múltiplo, não há nada de especial sobre o primeiro argumento de uma função/método, então por que escrevê-lo em um lugar diferente.

Como o Go não tem despacho múltiplo, tudo isso começa a parecer muito para mudar de uma só vez. Parece que os tipos associados seriam mais adequados, embora mais limitados. Isso permitiria coleções abstratas, mas não soluções elegantes para coisas como unificação.

@Merovius Obrigado por dar uma olhada na proposta. Deixe-me tentar resolver suas preocupações. Estou triste que você tenha rejeitado a proposta antes de discutirmos mais, espero poder mudar sua mente - ou talvez você possa mudar a minha :)

Antecipação ilimitada:
Então, como mencionei na proposta, atualmente parece que a gramática Go tem uma boa maneira de detectar o "fim" de praticamente tudo sintaticamente. E ainda o faríamos por causa dos argumentos genéricos implícitos. Letras minúsculas sendo a construção sintática que cria esse argumento genérico - ou o que quer que decidamos fazer esse token embutido, talvez até voltemos para uma coisa tokenizada como @a na proposta se gostarmos da sintaxe o suficiente, mas não é possível dada a dificuldade do compilador sem tokens, embora a proposta perca muito charme assim que você fizer isso.

Independentemente do problema com type LinkedList a nesta proposta não é tão difícil porque sabemos que a é um argumento de tipo genérico e, portanto, isso falharia com um erro de compilador igual a type LinkedList falha hoje com: prog.go:3:16: expected type, found newline (and 1 more errors) . O post original realmente não saiu e disse isso, mas você não tem mais permissão para nomear um tipo concreto [a-z]{1} que eu acho que resolve esse problema e é um sacrifício com o qual todos ficaríamos bem fazendo (só posso ver prejuízos na criação de tipos reais com nomes de letra única no código Go hoje).

É apenas polimorfismo irrestrito
A razão pela qual eu omiti qualquer tipo de traços ou restrições de argumentos genéricos é porque sinto que esse é o papel das interfaces em Go, se você quiser fazer algo com um valor, esse valor deve ser um tipo de interface e não um tipo totalmente genérico. Acho que essa proposta também funciona bem com interfaces.

Sob esta proposta, ainda teríamos o mesmo problema que temos agora com operadores como + então você não poderia fazer uma função add genérica para todos os tipos numéricos, mas você poderia aceitar uma função add genérica como um argumento. Considere o seguinte:

func Sort(slice []a, compare func (a, a) bool) { ... }

Dúvidas sobre escopo

Você deu um exemplo aqui:

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

O escopo desses identificadores como regra está vinculado à declaração/definição específica em que eles estão. Eles não são compartilhados em nenhum lugar e não estou vendo uma razão para eles serem.

@keean Isso é muito interessante, embora, como outros apontaram, você teria que alterar o que mostrou lá para realmente poder implementar as interfaces (atualmente, no seu exemplo, não há métodos com receptores, apenas funções). Tentando pensar mais sobre como isso afeta minha proposta original.

Letras minúsculas sendo a construção sintática que cria esse argumento genérico

Não me sinto bem com isso; requer ter produções separadas para o que é um identificador dependendo do contexto e também significa proibir arbitrariamente certos identificadores para tipos. Mas não é realmente o momento de falar sobre esses detalhes.

Sob esta proposta, ainda teríamos o mesmo problema que temos agora com operadores como +

Eu não entendo essa frase. Atualmente, o operador + não tem nenhum desses problemas, pois os tipos de seus operandos são conhecidos localmente e a mensagem de erro é clara e inequívoca e aponta para a origem do problema. Estou correto em supor que você está dizendo que deseja proibir qualquer uso de valores genéricos que não seja permitido para todos os tipos possíveis (não consigo pensar em muitas dessas operações)? E criar um erro de compilador para a expressão incorreta na função genérica? IMO que limitaria muito o valor dos genéricos.

se você quiser fazer algo com um valor, esse valor deve ser um tipo de interface e não um tipo totalmente genérico.

As duas principais razões pelas quais as pessoas querem genéricos são desempenho (evitar encapsulamento de interfaces) e segurança de tipo (certificando-se de que o mesmo tipo seja usado em lugares diferentes, sem se importar com qual é). Isso parece ignorar essas razões.

você pode aceitar uma função add genérica como um argumento.

Verdadeiro. Mas bem pouco ergonômico. Considere quantas reclamações existem sobre a API sort . Para muitos contêineres genéricos, a quantidade de funções que o chamador teria que implementar e passar parece ser proibitiva. Considere, como seria uma implementação container/heap sob esta proposta e como seria melhor do que a implementação atual, em termos de ergonomia? Parece que as vitórias são insignificantes aqui, na melhor das hipóteses. Você teria que implementar funções mais triviais (e duplicar para/referência em cada site de uso), não menos.

@Merovius

pensando nesse ponto do @aarondl

você pode aceitar uma função add genérica como um argumento.

Seria melhor ter uma interface Addable para permitir a sobrecarga de adição, dada alguma sintaxe para definir operadores infixos:

type Addable interface {
   + (x Addable, y Addable) Addable
}

Infelizmente, isso não funciona, porque não expressa que esperamos que todos os tipos sejam iguais. Para definir addable, precisaríamos de algo como as interfaces multiparâmetros:

type Addable[A] interface {
   + (x A, y A) A
}

Então você também precisaria de Go para fazer despacho múltiplo, o que significaria que todos os argumentos em uma função são tratados como um receptor para correspondência de interface. Portanto, no exemplo acima, qualquer tipo é Addable se houver uma função + definida nele que satisfaça as definições de função na definição da interface.

Mas, dadas essas alterações, agora você pode escrever:

type S struct {
   value: int
}

func (+) (x S, y S) S {
   return S {
      value: x.value + y.value
   }
}

func main() {
    println(S {value: 27} + S {value: 5})
}

É claro que a sobrecarga de funções e o despacho múltiplo podem ser algo que as pessoas nunca querem em Go, mas coisas como definir aritmética básica em tipos definidos pelo usuário, como vetores, matrizes, números complexos etc., sempre serão impossíveis. Como eu disse acima, 'tipos associados' em interfaces permitiriam algum aumento na capacidade de programação genérica, mas não generalidade total. O despacho múltiplo (e presumivelmente sobrecarga de funções) é algo que poderia acontecer em Go?

coisas como definir aritmética básica em tipos definidos pelo usuário como vetores, matrizes, números complexos etc, sempre serão impossíveis.

Alguns podem considerar isso um recurso :) AFAIR há alguma proposta ou tópico circulando em algum lugar discutindo se deveria. FWIW, eu acho que isso é - novamente - vagando fora do tópico. Sobrecarga de operador (ou ideias gerais de "como tornar o Go mais Haskell") não é realmente o ponto deste problema :)

O despacho múltiplo (e presumivelmente sobrecarga de funções) é algo que poderia acontecer em Go?

Nunca diga nunca. Eu não esperaria isso, porém, pessoalmente.

@Merovius

Alguns podem considerar isso um recurso :)

Claro, e se Go não fizer isso, existem outras linguagens que o farão :-) Go não precisa ser tudo para todos. Eu estava apenas tentando estabelecer algum escopo para genéricos em Go. Meu foco é criar linguagens totalmente genéricas, pois tenho aversão a me repetir e clichê (e não gosto de macros). Se eu ganhasse um centavo para cada vez que tivesse que escrever uma lista encadeada ou uma árvore em 'C' para algum tipo de dado específico. Na verdade, torna alguns projetos impossíveis para uma equipe pequena por causa do volume de código que precisa ser mantido em sua cabeça para entendê-lo e, em seguida, mantido por meio de alterações. Às vezes acho que as pessoas que não entendem a necessidade de genéricos ainda não escreveram um programa grande o suficiente. É claro que você pode ter uma grande equipe de desenvolvedores trabalhando em algo e apenas ter cada desenvolvedor responsável por uma pequena parte do código total, mas estou interessado em tornar um único desenvolvedor (ou equipe pequena) o mais eficaz possível.

Dado que a sobrecarga de função e o despacho múltiplo estão fora do escopo, e também dados os problemas de análise com a sugestão de @aarondl , parece que adicionar tipos associados a interfaces e parâmetros de tipo a funções seria o máximo que você gostaria ir com genéricos em Go.

Algo assim parece ser o tipo certo de coisa:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt<T>(c T, e T.Element) requires T:Collection {...}

Em seguida, haveria uma decisão na implementação de usar tipos paramétricos ou tipos quantificados universalmente. Com tipos paramétricos (como Java), uma função 'genérica' não é realmente uma função, mas algum tipo de modelo de função de tipo seguro e, como tal, não pode ser passado como um argumento, a menos que tenha seu parâmetro de tipo fornecido:

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

Com tipos quantificados universalmente, você pode passar useIt como um argumento e, em seguida, pode ser fornecido com um parâmetro de tipo dentro f . A razão para favorecer os tipos paramétricos é porque você pode monomorfizar o polimorfismo em tempo de compilação, o que significa que não há elaboração de funções polimórficas em tempo de execução. Não tenho certeza se isso é uma preocupação com Go, porque Go já está fazendo despacho em tempo de execução em interfaces, portanto, desde que o parâmetro de tipo para useIt implemente Coleção, você pode despachar para o receptor correto em tempo de execução, tão universal a quantificação é provavelmente o caminho certo para o Go.

Eu me pergunto, SFINAE mencionado apenas por @bcmills. Nem sequer mencionado na proposta (embora Sort esteja lá como exemplo).
Como seria o Sort para slice e linkedlist?

@keean
Não consigo descobrir como alguém definiria uma coleção genérica 'Slice' com sua sugestão. Você parece estar definindo um 'IntSlice' que pode estar implementando 'Collection' (embora Insert retorne um tipo diferente do desejado pela interface), mas isso não é um 'slice' genérico, pois parece ser apenas para ints , e as implementações de método são apenas para ints. Precisamos definir implementação específica por tipo?

Às vezes acho que as pessoas que não entendem a necessidade de genéricos ainda não escreveram um programa grande o suficiente.

Posso assegurar-lhe que a impressão é falsa. E FWIW, ISTM que "o outro lado" está colocando "não vendo a necessidade" no mesmo balde que "não vendo o uso". Eu vejo o uso e não refuto. Eu realmente não vejo a necessidade , no entanto. Estou indo bem sem, mesmo em grandes bases de código.

E não confunda "querer que sejam bem feitas e apontar onde as propostas existentes não estão" com "opor-se fundamentalmente à própria ideia".

também devido aos problemas de análise com a sugestão de @aarondl .

Como eu disse, não acho que falar sobre o problema de análise seja realmente produtivo agora. Problemas de análise podem ser resolvidos. A falha do polimorfismo restrito é muito mais séria, semanticamente. IMO, adicionar genéricos sem isso simplesmente não vale o esforço.

@urandom

Não consigo descobrir como alguém definiria uma coleção genérica 'Slice' com sua sugestão.

Como dado acima, você ainda precisaria definir uma implementação separada para cada tipo de fatia, mas ainda ganharia com a capacidade de escrever algoritmos em termos de interface genérica. Se você quiser permitir uma implementação genérica para todas as fatias, precisará permitir tipos e métodos associados paramétricos. Observe que movi o parâmetro type para depois da palavra-chave para que ocorra antes do tipo do receptor.

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

No entanto, agora você também precisa lidar com a especialização, porque alguém poderia definir o tipo e os métodos associados para o []int mais especializado e você teria que lidar com qual deles usar. Normalmente você usaria a instância mais específica, mas adiciona outra camada de complexidade.

Não tenho certeza de quanto isso realmente ganha você. Com meu exemplo original acima, você pode escrever algoritmos genéricos para atuar em coleções gerais usando a interface, e você só precisa fornecer os métodos e tipos associados para os tipos que você realmente usa. A grande vitória para mim é poder definir algoritmos como classificar em coleções arbitrárias e colocar esses algoritmos em uma biblioteca. Se eu tiver uma lista de "formas", só preciso definir os métodos de interface de coleção para minha lista de formas e posso usar qualquer algoritmo na biblioteca sobre elas. Ser capaz de definir os métodos de interface para todos os tipos de fatias é de menos interesse para mim e pode ser muita complexidade para o Go?

@Merovius

Eu realmente não vejo a necessidade, no entanto. Estou indo bem sem, mesmo em grandes bases de código.

Se você puder lidar com um programa de 100.000 linhas, poderá fazer mais com 100.000 linhas genéricas do que com 100.000 linhas não genéricas (devido à repetição). Portanto, você pode ser um desenvolvedor super-estrela capaz de lidar com bases de código muito grandes, mas ainda conseguiria mais com uma base de código genérica muito grande, pois estaria eliminando a redundância. Esse programa genérico se expandiria para um programa não genérico ainda maior. Parece-me que você ainda não atingiu seu limite de complexidade.

No entanto, acho que você está certo 'necessidade' é muito forte, estou feliz em escrever código go, com apenas uma frustração ocasional sobre a falta de genéricos, e posso contornar isso simplesmente escrevendo mais código, e em Go esse código é completamente direto e literais.

A falta de polimorfismo restrito é muito mais séria, semanticamente. IMO, adicionar genéricos sem isso simplesmente não vale o esforço.

Eu concordo com isto.

você poderá fazer mais com 100.000 linhas genéricas do que com 100.000 linhas não genéricas (devido à repetição)

Estou curioso, do seu exemplo hipotético, qual % dessas linhas seria uma função genérica?
Na minha experiência, isso é menos de 2% (de uma base de código com 115k LOC), então não acho que seja um bom argumento, a menos que você escreva uma biblioteca para "coleções"

Eu gostaria que eventualmente tivéssemos genéricos

@keean

Em relação à sua alegação de que você não pode fazer este exemplo em Haskell, aqui está o código:

Este código não é moralmente equivalente ao código que escrevi. Ele apresenta um novo tipo de wrapper Cloneable além da interface ICloneable. O código Go não precisava de um wrapper; nem outros idiomas que suportam subtipagem.

@andrewcmyers

Este código não é moralmente equivalente ao código que escrevi. Ele apresenta um novo tipo de wrapper Cloneable além da interface ICloneable.

Não é isso que este código faz:

type Cloneable interface {...}

Ele induz um tipo de dados 'Cloneable' derivado da interface. Você não vê o 'ICloneable' porque não tem declarações de instância para interfaces, apenas declara os métodos.

Você pode considerar a subtipagem quando os tipos que implementam uma interface não precisam ser estruturalmente compatíveis?

@keean Eu consideraria Cloneable apenas um tipo, não realmente um "tipo de dados". Em uma linguagem como Java, essencialmente não haveria custo adicional para a abstração Cloneable , porque não haveria wrapper, ao contrário do seu código.

Parece-me limitante e indesejável exigir similaridade estrutural entre os tipos que implementam uma interface, então estou confuso sobre o que você está pensando aqui.

@andrewcmyers
Estou usando tipo e tipo de dados de forma intercambiável. Qualquer tipo que possa conter dados é um tipo de dados.

porque não haveria wrapper, ao contrário do seu código.

Sempre há um wrapper porque os tipos Go são sempre encaixotados, então o wrapper existe em torno de tudo. Haskell precisa que o wrapper seja explícito porque possui tipos sem caixa.

similaridade estrutural entre tipos implementando uma interface, então estou confuso sobre o que você está pensando aqui.

A subtipagem estrutural exige que os tipos sejam 'estruturalmente compatíveis'. Como não há hierarquia de tipos explícita como em uma linguagem OO com herança, a subtipagem não pode ser nominal, portanto deve ser estrutural, se existir.

Eu entendo o que você quer dizer, no entanto, que eu descreveria como considerando uma interface como uma classe base abstrata, não uma interface, com algum tipo de relacionamento de subtipo nominal implícito com qualquer tipo que implemente os métodos necessários.

Na verdade, acho que Go se encaixa nos dois modelos agora, e poderia ir de qualquer maneira a partir daqui, mas sugiro que chamá-lo de interface e não de classe sugere uma maneira de pensar sem subtipagem.

@keean Não entendi seu comentário. Primeiro você me diz que discorda e que eu "ainda não atingi meu limite de complexidade" e então você me diz que concorda (naquele "necessidade" é uma palavra muito forte). Eu também acho que seu argumento é falacioso (você assume que LOC é a principal medida de complexidade e que cada linha de código é igual). Mas acima de tudo, não acho que "quem está escrevendo programas mais complicados" seja realmente uma linha de discussão produtiva. Eu estava apenas tentando esclarecer que o argumento "se você discorda de mim, isso deve significar que você não está trabalhando em problemas tão difíceis ou interessantes" não é convincente e não parece de boa fé. Espero que você possa confiar que as pessoas podem discordar de você sobre a importância desse recurso enquanto são igualmente competentes e fazem coisas igualmente interessantes.

@merovius
Eu estava dizendo que você provavelmente é um programador mais capaz do que eu e, portanto, capaz de trabalhar com mais complexidade. Certamente não acho que você esteja trabalhando em problemas menos interessantes ou menos complexos, e lamento que tenha sido assim. Passei ontem tentando fazer um scanner funcionar, o que foi um problema muito desinteressante.

Posso pensar que os genéricos me ajudam a escrever programas mais complexos com minha capacidade cerebral limitada e também admitir que não "preciso" de genéricos. É uma questão de grau. Ainda posso programar sem genéricos, mas não posso necessariamente escrever software da mesma complexidade.

Espero que isso lhe assegure que estou agindo de boa fé, não tenho nenhuma agenda oculta aqui e, se Go não adotar genéricos, ainda o usarei. Eu tenho uma opinião sobre a melhor forma de fazer genéricos, mas não é a única opinião, só posso falar por experiência própria. Se eu não estiver ajudando, há muitas outras coisas em que posso gastar meu tempo, então apenas diga a palavra, e eu me concentrarei em outro lugar.

@Merovius Obrigado pelo diálogo contínuo.

| As duas principais razões pelas quais as pessoas querem genéricos são desempenho (evitar encapsulamento de interfaces) e segurança de tipo (certificando-se de que o mesmo tipo seja usado em lugares diferentes, sem se importar com qual é). Isso parece ignorar essas razões.

Talvez estejamos olhando para o que propus de maneira muito diferente, já que, da minha perspectiva, faz as duas coisas até onde posso dizer? No exemplo da lista vinculada, não há envolvimento com interfaces e, portanto, deve ter o desempenho como se fosse escrito à mão para um determinado tipo. No lado de segurança de tipo é o mesmo. Existe um contra-exemplo que você pode dar aqui para me ajudar a entender de onde você está vindo?

| Verdadeiro. Mas bem pouco ergonômico. Considere quantas reclamações existem sobre a API de classificação. Para muitos contêineres genéricos, a quantidade de funções que o chamador teria que implementar e passar parece ser proibitiva. Considere, como seria uma implementação de contêiner/heap sob esta proposta e como seria melhor do que a implementação atual, em termos de ergonomia? Parece que as vitórias são insignificantes aqui, na melhor das hipóteses. Você teria que implementar funções mais triviais (e duplicar para/referência em cada site de uso), não menos.

Na verdade, não estou nem um pouco preocupado com isso. Não acredito que a quantidade de funções seja proibitiva, mas definitivamente estou aberto a ver alguns contra-exemplos. Lembre-se de que a API da qual as pessoas reclamaram não era aquela para a qual você precisava fornecer uma função, mas a original aqui: https://golang.org/pkg/sort/#Interface onde você precisava criar um novo tipo que era simplesmente sua fatia + tipo e, em seguida, implemente 3 métodos nele. À luz das reclamações e da dor associada a essa interface, foi criado o seguinte: https://golang.org/pkg/sort/#Slice , eu não tenho nenhum problema com esta API e recuperaríamos as penalidades de desempenho desta sob a proposta que estamos discutindo simplesmente alterando a definição para func Slice(slice []a, less func(a, a) bool) .

Em termos da estrutura de dados container/heap , não importa qual proposta genérica você aceite, que precisa de uma reescrita completa. container/heap assim como o pacote sort está apenas fornecendo algoritmos em cima de sua própria estrutura de dados, mas nenhum pacote possui a estrutura de dados porque, caso contrário, teríamos []interface{} e o custos associados a isso. Presumivelmente, nós os mudaríamos, pois você poderia ter um Heap que possui uma fatia com um tipo concreto graças aos genéricos, e isso é verdade em qualquer uma das propostas que vi aqui (incluindo a minha) .

Estou tentando separar as diferenças em nossas perspectivas sobre o que eu propus. E acho que a raiz do desacordo (além de qualquer preferência pessoal sintaticamente) é que não há restrições sobre os tipos genéricos. Mas ainda estou tentando descobrir o que isso nos traz. Se a resposta é que nada no que diz respeito ao desempenho tem permissão para usar uma interface, então não há muito o que dizer aqui.

Considere a seguinte definição de tabela de hash:

// Hasher turns a key into a hash
type Hasher interface {
  func Hash() []byte
}

type HashTable v struct {
   Keys   []Hasher
   Values []v
}

// Note that the generic arguments must be repeated here and immediately
// understood without reading another line of code, which to me
// is a readability win over the sudden appearance of the K and V which are
// defined elsewhere in the code in the example below. This is of course because
// the tokenized type declarations with constraints are fairly painful in general
// and repeating them everywhere is simply too much.
func (h (*HashTable v)) Insert(key Hasher, value v) { ... }

Estamos dizendo que o []Hasher não é inicial devido a problemas de desempenho/armazenamento e que para ter uma implementação de Genéricos bem-sucedida em Go, devemos absolutamente ter algo como o seguinte?

// Without selecting another proposal I have no idea how the constraint might be defined or implemented so let's just pretend
type [K: Hasher, V] HashTable a struct {
   Keys   []K
   Values []V
}

func (h *HashTable) Insert(key K, value V) { ... }

Espero que você veja de onde estou vindo. Mas é definitivamente possível que eu não entenda as restrições que você deseja impor a determinado código. Talvez haja casos de uso que eu não considerei, independentemente, espero chegar a uma compreensão mais completa de quais são os requisitos e como a proposta está falhando neles.

Talvez estejamos olhando para o que propus de maneira muito diferente, já que, da minha perspectiva, faz as duas coisas até onde posso dizer?

O "isto" na seção que você está citando está se referindo ao uso de interfaces. A questão não é que sua proposta também não, é que sua proposta não permite polimorfismo restrito, o que exclui a maioria dos usos para eles. E a alternativa que você sugeriu para onde interfaces, que também não abordam o caso de uso principal para genéricos (por causa das duas coisas que mencionei).

Por exemplo, sua proposta (como escrita originalmente) não permitia escrever um mapa genérico de qualquer tipo, pois isso exigiria poder pelo menos comparar chaves usando == (que é uma restrição, portanto, implementar um map requer polimorfismo restrito).

À luz das queixas e dores associadas a esta interface foi criado o seguinte: https://golang.org/pkg/sort/#Slice

Observe que essa interface ainda não é possível em sua proposta de genéricos, pois ela depende de reflexão para comprimento e troca (portanto, novamente, você tem uma restrição nas operações de fatia). Mesmo se aceitarmos essa API como o limite inferior do que os genéricos devem ser capazes de realizar (muitas pessoas não aceitariam. Ainda há muitas reclamações sobre a falta de segurança de tipo nessa API), sua proposta não passaria aquela barra.

Mas também, novamente, você está citando uma resposta para um ponto específico que você fez, ou seja, que você pode obter polimorfismo restrito passando literais de função na API. E essa maneira específica que você sugeriu para contornar a falta de polimorfismo restrito exigiria a implementação mais ou menos da API antiga. ou seja, você está citando minha resposta a este argumento, que você está apenas repetindo:

recuperaríamos as penalidades de desempenho disso sob a proposta que estamos discutindo simplesmente alterando a definição para func Slice(slice []a, less func(a, a) bool).

Essa é a API antiga. Você está dizendo "minha proposta não permite polimorfismo restrito, mas isso não é problema, porque simplesmente não podemos usar genéricos e, em vez disso, usar as soluções existentes (reflexão/interfaces)". Bem, responder a "sua proposta não permite os casos de uso mais básicos para os quais as pessoas querem genéricos" com "podemos apenas fazer as coisas que as pessoas já estão fazendo sem genéricos para os casos de uso mais básicos" não parece nos entender em qualquer lugar, tbm. Uma proposta genérica que não te ajuda a escrever nem mesmo tipos básicos de container, sort, max… simplesmente não parece valer a pena.

isso é verdade em qualquer uma das propostas que vi aqui (incluindo a minha).

A maioria das propostas genéricas inclui alguma maneira de restringir os parâmetros de tipo. ou seja, para expressar "o parâmetro de tipo deve ter um método Less", ou "o parâmetro de tipo deve ser comparável". O seu - AFAICT - não.

Considere a seguinte definição de tabela de hash:

Sua definição está incompleta. a) O tipo de chave também precisa de igualdade e b) você não está impedindo o uso de diferentes tipos de chave. ou seja, isso seria legal:

type hasherA uint64

func (a hasherA) Hash() []byte {
    b := make([]byte, 8)
    binary.BigEndian.PutUint64(b, uint64(a))
    return b
}

type hasherB string

func (b hasherB) Hash() []byte {
    return []byte(b)
}

h := new(HashTable int)
h.Insert(hasherA(42), 1)
h.Insert(hasherB("Hello world"), 2)

No entanto, não deve ser legal, pois você está usando diferentes tipos de chaves. ou seja, o contêiner não é verificado de acordo com o grau que as pessoas desejam. Você precisa parametrizar a tabela de hash sobre o tipo de chave e valor

type HashTable k v struct {
    Keys []k
    Values []v
}

func (h *(HashTable k v)) Insert(key k, value v) {
    // You can't actually do anything with k, as it's unconstrained. i.e. you can't hash it, compare it…
    // Implementing this is impossible in your proposal.
}

// If it weren't impossible, you'd get this:
h := new(HashTable hasherA int)
h[hasherA(42)] = 1
h[hasherB("Hello world")] = 2 // compile error - can't use hasherB as hasherA

Ou, se ajudar, imagine que você está tentando implementar um conjunto de hash. Você teria o mesmo problema, mas agora o contêiner resultante não tem nenhuma verificação de tipo adicional sobre interface{} .

É por isso que sua proposta não aborda os casos de uso mais básicos: ela depende de interfaces para restringir o polimorfismo, mas na verdade não fornece nenhuma maneira de verificar a consistência dessas interfaces. Você pode ter uma verificação de tipo consistente ou ter polimorfismo restrito, mas não ambos. Mas você precisa de ambos.

que para ter uma implementação de Genéricos bem-sucedida em Go, devemos ter algo como o seguinte?

É pelo menos como me sinto sobre isso, sim, praticamente. Se uma proposta não permite escrever contêineres de tipo seguro ou classificar ou… ela realmente não adiciona nada à linguagem existente que seja significativo o suficiente para justificar o custo.

@Merovius Ok. Acho que entendi o que você quer. Tenha em mente que seus casos de uso estão muito longe do que eu quero. Eu não estou realmente ansioso por recipientes seguros, embora eu suspeite - como você afirmou - que pode ser uma opinião minoritária. Algumas das maiores coisas que eu gostaria de ver são tipos de resultados em vez de erros e manipulação fácil de fatias sem duplicação ou reflexão em todos os lugares que minha proposta faz um trabalho razoável de endereçamento. No entanto, posso ver como, da sua perspectiva, "não aborda os casos de uso mais básicos" se seu caso de uso básico for escrever contêineres genéricos sem o uso de interfaces,

Observe que essa interface ainda não é possível em sua proposta de genéricos, pois ela depende de reflexão para comprimento e troca (portanto, novamente, você tem uma restrição nas operações de fatia). Mesmo se aceitarmos essa API como o limite inferior do que os genéricos devem ser capazes de realizar (muitas pessoas não aceitariam. Ainda há muitas reclamações sobre a falta de segurança de tipo nessa API), sua proposta não passaria aquela barra.

Lendo isso, fica claro que você entendeu mal a maneira como as fatias genéricas funcionariam/deveriam funcionar sob essa proposta. É por meio desse mal-entendido que você chegou à falsa conclusão de que "essa interface ainda não é possível na sua proposta". Sob qualquer proposta, uma fatia genérica deve ser possível, é o que eu acho. E len() no mundo, como eu vi, seria definido como: func len(slice []a) , que é um argumento de fatia genérico, o que significa que ele pode contar o comprimento de maneira não-reflexiva para qualquer fatia. Este é muito o ponto desta proposta como eu disse acima (fácil manipulação de fatias) e sinto muito por não ter conseguido transmitir isso bem através dos exemplos que dei e da essência que fiz. Uma fatia genérica deve poder ser usada tão facilmente quanto um []int é hoje, direi novamente que qualquer proposta que não aborde isso (trocas de fatia/array, atribuição, len, cap, etc. ) está aquém na minha opinião.

Tudo isso dito, agora estamos realmente claros sobre quais são os objetivos um do outro. Quando propus o que fiz, disse muito que era simplesmente uma proposta sintática e que os detalhes eram super confusos. Mas nós meio que entramos nos detalhes de qualquer maneira e um desses detalhes acabou sendo a falta de restrições, quando eu escrevi eu simplesmente não os tinha em mente porque eles não são importantes para o que eu gostaria de fazer , não quer dizer que não podemos adicioná-los ou que eles não são desejáveis. O principal problema em continuar com a sintaxe proposta e tentar inserir restrições seria que a definição de um argumento genérico atualmente se repete (intencionalmente), então não há referência a código em outro lugar para determinar restrições etc. não vejo como poderíamos manter isso.

O melhor contra-exemplo é aquela função de classificação que discutimos anteriormente.

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

Como você pode ver, não há uma boa maneira de fazer isso acontecer, e as abordagens de token-spam para Genéricos começam a soar melhor novamente. Para definir restrições sobre isso, precisamos alterar duas coisas da proposta original:

• É preciso haver uma maneira de apontar para um argumento de tipo e dar-lhe restrições.
• As restrições precisam durar mais do que uma única definição, talvez esse escopo seja um tipo, talvez esse escopo seja um arquivo (arquivo na verdade parece bastante razoável).

Isenção de responsabilidade: O seguinte não é uma alteração real da proposta porque estou apenas lançando símbolos aleatórios, estou apenas usando essas sintaxes como exemplos para ilustrar o que poderíamos fazer para alterar a proposta como está originalmente

// Decorator style, follows the definition of the type thorugh all
// of it's methods.
<strong i="14">@a</strong>: Lesser, Hasher, Equaler
func Sort(slice []a) { ... }
<strong i="15">@k</strong>: Equaler, Hasher
type HashTable k v struct

// Inline, follows the definition of the type through
// all of it's methods.
func [a: Hasher, Equaler] Sort(slice []a) { ... }
type [k: Hasher, Equaler] HashTable k v struct

// File-scope global style, if k appears as a generic argument
// it's constrained by this that appears at the top of the file underneath
// the imports but before any other code.
<strong i="16">@k</strong>: Equaler, Hasher

Mais uma vez, observe que nenhuma das opções acima eu realmente quero adicionar à proposta. Estou apenas mostrando que tipo de construções poderíamos usar para resolver o problema, e como elas se parecem é um tanto irrelevante no momento.

A pergunta que precisamos responder é: ainda ganhamos valor com os argumentos genéricos implícitos? O ponto principal da proposta era manter a sensação limpa do estilo Go da linguagem, manter as coisas simples, manter as coisas com ruído suficientemente baixo, eliminando tokens excessivos. Nos muitos casos em que não há restrições necessárias, por exemplo, uma função de mapa ou a definição de um tipo de resultado, parece bom, parece Go, é útil? Assumindo que as restrições também estão disponíveis de uma forma ou de outra.

func map(slice []a, mapper func(a) b) {
  for i := range slice {
    slice[i] = mapper(slice[i])
  }
}

type Result a b struct {
  Ok  a
  Err b
}

@aarondl vou tentar explicar. A razão pela qual você precisa de restrições de tipo é porque essa é a única maneira de chamar funções ou métodos em um tipo. considere o tipo irrestrito a que tipo pode ser, bem, pode ser uma string ou um Int ou qualquer coisa. Portanto, não podemos chamar nenhuma função ou método porque não conhecemos o tipo. Poderíamos usar uma mudança de tipo e reflexão de tempo de execução para obter o tipo e, em seguida, chamar algumas funções ou métodos nele, mas isso é algo que queremos evitar com genéricos. Quando você restringe um tipo, por exemplo a é um Animal, podemos chamar qualquer método definido para um animal em a .

No seu exemplo, sim, você pode passar uma função mapeadora, mas isso resultará em funções que recebem muitos argumentos e é basicamente como uma linguagem sem interfaces, apenas funções de primeira classe. Para passar todas as funções que você usará no tipo a obterá uma lista muito longa de funções em qualquer programa real, especialmente se você estiver escrevendo principalmente código genérico para injeção de dependência, o que você deseja fazer para minimizar o acoplamento.

Por exemplo, e se a função que chama map também for genérica? E se a função que chama isso for genérica etc. Como definimos o mapeador se ainda não sabemos o tipo de a ?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

Quais funções podemos chamar em x ao tentar definir mapper ?

@keean Eu entendo o propósito e a função das restrições. Eu simplesmente não os valorizo ​​tanto quanto coisas simples como estruturas de contêineres genéricas (não contêineres genéricos, por assim dizer) e fatias genéricas e, portanto, nem as incluí na proposta original.

Eu ainda acredito principalmente que as interfaces são a resposta certa para problemas como o que você está falando onde você está fazendo injeção de dependência, que simplesmente não parece ser o lugar certo para genéricos, mas quem sou eu para dizer. A sobreposição entre suas responsabilidades é bastante grande aos meus olhos, por isso @Merovius e eu tivemos que discutir se poderíamos ou não viver sem eles, e ele me convenceu de que seriam úteis em alguns casos de uso, portanto, exploramos um pouco do que poderíamos fazer para adicionar o recurso à proposta que fiz originalmente.

Quanto ao seu exemplo, você não pode chamar nenhuma função em x. Mas você ainda pode operar na fatia como qualquer outra fatia, o que é tremendamente útil por conta própria. Também não tenho certeza qual é o func dentro do func ... talvez você quis dizer atribuir a um var?

@aarondl
Obrigado, consertei a sintaxe, mas acho que o significado ainda ficou claro.

Os exemplos que dei acima usaram polimorfismo paramétrico e interfaces para atingir algum nível de programação genérica, no entanto, a falta de despacho múltiplo sempre colocará um teto no nível de generalidade alcançável. Como tal, parece que o Go não vai fornecer os recursos que procuro em uma linguagem, isso não significa que eu não possa usar o Go para algumas tarefas, e de fato eu já estou e funciona bem, mesmo que eu tenha para recortar e colar código que realmente só precisa de uma definição. Só espero que no futuro, se esse código precisar ser alterado, o desenvolvedor possa encontrar todas as instâncias coladas dele.

Estou então em dúvida se a generalidade limitada possível sem grandes mudanças na linguagem é uma boa ideia, considerando a complexidade que isso adicionará. Talvez Go seja melhor permanecer simples, e as pessoas possam adicionar macro como pré-processamento ou outras linguagens que compilam para Go, para fornecer esses recursos? Por outro lado, adicionar polimorfismo paramétrico seria um bom primeiro passo. Permitir que esses parâmetros de tipo sejam restritos seria um bom próximo passo. Então você poderia adicionar parâmetros de tipo associados a interfaces, e você teria algo razoavelmente genérico, mas isso é provavelmente o máximo que você pode obter sem despacho múltiplo. Ao dividir em recursos menores separados, acho que você aumentaria a chance de serem aceitos?

@keean
O despacho múltiplo é tudo o que é necessário? Muito poucos idiomas o suportam nativamente. Mesmo C++ não suporta isso. C# meio que suporta via dynamic mas eu nunca usei na prática e a palavra-chave em geral é muito rara no código real. Os exemplos que lembro lidam com algo como análise JSON, não escrevendo genéricos.

O despacho múltiplo é tudo o que é necessário?

IMHO, acho que @keean fala sobre despacho múltiplo estático fornecido por typeclasses/interfaces.
Isso é fornecido em C++ por sobrecarga de método (não sei para C#)

O que você quer dizer é despacho múltiplo dinâmico, que é bastante complicado em linguagens estáticas sem tipos de união. As linguagens dinâmicas contornam esse problema omitindo a verificação de tipo estático (inferência de tipo parcial para linguagens dinâmicas, o mesmo para o tipo "Dinâmico" do C#).

Um tipo pode ser fornecido como "apenas" um parâmetro?

func Append(t, t2 type, arr []t, value t2) []t {
    v := t(value) // conversion
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

@Inuart escreveu:

Um tipo pode ser fornecido como "apenas" um parâmetro?

Questionável até que ponto isso seria possível ou desejado em

O que você deseja pode ser alcançado se as restrições genéricas forem suportadas:

func Append(arr []t, value s) []t  requires Convertible<s,t>{
    v := t(value) // conversion
    return append(arr, v)
}

var arr []int64
v := 0.5

arr = Append(arr, v)

Isso também deve ser possível com restrições:

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

Pelo que vale, nossa linguagem Genus suporta despacho múltiplo. Os modelos para uma restrição podem fornecer várias implementações para as quais são despachadas.

Eu entendo que a notação Convertible<s,t> é necessária para a segurança do tempo de compilação, mas talvez possa ser degradada para uma verificação de tempo de execução

func Append(t, t2 type, arr []t, value t2) []t {
    v, ok := t(value) // conversion
    if !ok {
        panic(...) // or return an err
    }
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

Mas isso se parece mais com açúcar de sintaxe para reflect .

@Inuart o ponto é que o compilador pode verificar se o tipo implementa a typeclass em tempo de compilação, portanto, a verificação em tempo de execução é desnecessária. O benefício é um melhor desempenho (chamado abstração de custo zero). Se for uma verificação de tempo de execução, você também pode usar reflect .

@creker

O despacho múltiplo é tudo o que é necessário?

Eu estou em mente muito sobre isso. Por um lado, o despacho múltiplo (com classes do tipo multiparâmetros) não funciona bem com existenciais, o que 'Go' chama de 'valores de interface'.

type Equals<T> interface {eq(right T) bool}
(left I) eq(right I) bool {return left == right}
(left I) eq(right F) bool {return false}
(left F) eq(right I) bool {return false}
(left F) eq(right F) bool {return left == right}

func main() {
    x := []Equals<?>{I{2}, F{4.0}, I{2}, F{4.0}}
}

Não podemos definir a fatia de Equals porque não temos como indicar que o parâmetro do lado direito é da mesma coleção. Não podemos nem fazer isso em Haskell:

data Equals = forall a . IEquals a a => Equals a

Isso não é bom porque só permite que um tipo seja comparado consigo mesmo

data Equals = forall a b . IEquals a b => Equals a

Isso não é bom porque não temos como restringir b a ser outro existencial na mesma coleção que a (se a estiver em uma coleção).

No entanto, torna muito fácil estender com um novo tipo:

(left K) eq(right I) bool {return false}
(left K) eq(right F) bool {return false}
(left I) eq(right K) bool {return false}
(left F) eq(right K) bool {return false}
(left K) eq(right K) bool {return left == right}

E isso seria ainda mais conciso com instâncias padrão ou especialização.

Por outro lado, podemos reescrever isso em 'Go' que funciona agora:

package main

type I struct {v int}
type F struct {v float32}

type EqualsInt interface {eqInt(left I) bool}
func (right I) eqInt (left I) bool {return left == right}
func (right F) eqInt (left I) bool {return false}

type EqualsFloat interface {eqFloat(left F) bool}
func (right I) eqFloat (left F) bool {return false}
func (right F) eqFloat (left F) bool {return left == right}

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

type EqualsLeft interface {eq(right EqualsRight) bool}
func (left I) eq (right EqualsRight) bool {return right.eqInt(left)}
func (left F) eq (right EqualsRight) bool {return right.eqFloat(left)}

type Equals interface {
    EqualsLeft
    EqualsRight
}

func main() {
    x := []Equals{I{2}, F{4.0}, I{2}, F{4.0}}
    println(x[0].eq(x[1]))
    println(x[1].eq(x[0]))
    println(x[0].eq(x[2]))
    println(x[1].eq(x[3]))
}

Isso funciona bem com o existencial (valor da interface), porém é muito mais complexo, mais difícil de ver o que está acontecendo e como funciona, e tem a grande restrição de que precisamos de uma interface por tipo e precisamos codificar o aceitável tipos do lado direito como este:

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

O que significa que teríamos que modificar a fonte da biblioteca para adicionar um novo tipo porque a interface EqualsRight não é extensível.

Portanto, sem interfaces multiparâmetros, não podemos definir operadores genéricos extensíveis como igualdade. Com interfaces multiparâmetros existenciais (valores de interface) tornam-se problemáticos.

Meu principal problema com muitas das sintaxes propostas (sintaces?) Blah[E] é que o tipo subjacente não mostra nenhuma informação sobre conter genéricos.

Por exemplo:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

Isso significa que estamos declarando um novo tipo que adiciona mais informações ao tipo subjacente. O objetivo da declaração type não é definir um nome baseado em outro tipo?

Eu proporia uma sintaxe mais ao longo da linha de

type Comparer interface[C] {
    Compare(other C) bool
}

Isso significa que realmente Comparer é apenas um tipo baseado em interface[C] { ... } , e interface[C] { ... } é, obviamente, seu próprio tipo separado de interface { ... } . Isso permite que você use uma interface genérica sem nomeá-la, se desejar (o que é permitido com interfaces normais). Eu acho que esta solução é um pouco mais intuitiva e funciona bem com o sistema de tipos do Go, embora por favor me corrija se eu estiver errado.

Nota: Declarar um tipo genérico só seria permitido em interfaces, structs e funcs com as seguintes sintaxes:
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

Então "implementando" os genéricos teria as seguintes sintaxes:
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

E com alguns exemplos para deixar mais claro:

Interfaces

package add

type Adder interface[E] {
    // Adds the element and returns the size
    Add(elem E) int
}

// Adds the integer 5 to any implementation of Adder[int].
func AddFiveTo(a Adder[int]) int {
    return a.Add(5)
}

Estruturas

package heap

type List struct[T] {
    slice []T
}

func (l *List) Add(elem T) { // T is a type defined by the receiver
    l.slice = append(l.slice, elem)
}

Funções

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

Isso é uma resposta ao rascunho de contratos do Go2 e usarei sua sintaxe, mas estou postando aqui, pois se aplica a qualquer proposta de polimorfismo paramétrico.

A incorporação de parâmetros de tipo não deve ser permitida.

Considerar

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

para algum tipo arbitrário R e algum contrato arbitrário C que não contém Foo() .

T terá todos os seletores exigidos por C mas uma instanciação específica de T também pode ter outros seletores arbitrários, incluindo Foo .

Digamos que Bar seja uma struct, admissível em C , que tenha um campo chamado Foo .

X(Bar) pode ser uma instanciação ilegal. Sem uma forma de especificar no contrato que um tipo não possui um seletor, isso teria que ser uma propriedade inferida.

Métodos de X(Bar) podem continuar a resolver referências a Foo como X(Bar).R.Foo . Isso torna possível escrever o tipo genérico, mas pode ser confuso para um leitor não familiarizado com os detalhes das regras de resolução. Fora dos métodos de X , o seletor permaneceria ambíguo então, enquanto interface { Foo() } não depende dos parâmetros de X , algumas instanciações de X não satisfazê-lo.

Não permitir a incorporação de um parâmetro de tipo é mais simples.

(Se isso for permitido, no entanto, o nome do campo será T pela mesma razão que o nome do campo de um S incorporado definido como type S = io.Reader é S e não Reader mas também porque o tipo que instancia T não precisa necessariamente ter um nome.)

@jimmyfrasche Eu acho que os campos incorporados com tipos genéricos são úteis o suficiente para que seja bom permiti-los, mesmo que haja um pouco de constrangimento em alguns lugares. Minha sugestão seria assumir em todo código genérico que o tipo embutido definiu todos os campos e métodos possíveis em todos os níveis possíveis, de modo que dentro do código genérico todos os métodos embutidos e campos de tipos não genéricos sejam apagados.

Assim dado:

type R struct(type T) {
    io.Reader
    T
}

métodos em R não seriam capazes de invocar Read em R sem indiretamente através de Reader. Por exemplo:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

A única desvantagem que posso ver disso é que o tipo dinâmico pode conter mais membros do que o tipo estático. Por exemplo:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

A única desvantagem que posso ver disso é que o tipo dinâmico pode conter mais membros do que o tipo estático.

Este é o caso com parâmetros de tipo diretamente, então acho que também deve funcionar com tipos paramétricos. Acho que a solução para o problema que o @jimmyfrasche apresentou pode ser colocar o conjunto de métodos desejado do tipo parametrizado no contrato.

contract C(t T) {
  interface { Foo() } (X(T){})
  // ...
}

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

Isso permitiria que Foo fosse chamado em X diretamente. Claro, isso entraria em conflito com a regra "sem nomes locais nos contratos" ...

@stevenblenkinsop Hmm, é possível, se estranho, fazer isso sem se referir a X

contract C(t T) {
  struct{ R; T }{}.Foo
}

C ainda está vinculado à implementação de X embora um pouco mais vagamente.

Se você não fizer isso, e você escrever

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

ele compila? Não estaria sob a regra do @rogpeppe que parece que precisaria ser adotado também para quando você não fizer a garantia no contrato. Mas isso se aplica apenas quando você incorpora um argumento de tipo sem um contrato suficiente ou para todas as incorporações?

Seria mais fácil simplesmente desautorizá-lo.

Comecei a trabalhar nessa proposta antes que o rascunho do Go2 fosse anunciado.

Eu estava pronto para descartar o meu feliz quando vi o anúncio, mas ainda estou inseguro com a complexidade do rascunho, então terminei o meu. É menos poderoso, mas mais simples. Se nada mais, pode ter alguns bits que valem a pena roubar.

Ele expande a sintaxe das propostas anteriores de @ianlancetaylor , pois era isso que estava disponível quando comecei. Isso não é fundamental. Pode ser substituído por uma sintaxe (type T etc. ou algo equivalente. Eu só precisava de alguma sintaxe como notação para a semântica.

Ele está localizado aqui: https://gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

A regra teria que ser que qualquer método promovido a partir de uma profundidade maior do que a de um parâmetro de tipo incorporado não pode ser chamado a menos que (1) a identidade do argumento de tipo seja conhecida ou (2) o método seja declarado como chamável na type pelo contrato que restringe o parâmetro type. O compilador também pode determinar os limites superior e inferior na profundidade que um método promovido deve ter dentro do tipo externo O e usá-los para determinar se o método pode ser chamado em um tipo que incorpora O , ou seja, se há potencial de conflito com outros métodos promovidos ou não. Algo semelhante também se aplicaria a qualquer parâmetro de tipo declarado como tendo métodos que podem ser chamados, onde os intervalos de profundidade dos métodos dentro do parâmetro de tipo seriam [0, inf).

A incorporação de parâmetros de tipo parece útil demais para proibi-lo completamente. Por um lado, permite composição transparente, que o padrão de interfaces embutidas não permite.

Também encontrei um uso potencial na definição de contratos. Se você quiser aceitar um valor do tipo T (que pode ser um tipo de ponteiro) que possa ter métodos definidos em *T , e você quiser colocar esse valor em uma interface, você não pode necessariamente colocar T na interface, já que os métodos podem estar em *T , e você não pode necessariamente colocar *T na interface porque T pode ser um tipo de ponteiro (e, portanto, *T pode ter um método vazio definido). No entanto, se você tivesse um wrapper como

type Wrapper(type T) { T }

você pode colocar *Wrapper(T) na interface em todos os casos se o seu contrato disser que satisfaz a interface.

Você não pode simplesmente fazer

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

Estou tentando lidar com o caso em que alguém liga

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

Isso não funcionará porque S não pode ser convertido em Interface , apenas *S pode.

Obviamente, a resposta pode ser "não faça isso". No entanto, a proposta de contratos descreve contratos como:

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S satisfaria este contrato devido ao endereçamento automático, assim como *S . O que estou tentando resolver é a lacuna de capacidade entre chamadas de método e conversões de interface em contratos.

De qualquer forma, isso é um pouco tangente, mostrando um uso potencial para incorporar parâmetros de tipo.

Re embedding, acho que “pode embutir em um struct” é outra restrição que os contratos teriam que capturar se permitidos.

Considerar:

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

A incorporação de tipos de @bcmills com seletores ambíguos é permitida, então não tenho certeza de como esse contrato deve ser interpretado.

De qualquer forma, se você estiver apenas incorporando tipos conhecidos, tudo bem. Se você está apenas incorporando parâmetros de tipo, tudo bem. O único caso que fica estranho é quando você incorpora um ou mais tipos conhecidos E um ou mais parâmetros de tipo e somente quando os seletores dos tipos conhecidos e os argumentos de tipo não são disjuntos

A incorporação de tipos de @bcmills com seletores ambíguos é permitida, então não tenho certeza de como esse contrato deve ser interpretado.

Hum, bom ponto. Falta mais uma restrição para acionar o erro.¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹ https://play.golang.org/p/3wSg5aRjcQc

Isso requer um X ou Y mas não ambos para ser um io.Reader . É interessante que o sistema de contratos seja expressivo o suficiente para permitir isso. Estou feliz por não ter que descobrir as regras de inferência de tipo para tal fera.

Mas esse não é realmente o problema.

É quando você faz

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

Isso deve falhar ao compilar porque T pode ter um seletor Read a menos que C tenha

struct{ io.Reader; T }.Read

Mas então quais são as regras quando C não garante que os conjuntos de seletores sejam disjuntos e S não faça referência aos seletores? É possível que cada instanciação S satisfaça uma interface, exceto para tipos que criam um seletor ambíguo?

É possível que cada instanciação S satisfaça uma interface, exceto para tipos que criam um seletor ambíguo?

Sim, parece ser esse o caso. Será que isso implica em algo mais profundo... 🤔

Não consegui construir nada irremediavelmente desagradável, mas a assimetria é bastante desagradável e me deixa desconfortável:

type I interface { /* ... */ }
a := G(A) // ok, A satisfies contract
var _ I = a // ok, no selector overlap
b := G(B) // ok, B satisfies contract
var _ = b // error, selector overlap

Estou preocupado com as mensagens de erro quando G0(B) usa um G1(B) usa um arquivo . . . usa um Gn(B) e Gn é o que causa o erro. . . .

FTR, você não precisa passar pelo problema de seletores ambíguos para acionar erros de tipo com incorporação.

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

Você está assumindo que o nome do campo incorporado é baseado no tipo de argumento, enquanto é mais provável que seja o nome do parâmetro de tipo incorporado. Isso é como quando você incorpora um alias de tipo e o nome do campo é o alias em vez do nome do tipo que ele alias.

Na verdade, isso é especificado no projeto de projeto na seção sobre tipos parametrizados :

Quando um tipo parametrizado é uma estrutura e o parâmetro de tipo é incorporado como um campo na estrutura, o nome do campo é o nome do parâmetro de tipo, não o nome do argumento de tipo.

type Lockable(type T) struct {
    T
    mu sync.Mutex
}

func (l *Lockable(T)) Get() T {
    l.mu.Lock()
    defer l.mu.Unlock()
    return l.T
}

(Nota: isso funciona mal se você escrever Lockable(X) na declaração do método: o método deve retornar lT ou lX? Talvez devêssemos simplesmente banir a incorporação de um parâmetro de tipo em uma estrutura.)

Estou apenas sentado aqui à margem e observando. Mas também ficando um pouco preocupado.

Uma coisa que não tenho vergonha de dizer é que 90% dessa discussão está na minha cabeça.

Parece que 20 anos ganhando a vida escrevendo software sem saber o que é genérico, ou polimorfismo paramétrico, não me impediu de fazer o trabalho.

Infelizmente, só dediquei um ano atrás para aprender Go. Eu fiz a falsa suposição de que era uma curva de aprendizado íngreme e levaria muito tempo para se tornar produtivo.

Eu não poderia estar mais errado.

Consegui aprender Go o suficiente para construir um microsserviço que destruiu completamente o serviço node.js com o qual eu estava tendo problemas de desempenho em menos de um fim de semana.

Ironicamente, eu estava apenas brincando. Eu não estava particularmente falando sério sobre conquistar o mundo com Go.

E, no entanto, dentro de algumas horas, eu me encontrei sentando da minha postura desleixada e derrotada, como se estivesse na beirada do meu assento assistindo a um thriller de ação. A API que eu estava construindo surgiu tão rapidamente. Percebi que essa era realmente uma linguagem na qual valia a pena investir meu precioso tempo, porque era obviamente muito pragmática em seu design.

E é isso que eu amo em Go. É muito rápido..... Para aprender. Todos nós aqui sabemos de suas capacidades de desempenho. Mas a velocidade com que pode ser aprendida é incomparável com as outras 8 línguas que aprendi ao longo dos anos.

Desde então venho cantando louvores ao Go, e consegui que mais 4 Devs se apaixonassem por ele. Eu apenas sento com eles por algumas horas e construo algo. Os resultados falam por si.

Simplicidade e rapidez para aprender. Esses são os verdadeiros recursos matadores da linguagem.

Linguagens de programação que exigem meses de aprendizado árduo muitas vezes não retêm os próprios desenvolvedores que procuram atrair. Temos trabalho a fazer e empregadores que querem ver o progresso diário (obrigado ágil, agradeço)

Portanto, há duas coisas que espero que a equipe Go possa levar em consideração:

1) Que problema do dia a dia estamos procurando resolver?

Não consigo encontrar um exemplo do mundo real, com uma rolha de show que seria resolvida por genéricos, ou seja lá como eles vão ser chamados.

Exemplos de estilo de livro de receitas de tarefas do dia a dia que são problemáticas, com um exemplo de como elas podem ser melhoradas com essas propostas de mudança de linguagem.

2) Mantenha-o simples, como todos os outros ótimos recursos do Go

Há alguns comentários incrivelmente inteligentes aqui. Mas estou certo de que a maioria dos desenvolvedores que usam Go no dia a dia para programação geral, como eu, estão perfeitamente felizes e produtivos com as coisas do jeito que estão.

Talvez um argumento do compilador para habilitar esses recursos avançados? '--hardcore'

Eu ficaria muito triste se impactássemos negativamente o desempenho do compilador. Apenas diga n

E é isso que eu amo em Go. É muito rápido..... Para aprender. Todos nós aqui sabemos de suas capacidades de desempenho. Mas a velocidade com que pode ser aprendida é incomparável com as outras 8 línguas que aprendi ao longo dos anos.

Eu concordo completamente. A combinação de poder com simplicidade em uma linguagem totalmente compilada é algo completamente único. Eu definitivamente não quero que Go perca isso, e por mais que eu queira genéricos, não acho que valha a pena por esse preço. Eu não acho que é necessário perder isso, no entanto.

Não consigo encontrar um exemplo do mundo real, com uma rolha de show que seria resolvida por genéricos, ou seja lá como eles vão ser chamados.

Eu tenho dois principais casos de uso principais para genéricos: Eliminação padrão de segurança de tipo de estruturas de dados complexas, como árvores binárias, conjuntos e sync.Map , e a capacidade de escrever funções de segurança de tipo _compile-time_ que operam com base puramente na funcionalidade de seus argumentos, em vez de seu layout na memória. Existem algumas coisas mais extravagantes que eu não me importaria de poder fazer, mas eu não me importaria de _não_ poder fazê-las se for impossível adicionar suporte para elas sem quebrar completamente a simplicidade da linguagem.

Para ser honesto, já existem recursos no idioma que são bastante abusivos. A principal razão pela qual eles _não_ são abusados ​​com tanta frequência, eu acho, é a cultura Go de escrever código 'idiomático', combinada com a biblioteca padrão que fornece exemplos limpos e fáceis de encontrar de tal código, na maioria das vezes. Obter um bom uso de genéricos na biblioteca padrão definitivamente deve ser uma prioridade quando eles forem implementados.

@camstuart

Não consigo encontrar um exemplo do mundo real, com uma rolha de show que seria resolvida por genéricos, ou seja lá como eles vão ser chamados.

Os genéricos são para que você não precise escrever o código sozinho. Portanto, você nunca precisará implementar outra lista vinculada, árvore binária, deque ou fila de prioridade novamente. Você nunca precisará implementar um algoritmo de classificação, um algoritmo de particionamento ou um algoritmo de rotação etc. e girar). Se você puder reutilizar esses componentes, a taxa de erro diminuirá, porque toda vez que você reimplementar uma fila de prioridade ou um algoritmo de particionamento, há uma chance de você errar e introduzir um bug.

Genéricos significam que você escreve menos código e reutiliza mais. Eles significam que funções de biblioteca padrão e bem mantidas e tipos de dados abstratos podem ser usados ​​em mais situações, para que você não precise escrever seus próprios.

Melhor ainda, tudo isso pode ser feito tecnicamente em Go agora, mas apenas com uma perda quase completa de segurança de tipo em tempo de compilação _e_ com alguma sobrecarga de tempo de execução potencialmente grande. Os genéricos permitem que você faça isso sem nenhuma dessas desvantagens.

Implementação de função genérica:

/*

* "generic" is a KIND of types, just like "struct", "map", "interface", etc...
* "T" is a generic type (a type of kind generic).
* var t = T{int} is a value of type T, values of generic types looks like a "normal" type

*/

type T generic {
    int
    float64
    string
}

func Sum(a, b T{}) T{} {
    return a + b
}

Chamador de função:

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

Implementação de estrutura genérica:

type ItemT generic {
    interface{}
}

type List struct {
    l []ItemT{}
}

func NewList(t ItemT) *List {
    l := make([]t)
    return &List{l}
}

func (p *List) Push(item ItemT{}) {
    p.l = append(p.l, item)
}

Chamador:

list := NewList(ItemT{int})
list.Push(42)

Como alguém apenas aprendendo Swift e não gostando, mas com bastante experiência em outras linguagens como Go, C, Java, etc; Eu realmente acredito que genéricos (ou templates, ou o que você quiser chamar) não é uma coisa boa para adicionar à linguagem Go.

Talvez eu seja apenas mais experiente com a versão atual do Go, mas para mim isso parece uma regressão ao C++, pois é mais difícil entender o código que outras pessoas escreveram. O espaço reservado clássico T para tipos torna muito difícil entender o que uma função está tentando fazer.

Eu sei que este é um pedido de recurso popular para que eu possa lidar com ele se ele chegar, mas eu queria adicionar meus 2 centavos (opinião).

@jlubawy
Você conhece outra maneira de nunca precisar implementar uma lista vinculada ou algoritmo de classificação rápida? Como Alexander Stepanov aponta, a maioria dos programadores não pode definir corretamente as funções "min" e "max", então que esperança temos de implementar corretamente algoritmos mais complexos sem muito tempo de depuração. Prefiro extrair versões padrão desses algoritmos de uma biblioteca e aplicar apenas aos tipos que tenho. Que alternativa existe?

@jlubawy

ou modelo, ou como você quiser chamá-lo

Tudo depende da implementação. se estamos falando de modelos C++, sim, eles são difíceis de entender em geral. Até mesmo escrevê-los é difícil. Por outro lado, se pegarmos os genéricos do C#, isso é outra coisa completamente diferente. O conceito em si não é um problema aqui.

Se você não sabia, a Go Team anunciou um rascunho do Go 2.0:
https://golang.org/s/go2designs

Há um rascunho para o design Genéricos no Go 2.0 (contrato). Você pode querer dar uma olhada e dar feedback sobre o Wiki deles.

Esta é a seção relevante:

Genéricos

• Visão geral
• Projeto de rascunho
• Página de feedback da wiki

Depois de ler o rascunho, pergunto:

Por que

T:Adicionável

significa "um tipo T implementando o contrato Addable"? Por que adicionar um novo
conceito quando já temos INTERFACES para isso? A atribuição de interfaces é
verificado em tempo de compilação, então já temos os meios para não precisar de nenhum
conceito adicional aqui. Podemos usar este termo para dizer algo como: Qualquer
tipo T implementando a interface Addable. Além disso, T:_ ou T:Qualquer
(sendo Any uma palavra-chave especial ou um alias integrado de interface{}) faria
o truque.

Só não sei por que reimplementar a maioria das coisas assim. Não faz
sentido e será redundante (assim como redundante é o novo tratamento de erros wrt
o tratamento de pânicos).

14/09/2018 6:15 GMT-05:00 Koala Yeung [email protected] :

Se você não sabia, a Go Team anunciou um rascunho do Go 2.0:
https://golang.org/s/go2designs

Há um rascunho para o design Genéricos no Go 2.0 (contrato). Você pode querer
para dar uma olhada e dar feedback
https://github.com/golang/go/wiki/Go2GenericsFeedback em seu Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Esta é a seção relevante:

Genéricos

• Visão geral
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Projeto de rascunho] (https://go.googlesource.com/proposal/+/master/design/
  go2draft-contratos.md)
• Página de feedback da wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Este é um teste para assinaturas de correio a serem usadas no TripleMint

Edit: "[...] faria o truque SE VOCÊ NÃO PRECISA DE NENHUM REQUISITO ESPECÍFICO
O ARGUMENTO TIPO".

17/09/2018 11:10 GMT-05:00 Luis Masuelli [email protected] :

Depois de ler o rascunho, pergunto:

Por que

T:Adicionável

significa "um tipo T implementando o contrato Addable"? Por que adicionar um novo
conceito quando já temos INTERFACES para isso? A atribuição de interfaces é
verificado em tempo de compilação, então já temos os meios para não precisar de nenhum
conceito adicional aqui. Podemos usar este termo para dizer algo como: Qualquer
tipo T implementando a interface Addable. Além disso, T:_ ou T:Qualquer
(sendo Any uma palavra-chave especial ou um alias integrado de interface{}) faria
o truque.

Só não sei por que reimplementar a maioria das coisas assim. Não faz
sentido e será redundante (assim como redundante é o novo tratamento de erros wrt
o tratamento de pânicos).

14/09/2018 6:15 GMT-05:00 Koala Yeung [email protected] :

Se você não sabia, a Go Team anunciou um rascunho do Go 2.0:
https://golang.org/s/go2designs

Há um rascunho para o design Genéricos no Go 2.0 (contrato). Você pode
quero dar uma olhada e dar feedback
https://github.com/golang/go/wiki/Go2GenericsFeedback em seu Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Esta é a seção relevante:

Genéricos

• Visão geral
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Projeto de rascunho] (https://go.googlesource.com/p
  roposal/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• Página de feedback da wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Este é um teste para assinaturas de correio a serem usadas no TripleMint

--
Este é um teste para assinaturas de correio a serem usadas no TripleMint

@luismasuelli-jobsity Se eu li o histórico de implementações genéricas em Go corretamente, parece que o motivo de introduzir Contratos é porque eles não queriam sobrecarga de operadores em Interfaces.

Uma proposta anterior que acabou sendo rejeitada usava interfaces para restringir o polimorfismo paramétrico, mas parece ter sido rejeitada porque você não poderia usar operadores comuns como '+' em tais funções porque não é definível em uma interface. Os contratos permitem que você escreva t == t ou t + t para que você possa indicar que o tipo deve suportar igualdade ou adição etc.

Edit: O Go também não suporta várias interfaces de parâmetro de tipo, então, de certa forma, o Go separou typeclass em duas coisas separadas, contratos que relacionam os parâmetros de tipo de funções entre si e interfaces que fornecem métodos. O que perde é a capacidade de selecionar uma implementação typeclass com base em vários tipos. É sem dúvida mais simples se você precisar usar apenas interfaces ou contratos, mas mais complexo se precisar usar os dois juntos.

Por que T:Addable significa "um tipo T implementando o contrato Addable"?

Na verdade, não é isso que significa; apenas parece assim para um argumento de tipo. Em outra parte do rascunho, ele faz o comentário de que você só pode ter um contrato por função, e é aí que entra a principal diferença. Os contratos são, na verdade, declarações sobre os tipos da função, não apenas os tipos independentemente. Por exemplo, se você tiver

func Example(type K, V someContract)(k K, v V) V

você pode fazer algo como

contract someContract(k K, v V) {
  k.someMethod(v)
}

Isso simplifica muito a coordenação de vários tipos sem precisar especificar os tipos de forma redundante na assinatura da função. Lembre-se, eles estão tentando evitar o 'padrão genérico de repetição curiosa'. Por exemplo, a mesma função com interfaces parametrizadas usadas para restringir os tipos seria algo como

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

Isso é meio estranho. A sintaxe do contrato ainda permite que você faça isso se precisar, porque os 'argumentos' do contrato são preenchidos automaticamente pelo compilador se o contrato tiver o mesmo número deles que a função faz parâmetros de tipo. Você pode especificá-los manualmente se quiser, o que significa que você _poderia_ fazer func Example(type K, V someContract(K, V))(k K, v V) V se realmente quisesse, embora não seja particularmente útil nesta situação.

Uma maneira de deixar mais claro que os contratos são sobre funções inteiras, não argumentos individuais, seria simplesmente associá-los com base no nome. Por exemplo,

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

seria o mesmo que o anterior. A desvantagem, no entanto, é que os contratos não seriam reutilizáveis ​​e você perde a capacidade de especificar os argumentos do contrato manualmente.

Edit: Para mostrar ainda mais por que eles querem resolver o padrão curiosamente repetido, considere o problema do caminho mais curto ao qual eles se referiam. Com interfaces parametrizadas, a definição acaba parecendo

type E(Node) interface {
  Nodes() []Node
}

type N(Edge) interface {
  Edges() (from, to Edge)
}

type Graph(type Node: N(Edge), Edge: E(Node)) struct { ... }
func New(type Node: N(Edge), Edge: E(Node))(nodes []Node) *Graph(Node, Edge) { ... }
func (*Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

Pessoalmente, gosto bastante da maneira como os contratos são especificados para funções. Não estou muito interessado em ter apenas corpos de função 'normais' como a especificação real do contrato, mas acho que muitos dos problemas potenciais podem ser resolvidos com a introdução de algum tipo de simplificador do tipo gofmt que simplifica automaticamente os contratos para você, removendo partes estranhas. Então você _poderia_ apenas copiar um corpo de função para ele, simplificá-lo e modificá-lo a partir daí. Eu não tenho certeza de como isso será possível para implementar, no entanto, infelizmente.

Algumas coisas ainda serão um pouco difíceis de especificar, e a aparente sobreposição entre contratos e interfaces ainda parece um pouco estranha.

Acho a versão "CRTP" muito mais clara, mais explícita e mais fácil de trabalhar (não há necessidade de criar contratos que só existem para definir a relação entre contratos pré-existentes sobre um conjunto de variáveis). É certo que isso pode ser apenas os muitos anos de familiaridade com a ideia.

Esclarecimentos. Pela minuta do projeto , o contrato pode ser aplicado tanto a funções quanto a tipos .

"""
É sem dúvida mais simples se você precisar usar apenas interfaces ou contratos, mas mais complexo se precisar usar os dois juntos.
"""

Enquanto eles permitirem que você, dentro de um contrato, faça referência a uma ou mais interfaces (em vez de apenas operadores e funções, permitindo DRY), esse problema (e minha reclamação) será resolvido. Há uma chance de eu ter lido errado ou não ter lido completamente as coisas dos contratos, e também uma chance de que o referido recurso seja suportado e eu não tenha notado. Se não for, deveria ser.

Você não pode fazer o seguinte?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

Você não pode usar uma interface declarada em outro lugar devido à restrição de que você não pode fazer referência a identificadores do mesmo pacote em que o contrato é declarado, mas você pode fazer isso. Ou eles poderiam simplesmente remover essa restrição; parece um pouco arbitrário.

@DeedleFake Não, porque qualquer tipo de interface pode ser declarado por tipo (e, em seguida, entrar em pânico em tempo de execução, mas os contratos não são executados). Mas você pode usar uma atribuição em vez disso.