Репост из: Golang Дайджест
🧬 Proposal: Generic Methods для Go
Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил:
> We do not anticipate that Go will ever add generic methods
Но теперь — возможно, добавят 👍
Суть в том, что раньше дженерик-методы блокировались по цепочке: если методы могут принимать параметры типов, значит и методы интерфейсов тоже должны. А это не знали как реализовать эффективно — в Go тип реализует интерфейс неявно, поэтому компилятор не может знать заранее, для каких конкретных типов нужно будет скомпилировать метод.
Ключевой сдвиг в мышлении: метод — это не только способ реализовать интерфейс. Метод — это функция, привязанная к типу, удобная для организации кода и читаемая слева направо. Эти две вещи ортогональны.
Поэтому компромисс такой: методы могут быть generic, но не могут реализовывать интерфейсы с generic методами — их просто не будет. Вот как это выглядит:
type Reader struct{ … }
func (*Reader) Read[E any]([]E) (int, error) { … }
Reader не реализует io.Reader — и это нормально. Зато метод полезен сам по себе.
При этом изменение полностью обратно совместимо и не закрывает возможность добавить такое в будущем, если придумают как.
————
Дискуссия горячая — 156 комментариев. Кто-то радуется, кто-то боится усложнения языка, классика. За то и люблю наше сообщество ✨
Я сам редко работаю с дженериками, но при этом даже я не раз сталкивался с этим ограничением. Приходится делать standalone функции вместо методов — цепочки вызовов ломаются, читаемость страдает.
За я или против? Честно, не знаю — вопрос действительно непростой, если вникать глубоко в проблематику и доводы обоих сторон. Поэтмоу я предпочитаю делегировать столь сложные вопросы бородатым мужчинам — я в них верю! ❤️
Посмотрим, примут ли. Но сам факт, что Griesemer это открыл — уже хороший сигнал.
🟢Кстати, тема дженериков довольно забористая, и понимаю что не все поймут, что тут вообще имеется в виду. Если хотите, я напишу пост с более простым объяснением и разбором этой темы.
#proposal #generics
Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил:
> We do not anticipate that Go will ever add generic methods
Но теперь — возможно, добавят 👍
Суть в том, что раньше дженерик-методы блокировались по цепочке: если методы могут принимать параметры типов, значит и методы интерфейсов тоже должны. А это не знали как реализовать эффективно — в Go тип реализует интерфейс неявно, поэтому компилятор не может знать заранее, для каких конкретных типов нужно будет скомпилировать метод.
Ключевой сдвиг в мышлении: метод — это не только способ реализовать интерфейс. Метод — это функция, привязанная к типу, удобная для организации кода и читаемая слева направо. Эти две вещи ортогональны.
Поэтому компромисс такой: методы могут быть generic, но не могут реализовывать интерфейсы с generic методами — их просто не будет. Вот как это выглядит:
type Reader struct{ … }
func (*Reader) Read[E any]([]E) (int, error) { … }
Reader не реализует io.Reader — и это нормально. Зато метод полезен сам по себе.
При этом изменение полностью обратно совместимо и не закрывает возможность добавить такое в будущем, если придумают как.
————
Дискуссия горячая — 156 комментариев. Кто-то радуется, кто-то боится усложнения языка, классика. За то и люблю наше сообщество ✨
Я сам редко работаю с дженериками, но при этом даже я не раз сталкивался с этим ограничением. Приходится делать standalone функции вместо методов — цепочки вызовов ломаются, читаемость страдает.
За я или против? Честно, не знаю — вопрос действительно непростой, если вникать глубоко в проблематику и доводы обоих сторон. Поэтмоу я предпочитаю делегировать столь сложные вопросы бородатым мужчинам — я в них верю! ❤️
Посмотрим, примут ли. Но сам факт, что Griesemer это открыл — уже хороший сигнал.
🟢Кстати, тема дженериков довольно забористая, и понимаю что не все поймут, что тут вообще имеется в виду. Если хотите, я напишу пост с более простым объяснением и разбором этой темы.
#proposal #generics