Зачем нужны дженерики, если можно проще?

Question

[elfuegobiz]

Кто в теме, объясните, пожалуйста,почему в golang нельзя []что-то привести к []interface{} :

func remove(slice []interface{}, s interface{}) []interface{} {
    return append(slice[:s], slice[s+1:]...)
}

a := []string{"a", "b", "c"}
b := []int{1, 2, 3}

a = remove(a, 2)
b = remove(b, 1)

Вот -- более широкий пример. Если раскомментировать последние 2 строки в main(), то программа просто не соберётся. Вопрос: почему?? Ведь я могу передать переменную типа i1 в параметры типа intf, почему нельзя передать []i1 в параметр []intf? В смысле, почему не сделать, чтобы так было можно. Так бы было намного проще в том смысле, что вопрос с дженериками не стоял бы так остро.

package main

import (
	"fmt"
	"strconv"
)

type intf interface {
	get() string
}

type i1 string

func (s i1) get() string {
	return string(s)
}

type i2 int

func (s i2) get() string {
	return strconv.Itoa(int(s))
}

func print1(a []intf) {
	for _, i := range a {
		fmt.Print(i, "; ")
	}
}

func main() {
	a := []intf{i1("xyz"), i2(42)}
	print1(a)
	//b := []i1{i1("xyz")}
	//print1(b)
}

Answer 1

[Сергей Тихонов]

В Go отстойная алгебра интерфейсов. Если структура A реализует интерфейс I, это не значит, что []A реализует []I.
А всё потому что приведение типов к интерфейсу - это манипуляции с идентификатором типа в структуре. Очевидно, нужно в цикле заменить этот идентификатор в каждом элементе слайса, чтобы достичь нужного эффекта. Хотелось бы, чтобы это инлайнилось или как-то при компиляции автоматом обрабатывалось, но вот пока нет.

Comments

[elfuegobiz]

Да, я почитал разное об этом, и пришёл к выводу, что вот это ваше "но вот пока нет" наиболее точно передаёт сложившуюся ситуацию =)

[Алексей 〒.]

elfuegobiz, неправильно поняли. Такое поведение и не добавят, так как неявное преобразование за O(n) рушит принципы языка.
https://github.com/golang/go/wiki/InterfaceSlice
Для хранения и передачи слайса достаточно простого interface{}
https://play.golang.org/p/dE7GvBoI47d

[elfuegobiz]

так как неявное преобразование за O(n) рушит принципы языка

Безусловно. Однако, реализовать это можно разными путями, в т.ч. и такими, которые будут быстрее, чем O(n).

[Сергей Тихонов]

Алексей 〒., в 1.17, как я понял, внезапно внедрили рантайм-панику в приведение типов...

Note that the new conversion from slice to array pointer is the first case in which a type conversion can panic at run time. Analysis tools that assume type conversions can never panic should be updated to consider this possibility.

...так что принципами языка иногда можно и пренебречь.

Но в целом да, в текущей реализации конверсия за O(n) - это отстой. Так что ждем дженериков, видимо.

Answer 2

[Алексей 〒.]

Кто в теме, объясните, пожалуйста, почему в golang нельзя []что-то привести к []interface{} :

Привести можно, но это необходимо сделать самостоятельно. interface{} это отдельный тип и slice []interface{} может принять только срез этого типа.

func remove(slice []interface{}, s interface{}) []interface{} {
    return append(slice[:s.(int)], slice[s.(int)+1:]...)
}

func main() {
  a := []string{"a", "b", "c"}
  // преобразование
  ai := make([]interface{}, len(a))
  for i, v := range a {
    ai[i] = v
  }
  ai = remove(ai, 2)

  b := []int{1, 2, 3}
  // преобразование
  bi := make([]interface{}, len(b))
  for i, v := range b {
    bi[i] = v
  }
  bi = remove(bi, 1)
        
  fmt.Printf("%T: %v\n", ai, ai)
  fmt.Printf("%T: %v\n", bi, bi)
}

https://play.golang.org/p/gRHqO31LIJU

В смысле, почему не сделать, чтобы так было можно.

Потому что s []string это массив массивов типа byte, а i []int массив чисел типа int и они имеют в памяти разное представление.

Такая же история:

func main() {
  b := []i1{i1("xyz")}
  bi := make([]intf, len(b))
  for i, v := range b {
     bi[i] = v
  }
  print1(bi)
}

https://play.golang.org/p/z9BoM5lutV0

Answer 3

[index0h]

Зачем нужны дженерики, если можно проще?

дженерики тут ни при чем.

По сути вы пытаетесь передать в print1 (в заккоментированном коде) срез другого типа. Да, тип элементов среза отвечает вашему интерфейсу intf, но сам срез нет. Следующий вызов вполне валиден, но с типам i1 и i2 вы такого не провернете.

func main() {
  print1([]intf{nil, nil})
}

Comments

[elfuegobiz]

Да, ограничения типизации я понимаю. Я не понимаю, почему, на пути к дженерикам, нельзя было сделать чё попроще.
Для моего примера вот такое:

func print1[T intf](a []T) {
...
}

всё-таки выглядит более громоздко, хотя и оригинальный вид прекрасно бы передал смысл.

[index0h]

elfuegobiz, )))) это очень хороший вопрос, дискуссии о том, какими должны быть дженерики в go ведутся уже далеко не первый год. Последний proposal выглядит примерно как у вас в примере https://go.googlesource.com/proposal/+/refs/heads/...
Может в 1.18 его таки добавят, правда я как-то очень сомневаюсь.