Дженерики в Go — подробности из блога разработчиков

[Druj]

func Scale[S ~[]E, E constraints.Integer](s S, c E) S

А кто-то потом говорит что у раста синтаскис токсичный

[orcy]

Не зная Go, мне тут в принципе всю понятно (или мне кажется что все понятно), кроме ~. Два generic типа у функции, у типов ограничения - вроде все ок.

[JTG]

Писать код на перле можно на любом языке программирования, как говорится.

[Prototik]

Мне, как джависту, всё понятно, там и не такие дженерики можно увидеть иногда...

Разве что ~ заставляет подумать, но из текста статьи понятно, зачем оно.

[xmcuz]

Жаль что нельзя использовать структуры в качестве типов.

[Devoter]

Можно, проблема в том, как Go интерпретирует ограничения, ограничения - это интерфейсы, а у интерфейсов не может быть полей, только тип и методы. Таким образом, можно ввести ограничение, которое будет задано структурными типами, но нельзя будет обращаться к ним, так как constraint type - это интерфейсный тип, а не структурный. В некотором смысле это даже хорошо, но почему это может быть хорошо нужно писать отдельную статью.

[arturiosdev]

Можно было бы реализовать поддержку полей в интерфейсах по аналогии как это сделано в протоколах Swift. При объявлении поля в интерфейсе, внутри на самом деле объявляются лишь функции get/set. Но для этого я так понимаю нужно полноценное ООП?

[Prototik]

Это уже называется property, а не field. Хоть в простейшем случае property может иметь backing field, но в общем это не так.

Лично я особой проблемы написать один-два метода в интерфейсе вместо филда не вижу, в go итак много boilerplate кода, будет ещё немного, чего уж...