Отказ от ответственности: я играл в Go всего один день, так что есть хороший шанс, что я многое пропустил.

Кто-нибудь знает, почему в Go нет реальной поддержки generics / templates / whatsInAName? Итак, есть общий map, но он предоставляется компилятором, а программист на Go не может написать свою собственную реализацию. Учитывая все разговоры о том, чтобы сделать Go как можно более ортогональным, почему я могу ИСПОЛЬЗОВАТЬ общий тип, но не СОЗДАТЬ новый?

Особенно, когда дело доходит до функционального программирования, есть лямбды, даже замыкания, но с системой статических типов, не имеющей обобщений, как мне написать, ну, общие функции более высокого порядка, такие как filter(predicate, list)? Хорошо, связанные списки и тому подобное можно делать, interface{}жертвуя безопасностью типов.

Поскольку быстрый поиск в SO / Google не дал никакой информации, похоже, что дженерики, если они вообще будут добавлены в Go, будут запоздалыми. Я верю, что Томпсон справится лучше, чем ребята из Java, но зачем убирать дженерики? Или они запланированы и просто еще не реализованы?

этот ответ вы найдете здесь: http://golang.org/doc/faq#generics

Почему в Go нет универсальных типов?

В какой-то момент вполне могут быть добавлены дженерики. Мы не чувствуем в них необходимости, хотя понимаем, что некоторые программисты это делают.

Обобщения удобны, но они требуют сложности системы типов и времени выполнения. Мы еще не нашли дизайн, который дает ценность, пропорциональную сложности, хотя мы продолжаем думать об этом. Между тем, встроенные карты и срезы Go, а также возможность использовать пустой интерфейс для создания контейнеров (с явной распаковкой) означают, что во многих случаях можно написать код, который делает то, что позволяют дженерики, хотя и менее плавно.

Это остается открытым вопросом.

Перейти 2

На https://blog.golang.org/go2draft есть эскизный проект для дженериков .

Перейти 1

Расс Кокс, один из ветеранов го, написал сообщение в блоге под названием «Общая дилемма» , в котором он спрашивает:

… Вам нужны медленные программисты, медленные компиляторы и раздутые двоичные файлы или медленное время выполнения?

Медленные программисты являются результатом отсутствия дженериков, медленные компиляторы вызваны С ++, подобными дженерикам, а медленное время выполнения проистекает из подхода упаковки-распаковки, который использует Java.

Четвертая возможность, не упомянутая в блоге, идет по пути C #. Генерация специализированного кода, как в C ++, но во время выполнения, когда это необходимо. Мне это очень нравится, но Go очень не похож на C #, так что, вероятно, это вообще не применимо ...

Я должен упомянуть, что использование популярной техники универсального программирования, подобной Java 1.4, в go, которая приводит к interface{}возникновению тех же проблем, что и упаковка-распаковка (потому что это то, что мы делаем), помимо потери безопасности типов во время компиляции. Для небольших типов (например, целых чисел) Go оптимизирует interface{}тип таким образом, чтобы список целых чисел, приведенных к интерфейсу {}, занимал непрерывную область памяти и занимал в два раза больше места, чем обычные целые числа. Тем не менее, существуют накладные расходы на проверки времени выполнения при приведении из interface{}. Ссылка .

Все проекты, которые добавляют универсальную поддержку (их несколько, и все они интересны), единообразно идут по маршруту C ++ генерации кода времени компиляции.

Несмотря на то, что универсальные шаблоны в настоящее время не встроены, существует несколько внешних реализаций универсальных шаблонов, которые используют комментарии в сочетании с небольшими утилитами, генерирующими код.

Вот одна из таких реализаций: http://clipperhouse.github.io/gen/

Собственно, согласно этому сообщению:

Многие люди пришли к выводу (ошибочно), что позиция команды Go такова: «В Go никогда не будет дженериков». Напротив, мы понимаем потенциал дженериков как для того, чтобы сделать Go более гибким и мощным, так и для гораздо более сложного. Если мы хотим добавить дженерики, мы хотим сделать это таким образом, чтобы получить максимальную гибкость и мощность с минимально возможной дополнительной сложностью.

Параметрический полиморфизм (дженерики) находится на рассмотрении для Go 2 .

Этот подход представит концепцию контракта , который можно использовать для выражения ограничений на параметры типа:

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

Такой контракт затем можно было бы использовать следующим образом:

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

Это предложение на данном этапе.

Ваша filter(predicate, list)функция может быть реализована с таким параметром типа:

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
}

В этом случае ограничений нет T.