Disclaimer: ho giocato con Go solo per un giorno, quindi c'è una buona possibilità che mi sia perso molto.

Qualcuno sa perché non esiste un vero supporto per generics / template / whatsInAName in Go? Quindi esiste un generico map, ma viene fornito dal compilatore, mentre un programmatore Go non può scrivere la propria implementazione. Con tutto il discorso su come rendere Go il più ortogonale possibile, perché posso USARE un tipo generico ma non CREARE uno nuovo?

Soprattutto quando si tratta di programmazione funzionale, ci sono lambda, anche chiusure, ma con un sistema di tipo statico privo di generici, come faccio a scrivere, bene, funzioni generiche di ordine superiore come filter(predicate, list)? OK, le liste collegate e simili possono essere fatte interface{}sacrificando la sicurezza del tipo.

Poiché una rapida ricerca su SO / Google non ha rivelato alcun approfondimento, sembra che i generici, se non del tutto, verranno aggiunti a Go come ripensamento. Mi fido di Thompson di fare molto meglio dei ragazzi di Java, ma perché tenere fuori i generici? O sono pianificati e non ancora implementati?

questa risposta è disponibile qui: http://golang.org/doc/faq#generics

Perché Go non ha tipi generici?

I generici potrebbero anche essere aggiunti ad un certo punto. Non sentiamo l'urgenza per loro, anche se comprendiamo che alcuni programmatori lo fanno.

I generici sono convenienti ma hanno un costo in termini di complessità nel sistema di tipi e nel tempo di esecuzione. Non abbiamo ancora trovato un design che offra un valore proporzionato alla complessità, sebbene continuiamo a pensarci. Nel frattempo, le mappe e le sezioni incorporate di Go, oltre alla possibilità di utilizzare l'interfaccia vuota per costruire contenitori (con unboxing esplicito) significano in molti casi che è possibile scrivere codice che fa ciò che i generici consentirebbero, se meno agevolmente.

Questo rimane un problema aperto.

Vai 2

C'è un progetto di bozza per i generici su https://blog.golang.org/go2draft .

Vai 1

Russ Cox, uno dei veterani di Go, ha scritto un post sul blog intitolato The Generic Dilemma , in cui chiede

... vuoi programmatori lenti, compilatori lenti e binari gonfiati o tempi di esecuzione lenti?

I programmatori lenti sono il risultato di nessuna generica, i compilatori lenti sono causati da generici simili a C ++ e i tempi di esecuzione lenti derivano dall'approccio di box-unboxing che Java utilizza.

La quarta possibilità non menzionata nel blog sta andando sulla rotta C #. Generare il codice specializzato come in C ++, ma in fase di esecuzione quando è necessario. Mi piace davvero molto, ma Go è molto diverso dal C # quindi questo probabilmente non è applicabile affatto ...

Dovrei menzionare che l'utilizzo della popolare tecnica di programmazione generica di Java 1.4 in go che si presenta interface{}soffre esattamente degli stessi problemi del boxing-unboxing (perché è quello che stiamo facendo), oltre alla perdita della sicurezza del tipo di tempo di compilazione. Per tipi piccoli (come gli ints) Go ottimizza il interface{}tipo in modo che un elenco di ints che sono stati espressi per l'interfaccia {} occupi un'area contigua di memoria e occupi solo il doppio dello spazio rispetto agli ints normali. Tuttavia, c'è ancora il sovraccarico dei controlli di runtime durante il cast interface{}. Riferimento .

Tutti i progetti che aggiungono supporto generico per andare (ce ne sono molti e tutti sono interessanti) passano uniformemente alla route C ++ di generazione del time code di compilazione.

Anche se i generici non sono attualmente integrati, ci sono diverse implementazioni esterne di generici per go, che utilizza i commenti in combinazione con piccole utility che generano codice.

Ecco una di queste implementazioni: http://clipperhouse.github.io/gen/

In realtà, secondo questo post:

Molte persone hanno concluso (erroneamente) che la posizione del team Go è "Go non avrà mai generici". Al contrario, comprendiamo i potenziali generici, sia per rendere Go molto più flessibile e potente, sia per rendere Go molto più complicato. Se vogliamo aggiungere farmaci generici, vogliamo farlo in un modo che ottenga la massima flessibilità e potenza con la minore complessità possibile.

Il polimorfismo parametrico (generici) è in esame per Go 2 .

Questo approccio introdurrebbe il concetto di contratto , che può essere utilizzato per esprimere vincoli sui parametri di tipo:

contract Addable(a T) {
  a + a // Could be += also
}

Tale contratto potrebbe quindi essere utilizzato in tal modo:

func Sum(type T Addable)(l []T) (total T) {
  for _, e := range l {
    total += e
  }
  return total
}

Questa è una proposta in questa fase.

La tua filter(predicate, list)funzione potrebbe essere implementata con un parametro di tipo come questo:

func Filter(type T)(f func(T) bool, l []T) (result []T) {
  for _, e := range l {
    if f(e) {
      result = append(result, e)
    }
  }
  return result
}

In questo caso, non è necessario vincolare T.