Кастование произвольного слайса, к слайсу интерфейсов

[Shtucer]

Ничего не понял.
"Но можно и по другому" и ещё десятком способов, ну или меньше. Чем же предложенный метод лучше очевидного? Или это какой-то очередной плач про отсутствие дженериков? Это, как мне кажется не лучшее применение для uniptr.

[t0pep0]

Это просто интересный «ещё один» способ сделать так. Лучше очевидно — меньшим количеством аллокаций и большей скоростью выполнения. Но я бы не рекомендовал использовать подобное в продакшене.
Это не в коем случае не плач про дженерики.
Лично для меня это был не большой челлендж, смогу или нет — как итог — с удовольствием поковырялся в исходниках Go и его рантайме

[youROCK]

Тут на самом деле авторы go как бы пытались намекнуть — поскольку memory layout у слайса интерфейсов и у слайса интов разный, то они друг к другу не кастуются за O(1), поэтому автоматического преобразования нет. То есть, по возможности (т.е. всегда) следует принимать слайс именно того типа, который вам нужен, или же принимать просто interface{} и итерироваться по нему (или забирать только нужные элементы из слайса) с помощью reflection. Первое намного предпочтительнее, потому что очевидно будет работать сильно быстрее :).

[t0pep0]

Да, Вы абсолютно правы.Могу даже дополнить, что если надо скастовать слайс в слайс интерфейсов, то с большей долей вероятности — что то не так.
В данном случае int не при чём, вместо int'а там мог быть слайс строк или булов, или своих структур, для этого надо изменить только само определения слайса.
Данный метод быстрее, чем перебор циклом и гораздо быстрее, чем рефлексия, но я, как уже говорил выше, не стал бы его использовать в продакшене.

[divan0]

Напомнило README к этому проекту:

• Должен ли я это использовать?
• Конечно же да! Если таки будете, то напишите мне, какая ужасная идея заставила вас так подумать. Мне очень интересно. :)
  https://github.com/zeebo/goof