Go задумывался как язык, который учат за выходные: минимум синтаксиса, никаких хитростей. В 1.18 в него добавили дженерики, но только для функций и типов — методам параметры типа не полагались. Аргумент был технический: дженерик-методы интерфейсов трудно скомпилировать эффективно, а раз так, то и конкретным методам они ни к чему.
26 августа Марк Фримен из команды Go объяснил в блоге, почему это решение пересмотрели. Методы служат не только для реализации интерфейсов: они ещё и способ сгруппировать функциональность вокруг типа. Раньше преобразование списка приходилось выносить в пакетную функцию и писать вызовы «наизнанку»:
MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2)). В 1.27 то же пишется слева направо: NewList(0, 2, 4).Map(add(2)).Map(divideBy(2)).Ограничение осталось: параметры типа разрешены только конкретным методам. У интерфейсов их по-прежнему нет — компилятору пришлось бы порождать инстанциации на все возможные типы-аргументы через границу пакета, потому что при раздельной компиляции он не знает, как чужой пакет распорядится вашим значением.
Через два дня в r/golang собрал 176 голосов пост «Я ненавижу, куда движется Go»: автор жалуется, что видит в коде
req.GetSomething.OrDefault(2) и что язык превращается в Java с Kotlin. Голосов «за» там 69%, для r/golang это необычно спорно, и верхние комментарии на стороне дженериков: «итераторы и дженерики улучшают читаемость и намерение кода», «никто не заставляет вас эти возможности использовать».#go #обсуждение