Почему нет дженериков в Go?
отказ от ответственности: я только играл с Go в течение одного дня, так что есть хороший шанс, что я пропустил много.
кто-нибудь знает, почему нет реальной поддержки дженериков/шаблонов/whatsInAName в Go? Так что есть общий map, но это предоставлено компилятором, в то время как программист Go не может написать свою собственную реализацию. Со всеми разговорами о том, чтобы сделать Go максимально ортогональным, почему я могу использовать общий тип, но не создавать новый?
особенно когда он приходит к функциональному программированию, есть лямбды, даже замыкания, но с системой статического типа, лишенной дженериков, как я пишу, ну, общие функции более высокого порядка, такие как filter(predicate, list)? Хорошо, связанные списки и тому подобное можно сделать с interface{} ущерба для безопасности типа.
как быстрый поиск на SO / Google не показал никаких идей, похоже, что дженерики, если вообще, будут добавлены, чтобы пойти в качестве запоздалой мысли. Я действительно доверяю Томпсону, чтобы сделать лучше, чем Java-ребята, но зачем держать дженерики вышел? Или они запланированы и просто еще не реализованы?
3 ответов:
этот ответ вы найдете здесь: http://golang.org/doc/faq#generics
Почему Go не имеет универсальных типов?
дженерики вполне могут быть добавлены в какой-то момент. Мы не чувствуем срочности для них, хотя мы понимаем, что некоторые программисты делают.
дженерики удобны, но они приходят по стоимости сложности в системе типов и времени выполнения. Мы еще не нашли дизайн, который дает значение пропорционально сложности, хотя мы продолжаем об этом думать. Между тем, встроенные карты и срезы Go, а также возможность использовать пустой интерфейс для создания контейнеров (с явной распаковкой) означают, что во многих случаях можно написать код, который делает то, что дженерики позволят, если менее гладко.
этот вопрос остается открытым.
Go 2
есть проект дизайна для дженериков в https://blog.golang.org/go2draft.
Go 1
Расс Кокс, один из ветеранов го написал сообщение в блоге под названием Общая дилемма, в которой он просит
...вам нужны медленные программисты, медленные компиляторы и раздутые двоичные файлы или медленное время выполнения?
медленные программисты, являющиеся результатом отсутствия дженериков, медленные компиляторы вызвано C++, как дженерики и медленное время выполнения вытекают из бокс-распаковки подхода, который использует Java.
четвертая возможность, не упомянутая в блоге, идет по маршруту C#. Создание специализированных кода как в C++, но во время выполнения, когда это необходимо. Мне это очень нравится, но Go очень отличается от C#, поэтому это, вероятно, вообще не применимо...
Я должен упомянуть, что с помощью популярного Java 1.4, как техника общее программирование в go что бросает в
interface{}страдает точно такими же проблемами, как бокс-анбоксинг (потому что это то, что мы делаем), кроме потери времени компиляции тип безопасности. Для небольших типов (например, ints) Go оптимизируетinterface{}введите так, чтобы список int, которые были приведены к интерфейсу {}, занимал смежную область памяти и занимал только в два раза больше места, чем обычные int. Есть еще накладные расходы на проверку времени выполнения при литье изinterface{}, хотя. ссылка.все проекты это добавляет общую поддержку go (есть несколько из них, и все они интересны) равномерно идут по маршруту C++ генерации кода времени компиляции.
несмотря на то, что дженерики в настоящее время не встроены, существует несколько внешних реализаций дженериков для go, которые используют комментарии в сочетании с небольшими утилитами, которые генерируют код.
вот одна такая реализация:http://clipperhouse.github.io/gen/
Comments