Mengapa Saya Tidak Boleh Menggunakan Kaedah Dikongsi dengan Kekangan Kesatuan Go Generics?

Kekangan Kesatuan dalam Go Generik: Had Tidak Selesai

Dalam bidang generik Go, kekangan kesatuan jenis telah mencetuskan sedikit kekeliruan. Apabila cuba menggunakan kaedah biasa untuk jenis dalam kekangan kesatuan, pengkompil menimbulkan ralat, menyebabkan pembangun menggaru kepala mereka.

Pertimbangkan kod berikut:

type A struct {}
type B struct {}
type AB interface { *A | *B }

func (a *A) some() bool { return true }
func (b *B) some() bool { return false }
func some[T AB](x T) bool { return x.some() } // Compilation error

Pengkompil mengadu bahawa x.beberapa tidak ditentukan, walaupun kedua-dua *A dan *B melaksanakan beberapa kaedah. Ini menimbulkan persoalan: mengapa mentakrifkan kekangan kesatuan sama sekali jika kaedah yang dikongsi tidak boleh digunakan?

Penyelesaian, seperti yang dicadangkan oleh penjejak Go, ialah menambah kaedah pada kekangan antara muka:

type AB interface { *A | *B ; some() bool }
func some[T AB](x T) bool { return x.some() } // Compiles

Walau bagaimanapun, ini adalah penyelesaian yang tidak sempurna. Kekangan kesatuan jenis Go harus membenarkan kaedah dikongsi tanpa memerlukan pengisytiharan antara muka yang jelas. Malangnya, ini adalah had Go 1.18, yang didokumenkan dalam nota keluaran:

Pengkompil Go pada masa ini hanya menyokong panggilan kaedah m pada nilai x jenis parameter jenis P jika m diisytiharkan secara eksplisit oleh antara muka kekangan P .

Had ini dijangka akan ditangani dalam Go 1.19. Sehingga itu, pembangun mesti bergantung pada penyelesaian atau menentukan antara muka bersatu untuk kaedah dikongsi.

Atas ialah kandungan terperinci Mengapa Saya Tidak Boleh Menggunakan Kaedah Dikongsi dengan Kekangan Kesatuan Go Generics?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!