CL https://golang.org/cl/22057 menyebutkan masalah ini.

Izinkan saya terlebih dahulu mengingatkan semua orang tentang kebijakan https://golang.org/wiki/NoMeToo kami. Pesta emoji ada di atas.

Ada Summary of Go Generics Discussions , yang mencoba memberikan gambaran umum tentang diskusi dari berbagai tempat. Ini juga memberikan beberapa contoh bagaimana memecahkan masalah, di mana Anda ingin menggunakan obat generik.

Ada dua "persyaratan" dalam proposal tertaut yang dapat memperumit implementasi dan mengurangi keamanan jenis:

• Definisikan tipe generik berdasarkan tipe yang tidak diketahui sampai mereka dipakai.
• Tidak memerlukan hubungan eksplisit antara definisi tipe atau fungsi generik dan penggunaannya. Artinya, program tidak harus secara eksplisit mengatakan tipe T mengimplementasikan G generik.

Persyaratan ini tampaknya mengecualikan misalnya sistem yang mirip dengan sistem sifat Rust, di mana tipe generik dibatasi oleh batas sifat. Mengapa ini dibutuhkan?

Menjadi tergoda untuk membangun obat generik ke perpustakaan standar pada tingkat yang sangat rendah, seperti dalam C++ std::basic_string, std::pengalokasi>. Ini memiliki keuntungan—jika tidak, tidak ada yang akan melakukannya—tetapi ini memiliki efek yang luas dan terkadang mengejutkan, seperti pada pesan kesalahan C++ yang tidak dapat dipahami.

Masalah dalam C++ muncul dari pengecekan tipe kode yang dihasilkan. Perlu ada pemeriksaan tipe tambahan sebelum pembuatan kode. Proposal konsep C++ memungkinkan ini dengan mengizinkan pembuat kode generik untuk menentukan persyaratan tipe generik. Dengan begitu, kompilasi dapat gagal memeriksa jenis sebelum pembuatan kode dan pesan kesalahan sederhana dapat dicetak. Masalah dengan C++ generik (tanpa konsep) adalah bahwa kode generik _adalah_ spesifikasi tipe generik. Itulah yang menciptakan pesan kesalahan yang tidak dapat dipahami.

Kode generik tidak boleh menjadi spesifikasi tipe generik.

@tamird Ini adalah fitur penting dari tipe antarmuka Go sehingga Anda dapat mendefinisikan tipe non-antarmuka T dan kemudian menentukan tipe antarmuka I sehingga T mengimplementasikan I. Lihat https://golang.org/doc/faq#implements_interface . Akan menjadi tidak konsisten jika Go mengimplementasikan suatu bentuk generik di mana tipe generik G hanya dapat digunakan dengan tipe T yang secara eksplisit mengatakan "Saya dapat digunakan untuk mengimplementasikan G."

Saya tidak akrab dengan Rust, tetapi saya tidak tahu bahasa apa pun yang mengharuskan T untuk secara eksplisit menyatakan bahwa itu dapat digunakan untuk mengimplementasikan G. Kedua persyaratan yang Anda sebutkan tidak berarti bahwa G tidak dapat memaksakan persyaratan pada T, hanya karena saya memaksakan persyaratan pada T. Persyaratan hanya berarti bahwa G dan T dapat ditulis secara independen. Itu adalah fitur yang sangat diinginkan untuk obat generik, dan saya tidak bisa membayangkan meninggalkannya.

@ianlancetaylor https://doc.rust-lang.org/book/traits.html menjelaskan sifat Rust. Sementara saya pikir mereka adalah model yang baik secara umum, mereka tidak cocok untuk Go seperti yang ada saat ini.

@sbunce Saya juga berpikir bahwa konsep adalah jawabannya, dan Anda dapat melihat ide tersebar melalui berbagai proposal sebelum yang terakhir. Tetapi mengecewakan bahwa konsep awalnya direncanakan untuk apa yang menjadi C++ 11, dan sekarang tahun 2016, dan mereka masih kontroversial dan tidak terlalu dekat untuk dimasukkan dalam bahasa C++.

Akankah ada nilai pada literatur akademis untuk panduan dalam mengevaluasi pendekatan?

Satu-satunya makalah yang saya baca tentang topik ini adalah Apakah pengembang mendapat manfaat dari tipe generik? (maaf paywall, Anda mungkin mencari cara untuk mengunduh pdf di Google) yang memiliki yang berikut untuk dikatakan

Akibatnya, interpretasi konservatif dari eksperimen
adalah bahwa tipe generik dapat dianggap sebagai tradeoff
antara karakteristik dokumentasi positif dan
karakteristik ekstensibilitas negatif. Bagian yang menarik dari
penelitian ini menunjukkan situasi di mana penggunaan a
(lebih kuat) sistem tipe statis memiliki dampak negatif pada
waktu pengembangan sementara pada saat yang sama manfaat yang diharapkan
fit – pengurangan waktu perbaikan kesalahan tipe – tidak muncul.
Kami berpikir bahwa tugas-tugas tersebut dapat membantu dalam eksperimen masa depan di
mengidentifikasi dampak dari sistem tipe.

Saya juga melihat https://github.com/golang/go/issues/15295 juga mereferensikan obat generik berorientasi objek yang ringan dan fleksibel .

Jika kita akan bersandar pada akademisi untuk memandu keputusan, saya pikir akan lebih baik untuk melakukan tinjauan literatur di awal, dan mungkin memutuskan lebih awal jika kita akan menimbang studi empiris secara berbeda dari yang mengandalkan bukti.

Silakan lihat: http://dl.acm.org/citation.cfm?id=2738008 oleh Barbara Liskov:

Dukungan untuk pemrograman generik dalam bahasa pemrograman berorientasi objek modern canggung dan tidak memiliki kekuatan ekspresif yang diinginkan. Kami memperkenalkan mekanisme generik ekspresif yang menambahkan kekuatan ekspresif dan memperkuat pemeriksaan statis, sambil tetap ringan dan sederhana dalam kasus penggunaan umum. Seperti kelas tipe dan konsep, mekanisme memungkinkan tipe yang ada untuk memodelkan batasan tipe secara retroaktif. Untuk kekuatan ekspresif, kami mengekspos model sebagai konstruksi bernama yang dapat didefinisikan dan dipilih secara eksplisit untuk menyaksikan kendala; dalam penggunaan umum dari kedermawanan, bagaimanapun, tipe secara implisit menyaksikan kendala tanpa upaya programmer tambahan.

Saya pikir apa yang mereka lakukan di sana cukup keren - saya minta maaf jika ini adalah tempat yang salah untuk berhenti tetapi saya tidak dapat menemukan tempat untuk berkomentar di /proposals dan saya tidak menemukan masalah yang sesuai di sini.

Mungkin menarik untuk memiliki satu atau lebih transpiler eksperimental - kode sumber generik Go ke kompiler kode sumber Go 1.xy.
Maksud saya - terlalu banyak bicara/argumen-untuk-pendapat saya, dan tidak ada yang menulis kode sumber yang _coba_ untuk mengimplementasikan _beberapa jenis_ obat generik untuk Go.

Hanya untuk mendapatkan pengetahuan dan pengalaman dengan Go dan obat generik - untuk melihat apa yang berhasil dan apa yang tidak.
Jika semua solusi generik Go tidak terlalu bagus, maka; Tidak ada obat generik untuk Go.

Bisakah proposal juga menyertakan implikasi pada ukuran biner dan jejak memori? Saya berharap akan ada duplikasi kode untuk setiap jenis nilai konkret sehingga pengoptimalan kompiler bekerja pada mereka. Saya berharap ada jaminan bahwa tidak akan ada duplikasi kode untuk tipe pointer beton.

Saya menawarkan matriks Keputusan Pugh. Kriteria saya termasuk dampak persepsi (kompleksitas sumber, ukuran). Saya juga memaksa peringkat kriteria untuk menentukan bobot kriteria. Anda sendiri dapat bervariasi tentu saja. Saya menggunakan "antarmuka" sebagai alternatif default dan membandingkannya dengan obat generik "salin/tempel", obat generik berbasis template (saya memikirkan sesuatu seperti cara kerja bahasa D), dan sesuatu yang saya sebut generik gaya instantiasi runtime. Saya yakin ini adalah penyederhanaan yang berlebihan. Meskipun demikian, ini mungkin memicu beberapa ide tentang cara mengevaluasi pilihan... ini harus menjadi tautan publik ke Google Sheet saya, di sini

Ping ke @yizhouzhang dan @andrewcmyers sehingga mereka dapat menyuarakan pendapat mereka tentang genus seperti obat generik di Go. Kedengarannya seperti itu bisa menjadi pasangan yang baik :)

Desain generik yang kami buat untuk Genus memiliki pemeriksaan tipe modular yang statis, tidak memerlukan deklarasi sebelumnya bahwa tipe mengimplementasikan beberapa antarmuka, dan dilengkapi dengan kinerja yang wajar. Saya pasti akan melihatnya jika Anda berpikir tentang obat generik untuk Go. Sepertinya cocok dari pemahaman saya tentang Go.

Berikut ini tautan ke makalah yang tidak memerlukan akses Perpustakaan Digital ACM:
http://www.cs.cornell.edu/andru/papers/genus/

Halaman beranda Genus ada di sini: http://www.cs.cornell.edu/projects/genus/

Kami belum merilis kompiler secara publik, tetapi kami berencana untuk melakukannya segera.

Senang menjawab pertanyaan apa pun yang dimiliki orang.

Dalam hal matriks keputusan @mandolyte , Genus mendapat skor 17, terikat untuk #1. Saya akan menambahkan beberapa kriteria lagi untuk mencetak gol. Misalnya, pemeriksaan tipe modular penting, seperti yang lainnya seperti @sbunce yang diamati di atas, tetapi skema berbasis template tidak memilikinya. Laporan teknis untuk makalah Genus memiliki tabel yang jauh lebih besar di halaman 34, membandingkan berbagai desain generik.

Saya baru saja membaca seluruh dokumen Ringkasan Go Generics , yang merupakan ringkasan bermanfaat dari diskusi sebelumnya. Mekanisme generik di Genus, menurut saya, tidak mengalami masalah yang diidentifikasi untuk C++, Java, atau C#. Genus generik direifikasi, tidak seperti di Java, sehingga Anda dapat mengetahui jenisnya saat run time. Anda juga dapat membuat instance pada tipe primitif, dan Anda tidak mendapatkan tinju implisit di tempat yang sebenarnya tidak Anda inginkan: array T di mana T adalah primitif. Sistem tipenya paling dekat dengan Haskell dan Rust -- sebenarnya sedikit lebih kuat, tapi menurut saya juga intuitif. Spesialisasi primitif ala C# saat ini tidak didukung di Genus tetapi bisa jadi. Dalam kebanyakan kasus, spesialisasi dapat ditentukan pada waktu tautan, sehingga pembuatan kode run-time yang sebenarnya tidak diperlukan.

CL https://golang.org/cl/22163 menyebutkan masalah ini.

Cara untuk membatasi tipe generik yang tidak memerlukan penambahan konsep bahasa baru: https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing.

Genus terlihat sangat keren dan jelas merupakan kemajuan seni yang penting, tetapi saya tidak melihat bagaimana hal itu akan diterapkan pada Go. Adakah yang punya sketsa bagaimana itu akan diintegrasikan dengan sistem/filosofi tipe Go?

Masalahnya adalah tim go adalah upaya penghalang. Judulnya dengan jelas menyatakan niat tim go. Dan jika itu tidak cukup untuk menghalangi semua pengambil, fitur yang dituntut dari domain yang begitu luas dalam proposal oleh ian memperjelas bahwa jika Anda menginginkan obat generik maka mereka tidak menginginkan Anda. Tidak masuk akal bahkan mencoba berdialog dengan tim go. Bagi mereka yang mencari obat generik, saya katakan patahkan bahasanya. Mulailah perjalanan baru - banyak yang akan mengikuti. Saya telah melihat beberapa pekerjaan hebat yang dilakukan di garpu. Atur diri Anda, bersatu untuk suatu tujuan

Jika ada yang ingin mencoba membuat ekstensi generik untuk Go berdasarkan desain Genus, kami dengan senang hati membantu. Kami tidak tahu Go cukup baik untuk menghasilkan desain yang selaras dengan bahasa yang ada. Saya pikir langkah pertama adalah proposal desain manusia jerami dengan contoh-contoh yang berhasil.

@andrewcmyers berharap @ianlancetaylor akan bekerja dengan Anda dalam hal itu. Hanya memiliki beberapa contoh untuk dilihat akan banyak membantu.

Saya telah membaca makalah Genus. Sejauh yang saya pahami, sepertinya bagus untuk Java, tapi sepertinya tidak cocok untuk Go.

Salah satu aspek kunci dari Go adalah ketika Anda menulis program Go, sebagian besar yang Anda tulis adalah kode. Ini berbeda dari C++ dan Java, di mana lebih banyak dari apa yang Anda tulis adalah tipe. Genus tampaknya sebagian besar tentang tipe: Anda menulis batasan dan model, bukan kode. Sistem tipe Go sangat sangat sederhana. Sistem tipe Genus jauh lebih kompleks.

Ide pemodelan retroaktif, meskipun jelas berguna untuk Java, tampaknya tidak cocok dengan Go sama sekali. Orang sudah menggunakan tipe adaptor untuk mencocokkan tipe yang ada dengan antarmuka; tidak ada lagi yang diperlukan saat menggunakan obat generik.

Akan menarik untuk melihat ide-ide ini diterapkan pada Go, tetapi saya tidak optimis dengan hasilnya.

Saya bukan ahli Go, tetapi sistem tipenya tampaknya tidak lebih sederhana daripada Java pra-generik. Sintaks tipenya sedikit lebih ringan dengan cara yang bagus tetapi kompleksitas yang mendasarinya tampaknya hampir sama.

Di Genus, batasan adalah tipe tetapi model adalah kode. Model adalah adaptor, tetapi mereka beradaptasi tanpa menambahkan lapisan pembungkus yang sebenarnya. Ini sangat berguna ketika Anda ingin, katakanlah, mengadaptasi seluruh array objek ke antarmuka baru. Pemodelan retroaktif memungkinkan Anda memperlakukan larik sebagai larik objek yang memenuhi antarmuka yang diinginkan.

Saya tidak akan terkejut jika itu lebih rumit daripada Java (pra-generik) dalam pengertian teoretis tipe, meskipun lebih sederhana untuk digunakan dalam praktik.

Selain kompleksitas relatif, mereka cukup berbeda sehingga Genus tidak dapat memetakan 1:1. Tidak ada subtipe yang sepertinya besar.

Jika Anda tertarik:

Ringkasan singkat dari perbedaan filosofis/desain relevan yang saya sebutkan terdapat dalam entri FAQ berikut:

• https://golang.org/doc/faq#implements_interface
• https://golang.org/doc/faq#overloading
• https://golang.org/doc/faq#covariant_types
• https://golang.org/doc/faq#variant_types

Tidak seperti kebanyakan bahasa, spesifikasi Go sangat singkat dan jelas tentang properti yang relevan dari sistem tipe mulai dari https://golang.org/ref/spec#Constants dan terus berlanjut hingga bagian berjudul "Blocks" (semuanya dicetak kurang dari 11 halaman).

Tidak seperti generik Java dan C#, mekanisme generik Genus tidak didasarkan pada subtipe. Di sisi lain, menurut saya Go memang memiliki subtipe, tetapi subtipe struktural. Itu juga cocok untuk pendekatan Genus, yang memiliki cita rasa struktural daripada mengandalkan hubungan yang telah dideklarasikan sebelumnya.

Saya tidak percaya bahwa Go memiliki subtipe struktural.

Sementara dua tipe yang tipe dasarnya identik karena itu identik
bisa saling menggantikan, https://play.golang.org/p/cT15aQ-PFr

Ini tidak mencakup dua jenis yang berbagi subset bidang yang sama,
https://play.golang.org/p/KrC9_BDXuh.

Pada Kam, 28 Apr 2016 jam 13:09, Andrew [email protected]
menulis:

Tidak seperti generik Java dan C#, mekanisme generik Genus tidak didasarkan pada
subtipe. Di sisi lain, menurut saya Go memang memiliki subtipe,
tetapi subtipe struktural. Itu juga cocok untuk pendekatan Genus,
yang memiliki cita rasa struktural daripada mengandalkan yang telah dinyatakan sebelumnya
hubungan.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment -215298127

Terima kasih, saya salah mengartikan beberapa bahasa tentang kapan tipe mengimplementasikan antarmuka. Sebenarnya, menurut saya antarmuka Go, dengan ekstensi sederhana, dapat digunakan sebagai batasan gaya Genus.

Itulah mengapa saya melakukan ping kepada Anda, genus sepertinya merupakan pendekatan yang jauh lebih baik daripada Java/C# seperti obat generik.

Ada beberapa ide yang berkaitan dengan spesialisasi pada tipe antarmuka; misalnya _package templates_ pendekatan "proposal" 1 2 adalah contohnya.

tl; dr; paket generik dengan spesialisasi antarmuka akan terlihat seperti:

package set
type E interface { Equal(other E) bool }
type Set struct { items []E }
func (s *Set) Add(item E) { ... }

Versi 1. dengan spesialisasi cakupan paket:

package main
import items set[[E: *Item]]

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs items.Set
xs.Add(&Item{})

Versi 2. spesialisasi cakupan deklarasi:

package main
import set

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs set.Set[[E: *Item]]
xs.Add(&Item{})

Obat generik yang dicakup paket akan mencegah orang menyalahgunakan sistem generik secara signifikan, karena penggunaannya terbatas pada algoritme dasar dan struktur data. Ini pada dasarnya mencegah membangun abstraksi bahasa dan kode fungsional baru.

Spesialisasi cakupan deklarasi memiliki lebih banyak kemungkinan dengan biaya sehingga lebih rentan terhadap penyalahgunaan dan lebih bertele-tele. Tetapi, kode fungsional dimungkinkan, misalnya:

type E interface{}
func Reduce(zero E, items []E, fn func(a, b E) E) E { ... }

Reduce[[E: int]](0, []int{1,2,3,4}, func(a, b int)int { return a + b } )
// there are probably ways to have some aliases (or similar) to make it less verbose
alias ReduceInt Reduce[[E: int]]
func ReduceInt Reduce[[E: int]]

Pendekatan spesialisasi antarmuka memiliki properti yang menarik:

• Paket yang sudah ada menggunakan antarmuka akan dapat dispesialisasikan. misalnya saya akan dapat memanggil sort.Sort[[Interface:MyItems]](...) dan memiliki pekerjaan penyortiran pada tipe beton bukan antarmuka (dengan potensi keuntungan dari inlining).
• Pengujian disederhanakan, saya hanya perlu memastikan bahwa kode generik berfungsi dengan antarmuka.
• Sangat mudah untuk menyatakan cara kerjanya. yaitu bayangkan [[E: int]] mengganti semua deklarasi E dengan int .

Tapi, ada masalah verbositas saat bekerja di seluruh paket:

type op
import "set"

type E interface{}
func Union(a, b set.Set[[set.E: E]]) set.Set[[set.E: E]] {
    result := set.New[[set.E: E]]()
    ...
}

_Tentu saja, semuanya lebih sederhana untuk dinyatakan daripada diimplementasikan. Secara internal mungkin ada banyak masalah dan cara bagaimana itu bisa bekerja._

_PS, untuk para gerutuan tentang kemajuan obat generik yang lambat, saya memuji Tim Go karena menghabiskan lebih banyak waktu untuk masalah yang memiliki manfaat lebih besar bagi komunitas, misalnya bug kompiler/runtime, SSA, GC, http2._

@egonelbre poin Anda bahwa obat generik tingkat paket akan mencegah "penyalahgunaan" adalah hal yang sangat penting yang menurut saya diabaikan oleh kebanyakan orang. Itu ditambah kesederhanaan semantik dan sintaksis relatif mereka (hanya paket dan konstruksi impor yang terpengaruh) membuatnya sangat menarik untuk Go.

@andrewcymyers menarik bahwa menurut Anda antarmuka Go berfungsi sebagai batasan gaya Genus. Saya akan berpikir mereka masih memiliki masalah bahwa Anda tidak dapat mengungkapkan batasan parameter multi-tipe dengan mereka.

Namun, satu hal yang baru saya sadari adalah bahwa di Go Anda dapat menulis antarmuka sebaris. Jadi dengan sintaks yang tepat, Anda dapat menempatkan antarmuka dalam cakupan semua parameter dan menangkap batasan multi-parameter:

ketik [V, E] Grafik [V antarmuka { Tepi() E }, E antarmuka { Titik akhir() (V, V) }] ...

Saya pikir masalah yang lebih besar dengan antarmuka sebagai kendala adalah bahwa metode tidak meresap di Go seperti di Jawa. Tipe bawaan tidak memiliki metode. Tidak ada kumpulan metode universal seperti yang ada di java.lang.Object. Pengguna biasanya tidak mendefinisikan metode seperti Equals atau HashCode pada tipe mereka kecuali mereka secara khusus membutuhkannya, karena metode tersebut tidak memenuhi syarat untuk digunakan sebagai kunci peta, atau dalam algoritme apa pun yang membutuhkan kesetaraan.

(Kesetaraan di Go adalah cerita yang menarik. Bahasa memberi jenis Anda "==" jika memenuhi persyaratan tertentu (lihat https://golang.org/ref/spec#Logical_operators, cari "sebanding"). Jenis apa pun dengan " =" dapat berfungsi sebagai kunci peta. Tetapi jika jenis Anda tidak layak mendapatkan "==", maka tidak ada yang dapat Anda tulis yang akan membuatnya berfungsi sebagai kunci peta.)

Karena metode tidak meresap, dan karena tidak ada cara mudah untuk mengekspresikan properti dari tipe bawaan (seperti operator yang mereka gunakan), saya menyarankan untuk menggunakan kode itu sendiri sebagai mekanisme batasan umum. Lihat tautan di komentar saya tanggal 18 April di atas. Proposal ini memiliki masalah, tetapi satu fitur yang bagus adalah bahwa kode numerik generik masih dapat menggunakan operator biasa, alih-alih pemanggilan metode yang rumit.

Cara lain adalah menambahkan metode ke tipe yang tidak memilikinya. Anda dapat melakukan ini dalam bahasa yang ada dengan cara yang jauh lebih ringan daripada di Jawa:

ketik Int ke
func (i Int) Lebih sedikit(j Int) bool { kembali i < j }

Jenis Int "mewarisi" semua operator dan properti int lainnya. Meskipun Anda harus melakukan cast di antara keduanya untuk menggunakan Int dan int bersama-sama, yang bisa jadi menyusahkan.

Model genus dapat membantu di sini. Tetapi mereka harus dibuat sangat sederhana. Saya pikir @ianlancetaylor terlalu sempit dalam mengkarakterisasi Go karena menulis lebih banyak kode, lebih sedikit tipe. Prinsip umum adalah bahwa Go membenci kompleksitas. Kami melihat Java dan C++ dan bertekad untuk tidak pernah pergi ke sana. (Tanpa bermaksud menyinggung.)

Jadi satu ide cepat untuk fitur seperti model adalah: minta pengguna menulis tipe seperti Int di atas, dan dalam instantiasi umum izinkan "int dengan Int", artinya gunakan tipe int tetapi perlakukan seperti Int. Kemudian tidak ada konstruksi bahasa terbuka yang disebut model, dengan kata kuncinya, semantik pewarisan, dan sebagainya. Saya tidak memahami model dengan cukup baik untuk mengetahui apakah ini layak, tetapi ini lebih dalam semangat Go.

@jba Kami tentu setuju dengan prinsip menghindari kompleksitas. "Sesederhana mungkin tapi tidak sesederhana itu." Saya mungkin akan meninggalkan beberapa fitur Genus dari Go dengan alasan itu, setidaknya pada awalnya.

Salah satu hal bagus tentang pendekatan Genus adalah ia menangani tipe bawaan dengan lancar. Ingat bahwa tipe primitif di Java tidak memiliki metode, dan Genus mewarisi perilaku ini. Sebaliknya, Genus memperlakukan tipe primitif _seolah-olah_ mereka memiliki rangkaian metode yang cukup besar untuk tujuan memenuhi batasan. Tabel hash mensyaratkan bahwa kuncinya dapat di-hash dan dibandingkan, tetapi semua tipe primitif memenuhi batasan ini. Jadi, ketik instantiasi seperti Map[int, boolean] benar-benar legal tanpa perlu repot lagi. Tidak perlu membedakan antara dua rasa bilangan bulat (int vs Int) untuk mencapai ini. Namun, jika int tidak dilengkapi dengan operasi yang cukup untuk beberapa penggunaan, kami akan menggunakan model yang hampir persis seperti penggunaan Int di atas.

Hal lain yang layak disebutkan adalah gagasan "model alami" di Genus. Anda biasanya tidak perlu mendeklarasikan model untuk menggunakan tipe generik: jika argumen tipe memenuhi batasan, model alami dibuat secara otomatis. Pengalaman kami adalah bahwa ini adalah kasus yang biasa; menyatakan eksplisit, model bernama biasanya tidak diperlukan. Tetapi jika model diperlukan — misalnya, jika Anda ingin hash int dengan cara yang tidak standar — maka sintaksnya mirip dengan yang Anda sarankan: Map[int with fancyHash, boolean] . Saya berpendapat bahwa Genus secara sintaksis ringan dalam kasus penggunaan normal tetapi dengan daya cadangan saat diperlukan.

@egonelbre Apa yang Anda usulkan di sini terlihat seperti tipe virtual, yang didukung oleh Scala. Ada makalah ECOOP'97 oleh Kresten Krab Thorup, "Genericity in Java with virtual types", yang mengeksplorasi arah ini. Kami juga mengembangkan mekanisme untuk tipe virtual dan kelas virtual dalam pekerjaan kami ("J&: persimpangan bersarang untuk komposisi perangkat lunak yang dapat diskalakan", OOPSLA'06).

Karena inisialisasi literal meresap di Go, saya harus bertanya-tanya seperti apa fungsi literal itu. Saya menduga bahwa kode untuk menangani ini sebagian besar ada di Go generate, fix, dan rename.Mungkin itu akan menginspirasi seseorang :-)

// definisi tipe func (generik)
ketik Sum64 func (X, Y) float64 {
kembali float64(X) + float64(Y)
}

// instantiate satu, secara posisi
saya := 42
var ju uint = 86
jumlah := &Jumlah64{i, j}

// instantiate satu, dengan tipe parameter bernama
jumlah := &Jumlah64{ X: int, Y: uint}

// sekarang gunakan...
hasil := jumlah(i, j) // hasil 128

Usulan Ian menuntut terlalu banyak. Kami tidak mungkin mengembangkan semua fitur sekaligus, itu akan ada dalam keadaan yang belum selesai selama berbulan-bulan.

Sementara itu, proyek yang belum selesai tidak dapat disebut bahasa Go resmi sampai selesai karena akan berisiko memecah ekosistem.

Jadi pertanyaannya adalah bagaimana merencanakan ini.

Juga sebagian besar proyek akan mengembangkan korpus referensi.
mengembangkan koleksi generik yang sebenarnya, algoritme, dan hal-hal lain sedemikian rupa sehingga kita semua sepakat bahwa mereka idiomatik, saat menggunakan fitur go 2.0 yang baru

Sintaks yang mungkin?

// Module defining generic type
module list(type t)

type node struct {
    next *node
    data t
}

// Module using generic type:
import (
    intlist "module/path/to/list" (int)
    funclist "module/path/to/list" (func (int) int)
)

l := intlist.New()
l.Insert(5)

@md2perpe , sintaks bukanlah bagian yang sulit dari masalah ini. Bahkan, sejauh ini yang paling mudah. Silakan lihat diskusi dan dokumen terkait di atas.

@ md2perpe Kami telah membahas parametrizing seluruh paket ("modul") sebagai cara untuk generik secara internal - ini tampaknya menjadi cara untuk mengurangi overhead sintaksis. Tetapi memiliki masalah lain; misalnya, tidak jelas bagaimana seseorang akan mengukurnya dengan tipe yang bukan level paket. Tapi idenya mungkin masih layak untuk ditelusuri secara detail.

Saya ingin berbagi perspektif: Di alam semesta paralel, semua tanda tangan fungsi Go selalu dibatasi untuk hanya menyebutkan jenis antarmuka, dan alih-alih permintaan untuk obat generik hari ini, ada satu cara untuk menghindari tipuan yang terkait dengan nilai antarmuka. Pikirkan bagaimana Anda akan memecahkan masalah itu (tanpa mengubah bahasa). Saya punya beberapa ide.

@thwd Jadi, penulis perpustakaan akan terus menggunakan antarmuka, tetapi tanpa pengalihan jenis dan jenis pernyataan yang diperlukan saat ini. Dan akankah pengguna perpustakaan hanya meneruskan tipe konkret seolah-olah perpustakaan akan menggunakan tipe apa adanya... dan kemudian apakah kompiler akan mendamaikan keduanya? Dan jika itu tidak bisa menyatakan mengapa? (seperti operator modulo digunakan di perpustakaan, tetapi pengguna menyediakan sepotong sesuatu.

Apakah saya dekat? :-)

@mandolyte ya! mari bertukar email agar tidak mencemari thread ini. Anda dapat menghubungi saya di "saya di thwd dot me". Siapa pun yang membaca ini yang mungkin tertarik; kirimi saya email dan saya akan menambahkan Anda ke utas.

Ini fitur hebat untuk type system dan collection library .
Sintaks potensial:

type Element<T> struct {
    prev, next *Element<T>
    list *List<T>
    value T
}
type List<E> struct {
    root Element<E>
    len int
}

Untuk interface

type Collection<E> interface {
    Size() int
    Add(e E) bool
}

super type atau type implement :

func contain(l List<parent E>, e E) bool
<V> func (c Collection<child E>)Map(fn func(e E) V) Collection

Di atas alias di Jawa:

boolean contain(List<? super E>, E e)
<V> Collection Map(Function<? extend E, V> mapFunc);

@leaxoy seperti yang dikatakan sebelumnya, sintaks bukanlah bagian yang sulit di sini. Lihat pembahasan di atas.

Perlu diketahui bahwa biaya antarmuka luar biasa besar.

Tolong jelaskan mengapa menurut Anda biaya antarmuka "luar biasa"
besar.
Seharusnya tidak lebih buruk daripada panggilan virtual non-khusus C++.

@minux Saya tidak bisa mengatakan tentang biaya kinerja tetapi dalam kaitannya dengan kualitas kode. interface{} tidak dapat diverifikasi pada waktu kompilasi tetapi obat generik bisa. Menurut pendapat saya ini, dalam banyak kasus, lebih penting daripada masalah kinerja menggunakan interface{} .

@xoviat

Sebenarnya tidak ada kerugian untuk ini karena pemrosesan yang diperlukan untuk ini tidak memperlambat kompiler.

Ada (setidaknya) dua kelemahan.

Salah satunya adalah peningkatan pekerjaan untuk linker: jika spesialisasi untuk dua jenis menghasilkan kode mesin dasar yang sama, kami tidak ingin mengompilasi dan menautkan dua salinan kode itu.

Lain adalah bahwa paket parameter kurang ekspresif daripada metode parameter. (Lihat proposal yang ditautkan dari komentar pertama untuk detailnya.)

Apakah tipe hiper adalah ide yang bagus?

func getAddFunc (aType type) func(aType, aType) aType {
    return func(a, b aType) aType {
        return a+b
    }
}

Apakah tipe hiper adalah ide yang bagus?

Apa yang Anda gambarkan di sini cukup ketik parameterisasi ala C++ (yaitu, templat). Itu tidak mengetik-periksa secara modular karena tidak ada cara untuk mengetahui bahwa tipe aType memiliki operasi + dari informasi yang diberikan. Parameterisasi tipe terbatas seperti pada CLU, Haskell, Java, Genus adalah solusinya.

@ golang101 Saya memiliki proposal terperinci di sepanjang baris itu. Saya akan mengirim CL untuk menambahkannya ke daftar, tetapi sepertinya tidak akan diadopsi.

CL https://golang.org/cl/38731 menyebutkan masalah ini.

@andrewcmyers

Itu tidak mengetik-periksa secara modular karena tidak ada cara untuk mengetahui bahwa tipe aType memiliki operasi + dari informasi yang diberikan.

Tentu ada. Batasan itu tersirat dalam definisi fungsi, dan batasan bentuk itu dapat disebarkan ke semua pemanggil waktu kompilasi (transitif) dari getAddFunc .

Batasan bukan bagian dari _type_ Go — yaitu, tidak dapat dikodekan dalam sistem tipe bagian run-time bahasa — tetapi itu tidak berarti bahwa itu tidak dapat dievaluasi secara modular.

Menambahkan proposal saya sebagai 2016-09-compile-time-functions.md .

Saya tidak berharap itu akan diadopsi, tetapi setidaknya bisa menjadi referensi yang menarik.

@bcmils Saya merasa bahwa fungsi waktu kompilasi adalah ide yang kuat, terlepas dari pertimbangan obat generik. Misalnya, saya menulis pemecah sudoku yang membutuhkan popcount. Untuk mempercepatnya, saya menghitung popcount untuk berbagai kemungkinan nilai dan menyimpannya sebagai Go source . Ini adalah sesuatu yang mungkin dilakukan dengan go:generate . Tetapi jika ada fungsi waktu kompilasi, tabel pencarian itu juga dapat dihitung pada waktu kompilasi, menjaga kode yang dihasilkan mesin dari keharusan untuk dikomit ke repo. Secara umum, setiap jenis fungsi matematika memoizable cocok untuk tabel pencarian yang dibuat sebelumnya dengan fungsi waktu kompilasi.

Secara lebih spekulatif, seseorang mungkin juga ingin, misalnya, mengunduh definisi protobuf dari sumber kanonik dan menggunakannya untuk membangun tipe pada waktu kompilasi. Tapi mungkin itu terlalu banyak untuk dilakukan pada waktu kompilasi?

Saya merasa fungsi waktu kompilasi terlalu kuat dan terlalu lemah pada saat yang sama: mereka terlalu fleksibel dan dapat membuat kesalahan dengan cara yang aneh / memperlambat kompilasi seperti yang dilakukan template C++, tetapi di sisi lain mereka terlalu statis dan sulit untuk beradaptasi dengan hal-hal seperti fungsi kelas satu.

Untuk bagian kedua, saya tidak melihat cara Anda dapat membuat sesuatu seperti "sepotong fungsi yang memproses irisan dari tipe tertentu dan mengembalikan satu elemen", atau dalam sintaks ad-hoc []func<T>([]T) T , yang sangat mudah dilakukan pada dasarnya setiap bahasa fungsional yang diketik secara statis. Apa yang benar-benar dibutuhkan adalah nilai yang dapat mengambil tipe parametrik, bukan pembuatan kode tingkat kode sumber.

@bunsim

Untuk bagian kedua, saya tidak melihat cara Anda dapat membuat sesuatu seperti "sepotong fungsi yang memproses irisan dari tipe tertentu dan mengembalikan satu elemen",

Jika Anda berbicara tentang parameter tipe tunggal, dalam proposal saya yang akan ditulis:

const func SliceOfSelectors(T gotype) gotype { return []func([]T)T (type) }

Jika Anda berbicara tentang pencampuran parameter tipe dan parameter nilai, tidak, proposal saya tidak mengizinkan untuk itu: bagian dari titik fungsi waktu kompilasi adalah untuk dapat beroperasi pada nilai tanpa kotak, dan jenis parametrik run-time Saya pikir Anda menggambarkan cukup banyak membutuhkan tinju nilai.

Yup, tapi menurut saya hal seperti itu yang membutuhkan tinju harus diizinkan dengan tetap menjaga keamanan jenis, mungkin dengan sintaks khusus yang menunjukkan "kotak". Sebagian besar penambahan "generik" adalah untuk menghindari jenis-ketidakamanan interface{} bahkan ketika overhead interface{} tidak dapat dihindari. (Mungkin hanya mengizinkan konstruksi tipe parametrik tertentu dengan pointer dan tipe antarmuka yang "sudah" dikotak? Objek kotak Integer dll Java tidak sepenuhnya merupakan ide yang buruk, meskipun irisan tipe nilai rumit)

Saya hanya merasa seperti fungsi waktu kompilasi sangat mirip C++, dan akan sangat mengecewakan bagi orang-orang seperti saya yang mengharapkan Go2 memiliki sistem tipe parametrik modern yang didasarkan pada teori tipe suara daripada peretasan berdasarkan memanipulasi potongan kode sumber yang ditulis dalam bahasa tanpa generik.

@bcmils
Apa yang Anda usulkan tidak akan bersifat modular. Jika modul A menggunakan modul B, yang menggunakan modul C, yang menggunakan modul D, perubahan pada cara parameter tipe digunakan di D mungkin perlu disebarkan kembali ke A, bahkan jika pelaksana A tidak mengetahui bahwa D ada di dalam sistem. Kopling longgar yang disediakan oleh sistem modul akan melemah, dan perangkat lunak akan lebih rapuh. Ini adalah salah satu masalah dengan template C++.

Jika, di sisi lain, tanda tangan tipe menangkap persyaratan pada parameter tipe, seperti dalam bahasa seperti CLU, ML, Haskell, atau Genus, sebuah modul dapat dikompilasi tanpa akses ke internal modul yang bergantung padanya.

@bunsim

Bagian besar dari menambahkan "generik" sebenarnya adalah untuk menghindari tipe-ketidakamanan antarmuka{} bahkan ketika overhead antarmuka{} tidak dapat dihindari.

"tidak dapat dihindari" adalah relatif. Perhatikan bahwa overhead tinju adalah poin # 3 dalam posting Russ dari 2009 (https://research.swtch.com/generic).

mengharapkan Go2 memiliki sistem tipe parametrik modern yang didasarkan pada teori tipe suara daripada peretasan berdasarkan memanipulasi potongan kode sumber

"Teori tipe suara" yang baik adalah deskriptif, bukan preskriptif. Proposal saya khususnya diambil dari kalkulus lambda orde kedua (sepanjang baris Sistem F), di mana gotype adalah singkatan dari jenis type dan seluruh sistem jenis orde pertama diangkat ke dalam yang kedua -order ("waktu kompilasi") jenis.

Ini juga terkait dengan karya teori tipe modal Davies, Pfenning, et al di CMU. Untuk beberapa latar belakang, saya akan mulai dengan Analisis Modal Komputasi Bertahap dan Jenis Modal sebagai Spesifikasi Pementasan untuk Pembuatan Kode Run-time .

Memang benar bahwa teori tipe yang mendasari proposal saya kurang ditentukan secara formal daripada dalam literatur akademis, tetapi itu tidak berarti itu tidak ada.

@andrewcmyers

Jika modul A menggunakan modul B, yang menggunakan modul C, yang menggunakan modul D, perubahan pada cara parameter tipe digunakan di D mungkin perlu disebarkan kembali ke A, bahkan jika pelaksana A tidak mengetahui bahwa D ada di dalam sistem.

Itu sudah benar di Go hari ini: jika Anda perhatikan dengan cermat, Anda akan melihat bahwa file objek yang dihasilkan oleh kompiler untuk paket Go yang diberikan menyertakan informasi tentang bagian dependensi transitif yang memengaruhi API yang diekspor.

Kopling longgar yang disediakan oleh sistem modul akan melemah, dan perangkat lunak akan lebih rapuh.

Saya pernah mendengar argumen yang sama yang digunakan untuk menganjurkan mengekspor tipe interface daripada tipe konkret di Go API, dan kebalikannya ternyata lebih umum: abstraksi prematur membatasi tipe dan menghalangi ekstensi API. (Untuk satu contoh seperti itu, lihat #19584.) Jika Anda ingin mengandalkan garis argumen ini, saya pikir Anda perlu memberikan beberapa contoh konkret.

Ini adalah salah satu masalah dengan template C++.

Seperti yang saya lihat, masalah utama dengan template C++ adalah (tanpa urutan tertentu):

• Ambiguitas sintaksis yang berlebihan.
  sebuah. Ambiguitas antara nama tipe dan nama nilai.
  B. Dukungan yang terlalu luas untuk kelebihan beban operator, yang menyebabkan melemahnya kemampuan untuk menyimpulkan kendala dari penggunaan operator.
• Ketergantungan yang berlebihan pada resolusi yang berlebihan untuk metaprogramming (atau, secara setara, evolusi ad-hoc dari dukungan metaprogramming).
  sebuah. Terutama wrt referensi-runtuh aturan.
• Penerapan prinsip SFINAE yang terlalu luas, menyebabkan kendala yang sangat sulit untuk disebarkan dan terlalu banyak persyaratan implisit dalam definisi tipe, yang menyebabkan pelaporan kesalahan yang sangat sulit.
• Terlalu sering menggunakan token-paste dan inklusi tekstual (preprosesor C) alih-alih substitusi AST dan artefak kompilasi tingkat tinggi (yang untungnya tampaknya setidaknya sebagian ditangani dengan Modul).
• Kurangnya bahasa bootstrap yang baik untuk kompiler C++, menyebabkan pelaporan kesalahan yang buruk dalam garis keturunan kompiler yang berumur panjang (misalnya, toolchain GCC).
• Penggandaan (dan terkadang perkalian) nama yang dihasilkan dari pemetaan set operator ke "konsep" bernama berbeda (daripada memperlakukan operator itu sendiri sebagai kendala mendasar).

Saya telah mengkode dalam C++ dan selama satu dekade sekarang dan saya senang membahas kekurangan C++ secara panjang lebar, tetapi fakta bahwa dependensi program bersifat transitif tidak pernah berada jauh di dekat bagian atas daftar keluhan saya.

Di sisi lain, perlu memperbarui rantai dependensi O(N) hanya untuk menambahkan satu metode ke tipe di modul A dan dapat menggunakannya di modul D? Itu jenis masalah yang memperlambat saya secara teratur. Di mana parametrik dan kopling longgar bertentangan, saya akan memilih parametrik setiap hari.

Namun, saya sangat yakin bahwa metaprogramming dan polimorfisme parametrik harus dipisahkan, dan kebingungan C++ tentang mereka adalah akar penyebab mengapa template C++ mengganggu. Sederhananya, C++ mencoba untuk menerapkan ide teori tipe menggunakan makro pada dasarnya pada steroid, yang sangat bermasalah karena programmer suka menganggap template sebagai polimorfisme parametrik nyata dan terkena perilaku tak terduga. Fungsi waktu kompilasi adalah ide bagus untuk metaprogramming dan mengganti hack yang go generate , tapi saya tidak percaya itu harus menjadi cara yang diberkati untuk melakukan pemrograman generik.

Polimorfisme parametrik "nyata" membantu kopling longgar dan tidak boleh bertentangan dengannya. Itu juga harus terintegrasi erat dengan sistem tipe lainnya; misalnya mungkin harus diintegrasikan ke dalam sistem antarmuka saat ini, sehingga banyak penggunaan jenis antarmuka dapat ditulis ulang menjadi hal-hal seperti:

func <T io.Reader> ReadAll(in T)

yang harus menghindari overhead antarmuka (seperti penggunaan Rust), meskipun dalam hal ini tidak terlalu berguna.

Contoh yang lebih baik mungkin paket sort , di mana Anda dapat memiliki sesuatu seperti

func <T Comparable> Sort(slice []T)

di mana Comparable hanyalah antarmuka lama yang bagus yang dapat diimplementasikan oleh tipe. Sort kemudian dapat dipanggil pada sepotong tipe nilai yang mengimplementasikan Comparable , tanpa memasukkannya ke dalam tipe antarmuka.

@bcmills Ketergantungan transitif yang tidak dibatasi oleh sistem tipe, menurut saya, merupakan inti dari beberapa keluhan Anda tentang C++. Ketergantungan transitif tidak terlalu menjadi masalah jika Anda mengontrol modul A, B, C, dan D. Secara umum, Anda sedang mengembangkan modul A dan mungkin hanya sedikit menyadari bahwa modul D ada di bawah sana, dan sebaliknya, pengembang D mungkin tidak menyadari A. Jika modul D sekarang, tanpa membuat perubahan apa pun pada deklarasi yang terlihat di D, mulai menggunakan beberapa operator baru pada parameter tipe—atau hanya menggunakan parameter tipe itu sebagai argumen tipe ke modul baru E dengan miliknya sendiri batasan implisit—kendala tersebut akan meresap ke semua klien, yang mungkin tidak menggunakan argumen tipe yang memenuhi batasan. Tidak ada yang memberi tahu pengembang D bahwa mereka mengacaukannya. Akibatnya, Anda memiliki semacam inferensi tipe global, dengan semua kesulitan debugging yang menyertainya.

Saya percaya pendekatan yang kami ambil di Genus [ PLDI'15 ] jauh lebih baik. Parameter tipe memiliki batasan eksplisit, tetapi ringan (saya mengerti maksud Anda tentang mendukung batasan operasi; CLU menunjukkan bagaimana melakukannya dengan benar sejak tahun 1977). Pengecekan tipe genus sepenuhnya modular. Kode generik dapat dikompilasi hanya sekali untuk mengoptimalkan ruang kode atau khusus untuk argumen tipe tertentu untuk kinerja yang baik.

@andrewcmyers

Jika modul D sekarang, tanpa membuat perubahan apa pun pada deklarasi yang terlihat di D, mulai menggunakan beberapa operator baru pada parameter tipe […] [klien] mungkin tidak menggunakan argumen tipe yang memenuhi batasan. Tidak ada yang memberi tahu pengembang D bahwa mereka mengacaukannya.

Tentu, tapi itu sudah berlaku untuk banyak kendala implisit di Go yang terlepas dari mekanisme pemrograman umum apa pun.

Misalnya, suatu fungsi dapat menerima parameter tipe antarmuka dan awalnya memanggil metodenya secara berurutan. Jika fungsi itu kemudian berubah untuk memanggil metode tersebut secara bersamaan (dengan memunculkan goroutine tambahan), batasan "harus aman untuk penggunaan bersamaan" tidak tercermin dalam sistem tipe.

Demikian pula, sistem tipe Go saat ini tidak menentukan batasan pada masa pakai variabel: beberapa implementasi io.Writer secara keliru menganggap mereka dapat menyimpan referensi ke irisan yang diteruskan dan membacanya nanti (misalnya dengan melakukan penulisan aktual secara asinkron di goroutine latar belakang), tetapi hal itu menyebabkan balapan data jika pemanggil Write mencoba menggunakan kembali backing slice yang sama untuk Write berikutnya.

Atau fungsi yang menggunakan sakelar tipe mungkin mengambil jalur berbeda dari metode yang ditambahkan ke salah satu tipe di sakelar.

Atau fungsi yang memeriksa kode kesalahan tertentu mungkin rusak jika fungsi yang menghasilkan kesalahan mengubah cara melaporkan kondisi tersebut. (Misalnya, lihat https://github.com/golang/go/issues/19647.)

Atau fungsi yang memeriksa jenis kesalahan tertentu mungkin rusak jika pembungkus di sekitar kesalahan ditambahkan atau dihapus (seperti yang terjadi pada paket net standar di Go 1.5).

Atau buffering pada saluran yang diekspos dalam API dapat berubah, menyebabkan kebuntuan dan/atau balapan.

...dan seterusnya.

Go tidak biasa dalam hal ini: batasan implisit ada di mana-mana dalam program dunia nyata.

Jika Anda mencoba menangkap semua batasan yang relevan dalam anotasi eksplisit, maka Anda akan berakhir di salah satu dari dua arah.

Di satu arah, Anda membangun sistem tipe dan anotasi dependen yang kompleks dan sangat komprehensif, dan anotasi tersebut akhirnya merekapitulasi sebagian besar kode yang mereka anotasi. Seperti yang saya harap Anda dapat melihat dengan jelas, arah itu sama sekali tidak sesuai dengan desain bahasa Go lainnya: Go lebih menyukai kesederhanaan spesifikasi dan keringkasan kode daripada pengetikan statis yang komprehensif.

Di arah lain, anotasi eksplisit hanya akan mencakup sebagian dari batasan yang relevan untuk API tertentu. Sekarang anotasi memberikan rasa aman yang salah: kode masih dapat rusak karena perubahan batasan implisit, tetapi adanya batasan eksplisit menyesatkan pengembang untuk berpikir bahwa setiap perubahan "jenis-aman" juga mempertahankan kompatibilitas.

Tidak jelas bagi saya mengapa stabilitas API semacam itu perlu dicapai melalui anotasi kode sumber eksplisit: jenis stabilitas API yang Anda gambarkan juga dapat dicapai (dengan lebih sedikit redundansi dalam kode) melalui analisis kode sumber. Misalnya, Anda dapat membayangkan alat api menganalisis kode dan menghasilkan serangkaian batasan yang jauh lebih kaya daripada yang dapat diekspresikan dalam sistem tipe bahasa formal, dan memberikan alat guru kemampuan untuk mengkueri kumpulan batasan yang dihitung untuk setiap fungsi, metode, atau parameter API yang diberikan.

@bcmils Bukankah Anda menjadikan yang sempurna sebagai musuh dari yang baik? Ya, ada batasan implisit yang sulit ditangkap dalam sistem tipe. (Dan desain modular yang baik menghindari pengenalan batasan implisit seperti itu jika memungkinkan.) Akan sangat bagus jika memiliki analisis menyeluruh yang dapat memeriksa semua properti yang ingin Anda periksa secara statis -- dan memberikan penjelasan yang jelas dan tidak menyesatkan kepada pemrogram tentang di mana mereka sedang membuat kesalahan. Bahkan dengan kemajuan terbaru pada diagnosis kesalahan otomatis dan lokalisasi , saya tidak menahan napas. Untuk satu hal, alat analisis hanya dapat menganalisis kode yang Anda berikan. Pengembang tidak selalu memiliki akses ke semua kode yang mungkin terhubung dengan kode mereka.

Jadi di mana ada kendala yang mudah ditangkap dalam sistem tipe, mengapa tidak memberi pemrogram kemampuan untuk menuliskannya? Kami memiliki 40 tahun pengalaman pemrograman dengan parameter tipe yang dibatasi secara statis. Ini adalah anotasi statis intuitif sederhana yang terbayar.

Setelah Anda mulai membangun perangkat lunak yang lebih besar yang melapisi modul perangkat lunak, Anda mulai ingin menulis komentar yang menjelaskan batasan implisit seperti itu. Dengan asumsi ada cara yang baik dan dapat diperiksa untuk mengekspresikannya, mengapa tidak membiarkan kompiler terlibat dalam lelucon sehingga dapat membantu Anda?

Saya perhatikan bahwa beberapa contoh kendala implisit Anda lainnya melibatkan penanganan kesalahan. Saya pikir pemeriksaan pengecualian statis ringan kami [ PLDI 2016 ] akan membahas contoh-contoh ini.

@andrewcmyers

Jadi di mana ada kendala yang mudah ditangkap dalam sistem tipe, mengapa tidak memberi pemrogram kemampuan untuk menuliskannya?
[…]
Setelah Anda mulai membangun perangkat lunak yang lebih besar yang melapisi modul perangkat lunak, Anda mulai ingin menulis komentar yang menjelaskan batasan implisit seperti itu. Dengan asumsi ada cara yang baik dan dapat diperiksa untuk mengekspresikannya, mengapa tidak membiarkan kompiler terlibat dalam lelucon sehingga dapat membantu Anda?

Saya sebenarnya setuju sepenuhnya dengan poin ini, dan saya sering menggunakan argumen serupa dalam hal manajemen memori. (Jika Anda tetap harus mendokumentasikan invarian pada aliasing dan retensi data, mengapa tidak menerapkan invarian tersebut pada waktu kompilasi?)

Tapi saya akan mengambil argumen itu satu langkah lebih jauh: kebalikannya juga berlaku! Jika Anda _tidak_ perlu menulis komentar untuk kendala (karena jelas dalam konteks untuk manusia yang bekerja dengan kode), mengapa Anda harus menulis komentar itu untuk kompiler? Terlepas dari preferensi pribadi saya, penggunaan pengumpulan sampah dan nilai nol oleh Go dengan jelas menunjukkan bias terhadap "tidak mengharuskan pemrogram untuk menyatakan invarian yang jelas". Mungkin saja pemodelan gaya Genus dapat mengekspresikan banyak kendala yang akan diungkapkan dalam komentar, tetapi bagaimana hasilnya dalam hal menghilangkan kendala yang juga akan dihilangkan dalam komentar?

Tampaknya bagi saya bahwa model gaya Genus lebih dari sekadar komentar: mereka benar-benar mengubah semantik kode dalam beberapa kasus, mereka tidak hanya membatasinya. Sekarang kita akan memiliki dua mekanisme yang berbeda — antarmuka dan model tipe — untuk parameterisasi perilaku. Itu akan mewakili perubahan besar dalam bahasa Go: kami telah menemukan beberapa praktik terbaik untuk antarmuka dari waktu ke waktu (seperti "menentukan antarmuka di sisi konsumen") dan tidak jelas bahwa pengalaman itu akan diterjemahkan ke sistem yang sangat berbeda, bahkan mengabaikan kompatibilitas Go 1.

Lebih jauh lagi, salah satu keunggulan Go adalah spesifikasinya dapat dibaca (dan dipahami secara luas) dalam satu sore. Tidak jelas bagi saya bahwa sistem batasan gaya Genus dapat ditambahkan ke bahasa Go tanpa memperumitnya secara substansial — saya akan penasaran untuk melihat proposal konkret untuk perubahan pada spesifikasi.

Inilah titik data yang menarik untuk "pemrograman meta". Akan lebih baik untuk tipe tertentu dalam paket sync dan atomic — yaitu, atomic.Value dan sync.Map — untuk mendukung metode CompareAndSwap , tetapi itu hanya berfungsi untuk tipe yang kebetulan sebanding. Sisa dari atomic.Value dan sync.Map API tetap berguna tanpa metode tersebut, jadi untuk kasus penggunaan itu kita memerlukan sesuatu seperti SFINAE (atau jenis API yang ditentukan bersyarat lainnya) atau harus jatuh kembali ke hierarki tipe yang lebih kompleks.

Saya ingin membuang ide sintaksis kreatif ini menggunakan suku kata asli.

@bcmils Bisakah Anda menjelaskan lebih lanjut tentang tiga poin ini?

1. Ambiguitas antara nama tipe dan nama nilai.
2. Dukungan yang terlalu luas untuk kelebihan beban operator
   3. Ketergantungan yang berlebihan pada resolusi yang berlebihan untuk metaprogramming

@mahdix Tentu.

1. Ambiguitas antara nama tipe dan nama nilai.

Artikel ini memberikan pengantar yang bagus. Untuk mengurai program C++, Anda harus mengetahui nama mana yang merupakan tipe dan mana yang merupakan nilai. Saat Anda mengurai program C++ berpola, Anda tidak memiliki informasi yang tersedia untuk anggota parameter templat.

Masalah serupa muncul di Go untuk literal komposit, tetapi ambiguitas adalah antara nilai dan nama bidang daripada nilai dan tipe. Dalam kode Go ini:

const a = someValue
x := T{a: b}

apakah a adalah nama bidang literal, atau apakah itu konstanta a yang digunakan sebagai kunci peta atau indeks larik?

1. Dukungan yang terlalu luas untuk kelebihan beban operator

Pencarian yang bergantung pada argumen adalah tempat yang baik untuk memulai. Kelebihan operator di C++ dapat terjadi sebagai metode pada tipe penerima atau sebagai fungsi bebas di salah satu dari beberapa ruang nama, dan aturan untuk menyelesaikan kelebihan tersebut cukup rumit.

Ada banyak cara untuk menghindari kerumitan itu, tetapi yang paling sederhana (seperti yang dilakukan Go saat ini) adalah dengan melarang operator kelebihan beban sepenuhnya.

1. Ketergantungan yang berlebihan pada resolusi yang berlebihan untuk metaprogramming

Pustaka <type_traits> adalah tempat yang baik untuk memulai. Lihat implementasi di lingkungan ramah Anda libc++ untuk melihat bagaimana resolusi yang berlebihan berperan.

Jika Go mendukung metaprogramming (dan bahkan itu sangat diragukan), saya tidak akan mengharapkannya melibatkan resolusi yang berlebihan sebagai operasi dasar untuk menjaga definisi bersyarat.

@bcmils
Karena saya belum pernah menggunakan C++, dapatkah Anda menjelaskan di mana kelebihan beban operator melalui penerapan 'antarmuka' yang telah ditentukan sebelumnya dalam hal kompleksitas. Python dan Kotlin adalah contohnya.

Saya pikir ADL itu sendiri adalah masalah besar dengan templat C++ yang sebagian besar tidak disebutkan, karena mereka memaksa kompiler untuk menunda resolusi semua nama hingga waktu instantiasi, dan dapat menghasilkan bug yang sangat halus, sebagian karena "ideal" dan " kompiler lazy" berperilaku berbeda di sini dan standar mengizinkannya. Fakta bahwa ia mendukung kelebihan beban operator sejauh ini bukanlah bagian terburuknya.

Proposal ini didasarkan pada Template, sistem untuk ekspansi makro tidak akan cukup? Saya tidak berbicara tentang go generate atau proyek seperti gottemplate. Saya berbicara tentang lebih banyak seperti ini:

macro MacroFoo(stmt ast.Statement) {
    ....
}

Makro bisa mengurangi boilerplate dan penggunaan refleksi.

Saya pikir C++ adalah contoh yang cukup baik bahwa obat generik tidak boleh didasarkan pada templat atau makro. Terutama mengingat Go memiliki hal-hal seperti fungsi anonim yang benar-benar tidak dapat "dibuat" pada waktu kompilasi kecuali sebagai pengoptimalan.

@samadadi Anda bisa menyampaikan maksud Anda tanpa mengatakan "ada apa dengan kalian". Karena itu, argumen kompleksitas telah dikemukakan beberapa kali.

Go bukanlah bahasa pertama yang mencoba mencapai kesederhanaan dengan menghilangkan dukungan untuk polimorfisme parametrik (generik), meskipun fitur tersebut menjadi semakin penting selama 40 tahun terakhir -- menurut pengalaman saya, ini adalah pokok dari kursus pemrograman semester kedua.

Masalah dengan tidak memiliki fitur dalam bahasa adalah bahwa programmer akhirnya beralih ke solusi yang lebih buruk. Misalnya, pemrogram Go sering menulis templat kode yang diperluas secara makro untuk menghasilkan kode "asli" untuk berbagai jenis yang diinginkan. Tetapi bahasa pemrograman yang sebenarnya adalah yang Anda ketik, bukan yang dilihat oleh kompiler. Jadi strategi ini secara efektif berarti Anda menggunakan bahasa (tidak lagi standar) yang memiliki semua kerapuhan dan kode yang membengkak dari template C++.

Seperti yang tercantum di https://blog.golang.org/toward-go2 kita perlu menyediakan "laporan pengalaman", sehingga kebutuhan dan tujuan desain dapat ditentukan. Bisakah Anda meluangkan beberapa menit dan mendokumentasikan kasus makro yang telah Anda amati?

Harap menjaga bug ini pada topik dan sipil. Dan lagi, https://golang.org/wiki/NoMeToo. Harap hanya berkomentar jika Anda memiliki informasi unik dan konstruktif untuk ditambahkan.

@mandolyte Sangat mudah untuk menemukan penjelasan terperinci di web yang menganjurkan pembuatan kode sebagai pengganti (sebagian) untuk obat generik:
https://appliedgo.net/generics/
https://www.calhoun.io/using-code-generation-to-survive-without-generics-in-go/
http://blog.ralch.com/tutorial/golang-code-generation-and-generics/

Jelas ada banyak orang di luar sana yang mengambil pendekatan ini.

@andrewcmyers , ada beberapa batasan serta peringatan kenyamanan saat menggunakan pembuatan kode TAPI .
Secara umum - jika Anda yakin pendekatan ini terbaik/cukup baik, saya pikir upaya untuk memungkinkan generasi yang agak mirip dari dalam rantai alat go akan menjadi berkah.

• Pengoptimalan kompiler mungkin menjadi tantangan dalam kasus ini, tetapi runtime akan konsisten, DAN pemeliharaan kode, pengalaman pengguna (kesederhanaan...), praktik terbaik standar, dan standar kode terpadu dapat dipertahankan.
  Selain itu - semua rantai alat akan tetap sama, selain dari alat debugging (profiler , langkah debugger dll) yang akan melihat baris kode yang tidak ditulis oleh pengembang, tapi itu sedikit seperti masuk ke kode ASM saat debugging - hanya ini adalah kode yang dapat dibaca :) .

Kelemahan - tidak ada preseden (yang saya tahu) untuk pendekatan ini di dalam go tool chain .

Singkatnya - pertimbangkan pembuatan kode sebagai bagian dari proses build , seharusnya tidak terlalu rumit, cukup aman, runtime dioptimalkan, dapat menjaga kesederhanaan dan perubahan bahasa yang sangat kecil.

IMHO: Ini adalah kompromi yang mudah dicapai, dengan harga murah.

Untuk lebih jelasnya, saya tidak menganggap pembuatan kode gaya makro, baik yang dilakukan dengan gen, cpp, gofmt -r, atau alat makro/templat lainnya, sebagai solusi yang baik untuk masalah generik bahkan jika distandarisasi. Ini memiliki masalah yang sama dengan template C++: kode mengasapi, kurangnya pemeriksaan tipe modular, dan kesulitan debugging. Ini menjadi lebih buruk saat Anda mulai, seperti biasa, membangun kode generik dalam hal kode generik lainnya. Menurut saya, keuntungannya terbatas: itu akan membuat hidup relatif sederhana untuk penulis kompiler Go dan menghasilkan kode yang efisien — kecuali ada tekanan cache instruksi, situasi yang sering terjadi dalam perangkat lunak modern!

Saya pikir intinya adalah bahwa pembuatan kode digunakan untuk menggantikan
obat generik, jadi obat generik harus berusaha memecahkan sebagian besar kasus penggunaan tersebut.

Pada Rabu, 26 Juli 2017, 22:41 Andrew Myers, [email protected] menulis:

Untuk lebih jelasnya, saya tidak mempertimbangkan pembuatan kode gaya makro, apakah sudah selesai
dengan gen, cpp, gofmt -r, atau alat makro/templat lainnya, untuk menjadi baik
solusi untuk masalah generik bahkan jika standar. Ini memiliki hal yang sama
masalah sebagai template C++: kode mengasapi, kurangnya pemeriksaan tipe modular, dan
kesulitan debugging. Ini menjadi lebih buruk saat Anda mulai, seperti biasa, membangun
kode generik dalam hal kode generik lainnya. Menurut saya, kelebihannya adalah
terbatas: itu akan membuat hidup relatif sederhana untuk penulis kompiler Go
dan itu menghasilkan kode yang efisien — kecuali ada cache instruksi
tekanan, situasi yang sering terjadi dalam perangkat lunak modern!

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-318242016 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

Tidak diragukan lagi pembuatan kode bukanlah solusi NYATA bahkan jika dibungkus dengan beberapa dukungan bahasa untuk membuat tampilan dan nuansa sebagai "bagian dari bahasa"

Maksud saya adalah SANGAT hemat biaya.

Btw, jika Anda melihat beberapa pengganti pembuatan kode, Anda dapat dengan mudah melihat bagaimana mereka bisa jauh lebih mudah dibaca, lebih cepat, dan tidak memiliki beberapa konsep yang salah (misalnya iterasi pada array pointer vs nilai) jika bahasa memberi mereka alat yang lebih baik untuk ini.

Dan mungkin itu jalan yang lebih baik untuk diselesaikan dalam jangka pendek, yang tidak akan terasa seperti tambalan:
sebelum memikirkan "dukungan generik terbaik yang juga akan menjadi idiomatik untuk digunakan" (saya percaya beberapa implementasi di atas akan memakan waktu bertahun-tahun untuk mencapai integrasi penuh), implementasikan beberapa set fungsi yang didukung "dalam bahasa" yang bagaimanapun juga diperlukan (seperti build in struktur salinan dalam) akan membuat solusi penghasil kode ini jauh lebih bermanfaat.

Setelah membaca proposal generik oleh @bcmills dan @ianlancetaylor , saya membuat pengamatan berikut:

Fungsi Waktu Kompilasi dan Tipe Kelas Satu

Saya menyukai ide evaluasi waktu kompilasi, tetapi saya tidak melihat manfaat dari membatasinya pada fungsi murni. Proposal ini memperkenalkan gotype , tetapi membatasi penggunaannya pada fungsi const dan tipe data apa pun yang ditentukan dalam cakupan fungsi. Dari perspektif pengguna perpustakaan, instantiasi terbatas pada fungsi konstruktor seperti "Baru", dan mengarah ke tanda tangan fungsi seperti ini:

const func New(K, V gotype, hashfn Hashfn(K), eqfn Eqfn(K)) func()*Hashmap(K, V, hashfn, eqfn)

Tipe kembalian di sini tidak dapat dipisahkan menjadi tipe fungsi karena kita terbatas pada fungsi murni. Selain itu, tanda tangan mendefinisikan dua "tipe" baru dalam tanda tangan itu sendiri (K dan V), yang berarti bahwa untuk mengurai satu parameter, kita harus menguraikan seluruh daftar parameter. Ini bagus untuk kompiler, tetapi saya ingin tahu apakah menambah kompleksitas pada API publik suatu paket.

Ketik Parameter di Go

Jenis parameter memungkinkan untuk sebagian besar kasus penggunaan pemrograman generik, misalnya kemampuan untuk mendefinisikan struktur data generik dan operasi atas tipe data yang berbeda. Proposal secara lengkap mencantumkan peningkatan pada pemeriksa tipe yang akan diperlukan untuk menghasilkan kesalahan kompilasi yang lebih baik, waktu kompilasi yang lebih cepat, dan binari yang lebih kecil.

Di bawah bagian "Pemeriksa Jenis," proposal juga mencantumkan beberapa batasan jenis yang berguna untuk mempercepat proses, seperti "Dapat diindeks", "Sebanding", "Dapat Dipanggil", "Komposit", dll... Yang tidak saya mengerti adalah mengapa tidak mengizinkan pengguna menentukan batasan tipe mereka sendiri? Usulan tersebut menyatakan bahwa

Tidak ada batasan tentang bagaimana tipe berparameter dapat digunakan dalam fungsi berparameter.

Namun, jika pengidentifikasi memiliki lebih banyak batasan yang terkait dengannya, bukankah itu akan membantu kompiler? Mempertimbangkan:

HashMap[Anything,Anything] // Compiler must always compare the implementation and usages to make sure this is valid.

vs

HashMap[Comparable,Anything] // Compiler can first filter out instantiations for incomparable types before running an exhaustive check.

Memisahkan batasan tipe dari parameter tipe dan mengizinkan batasan yang ditentukan pengguna juga dapat meningkatkan keterbacaan, membuat paket generik lebih mudah dipahami. Menariknya, kekurangan yang tercantum di akhir proposal mengenai kompleksitas aturan pengurangan tipe sebenarnya dapat dikurangi jika aturan tersebut secara eksplisit didefinisikan oleh pengguna.

@smasher164

Saya menyukai ide evaluasi waktu kompilasi, tetapi saya tidak melihat manfaat dari membatasinya pada fungsi murni.

Manfaatnya adalah memungkinkan kompilasi terpisah. Jika fungsi waktu kompilasi dapat mengubah status global, maka kompiler harus memiliki status tersebut tersedia, atau membuat jurnal pengeditannya sedemikian rupa sehingga penaut dapat mengurutkannya pada waktu tautan. Jika fungsi waktu kompilasi dapat mengubah status lokal, maka kita memerlukan beberapa cara untuk melacak status mana yang lokal vs. global. Keduanya menambah kerumitan, dan tidak jelas apakah keduanya akan memberikan manfaat yang cukup untuk mengimbanginya.

@smasher164

Apa yang saya tidak mengerti adalah mengapa tidak mengizinkan pengguna menentukan batasan tipe mereka sendiri?

Pembatasan jenis dalam proposal itu sesuai dengan operasi dalam sintaks bahasa. Itu mengurangi luas permukaan fitur baru: tidak perlu menentukan sintaks tambahan untuk tipe pembatas, karena semua batasan sintaksis dapat disimpulkan dari penggunaan.

jika pengidentifikasi memiliki lebih banyak batasan yang terkait dengannya, bukankah itu akan membantu kompiler?

Bahasa harus dirancang untuk penggunanya, bukan untuk penyusun-penulis.

tidak perlu menentukan sintaks tambahan untuk tipe pembatas karena semua batasan sintaksis dapat disimpulkan dari penggunaan.

Ini adalah rute C++ turun. Ini membutuhkan analisis program global untuk mengidentifikasi penggunaan yang relevan. Kode tidak dapat dijelaskan oleh programmer secara modular, dan pesan kesalahan bertele-tele dan tidak dapat dipahami.

Ini bisa sangat mudah dan ringan untuk menentukan operasi yang dibutuhkan. Lihat CLU (1977) sebagai contoh.

@andrewcmyers

Ini membutuhkan analisis program global untuk mengidentifikasi penggunaan yang relevan. Kode tidak dapat dijelaskan oleh programmer secara modular,

Itu menggunakan definisi khusus "modular", yang menurut saya tidak universal seperti yang Anda asumsikan. Di bawah proposal 2013, setiap fungsi atau jenis akan memiliki serangkaian batasan yang jelas yang disimpulkan dari bawah ke atas dari paket yang diimpor, dengan cara yang persis sama dengan run-time (dan batasan run-time) dari fungsi non-parametrik diturunkan dari bawah- naik dari rantai panggilan hari ini.

Anda mungkin dapat menanyakan batasan yang disimpulkan menggunakan guru atau alat serupa, dan itu dapat menjawab pertanyaan tersebut menggunakan informasi lokal dari metadata paket yang diekspor.

dan pesan kesalahan bertele-tele dan tidak dapat dipahami.

Kami memiliki beberapa contoh (GCC dan MSVC) yang menunjukkan bahwa pesan kesalahan yang dibuat secara naif tidak dapat dipahami. Saya pikir itu berlebihan untuk menganggap bahwa pesan kesalahan untuk kendala implisit secara intrinsik buruk.

Saya pikir kelemahan terbesar dari batasan yang disimpulkan adalah mereka membuatnya mudah untuk menggunakan tipe dengan cara yang memperkenalkan batasan tanpa sepenuhnya memahaminya. Dalam kasus terbaik, ini hanya berarti bahwa pengguna Anda mungkin mengalami kegagalan waktu kompilasi yang tidak terduga, tetapi dalam kasus terburuk, ini berarti Anda dapat merusak paket untuk konsumen dengan memperkenalkan batasan baru secara tidak sengaja. Batasan yang ditentukan secara eksplisit akan menghindari hal ini.

Saya pribadi juga tidak merasa bahwa batasan eksplisit tidak sejalan dengan pendekatan Go yang ada, karena antarmuka adalah batasan tipe runtime eksplisit, meskipun mereka memiliki ekspresivitas terbatas.

Kami memiliki beberapa contoh (GCC dan MSVC) yang menunjukkan bahwa pesan kesalahan yang dibuat secara naif tidak dapat dipahami. Saya pikir itu berlebihan untuk menganggap bahwa pesan kesalahan untuk kendala implisit secara intrinsik buruk.

Daftar kompiler di mana inferensi tipe non-lokal - yang Anda usulkan - menghasilkan pesan kesalahan yang buruk sedikit lebih lama dari itu. Ini termasuk SML, OCaml, dan GHC, di mana banyak upaya telah dilakukan untuk meningkatkan pesan kesalahan mereka dan di mana setidaknya ada beberapa struktur modul eksplisit yang membantu. Anda mungkin dapat melakukan lebih baik, dan jika Anda menemukan algoritme untuk pesan kesalahan yang baik dengan skema yang Anda usulkan, Anda akan memiliki publikasi yang bagus. Sebagai titik awal menuju algoritme itu, Anda mungkin menemukan makalah POPL 2014 dan PLDI 2015 kami tentang lokalisasi kesalahan berguna. Mereka kurang lebih canggih.

karena semua kendala sintaksis dapat disimpulkan dari penggunaan.

Bukankah itu membatasi luasnya program generik yang dapat diperiksa tipenya? Misalnya, perhatikan bahwa proposal tipe-params tidak menentukan batasan "Dapat diubah". Dalam bahasa saat ini, ini akan sesuai dengan irisan atau saluran, tetapi tipe komposit (misalnya daftar tertaut) tidak selalu memenuhi persyaratan tersebut. Mendefinisikan antarmuka seperti

type Iterable[T] interface {
    Next() T
}

membantu kasus daftar tertaut, tetapi sekarang irisan bawaan dan jenis saluran harus diperluas untuk memenuhi antarmuka ini.

Batasan yang mengatakan "Saya menerima kumpulan semua jenis yang dapat berupa Iterable, irisan, atau saluran" tampaknya seperti situasi win-win-win bagi pengguna, pembuat paket, dan pelaksana kompiler. Poin yang saya coba sampaikan adalah bahwa batasan adalah superset dari program yang valid secara sintaksis, dan beberapa mungkin tidak masuk akal dari perspektif bahasa, tetapi hanya dari perspektif API.

Bahasa harus dirancang untuk penggunanya, bukan untuk penyusun-penulis.

Saya setuju, tapi mungkin saya harus mengungkapkannya secara berbeda. Peningkatan efisiensi kompiler bisa menjadi efek samping dari batasan yang ditentukan pengguna. Manfaat utamanya adalah keterbacaan, karena pengguna memiliki gagasan yang lebih baik tentang perilaku API mereka daripada kompiler. Tradeoff di sini adalah bahwa program generik harus sedikit lebih eksplisit tentang apa yang mereka terima.

Bagaimana jika alih-alih

type Iterable[T] interface {
    Next() T
}

kami memisahkan gagasan "antarmuka" dari "kendala". Maka kita mungkin memiliki

type T generic

type Iterable class {
    Next() T
}

di mana "class" berarti kelas tipe gaya Haskell, bukan kelas gaya Java.

Memiliki "kelas tipe" yang terpisah dari "antarmuka" dapat membantu menjernihkan beberapa ketidak-ortogonalan dari kedua gagasan tersebut. Kemudian Sortable (mengabaikan sort.Interface) mungkin terlihat seperti:

type T generic

type Comparable class {
    Less(a, b T) bool
}

type Sortable class {
    Next() Comparable
}

Berikut adalah beberapa umpan balik ke bagian "Ketik kelas dan konsep" di Genus oleh @andrewcmyers dan penerapannya untuk Go.

Bagian ini membahas keterbatasan kelas tipe dan konsep, dengan menyatakan:

pertama, kepuasan kendala harus disaksikan secara unik

Saya tidak yakin saya memahami batasan ini. Tidakkah mengikat batasan ke pengidentifikasi terpisah mencegahnya menjadi unik untuk tipe tertentu? Tampak bagi saya bahwa klausa "di mana" dalam Genus pada dasarnya membangun tipe/batasan dari batasan yang diberikan, tetapi ini tampaknya analog dengan membuat instance variabel dari tipe yang diberikan. Batasan dengan cara ini menyerupai sejenis .

Berikut adalah penyederhanaan definisi kendala yang dramatis, yang disesuaikan dengan Go:

kind Any interface{} // accepts any type that satisfies interface{}.
type T Any // Declare a type of Any kind. Also binds it to an identifier.
kind Eq T == T // accepts any type for which equality is defined.

Jadi deklarasi peta akan muncul sebagai:

type Map[K Eq, V Any] struct {
}

di mana di Genus, itu bisa terlihat seperti:

type Map[K, V] where Eq[K], Any[V] struct {
}

dan dalam proposal Type-Params yang ada akan terlihat seperti:

type Map[K,V] struct {
}

Saya pikir kita semua bisa setuju bahwa mengizinkan batasan untuk memanfaatkan sistem tipe yang ada dapat menghilangkan tumpang tindih antara fitur bahasa, dan membuatnya mudah untuk memahami yang baru.

dan kedua, model mereka menentukan bagaimana mengadaptasi satu tipe, sedangkan dalam bahasa dengan subtipe, setiap tipe yang diadaptasi secara umum mewakili semua subtipenya.

Batasan ini tampaknya kurang relevan dengan Go karena bahasa tersebut sudah memiliki aturan konversi yang baik antara tipe bernama/tidak bernama dan antarmuka yang tumpang tindih.

Contoh yang diberikan mengusulkan model sebagai solusi, yang tampaknya menjadi fitur yang berguna tetapi tidak diperlukan untuk Go. Jika perpustakaan mengharapkan suatu tipe untuk mengimplementasikan http.Handler misalnya, dan pengguna menginginkan perilaku yang berbeda tergantung pada konteksnya, menulis adaptor itu sederhana:

type handleFunc func(http.ResponseWriter, *http.Request)
func (f handlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w,r) }

Sebenarnya, inilah yang dilakukan perpustakaan standar .

@smasher164

pertama, kepuasan kendala harus disaksikan secara unik
Saya tidak yakin saya memahami batasan ini. Tidakkah mengikat batasan ke pengidentifikasi terpisah mencegahnya menjadi unik untuk tipe tertentu?

Idenya adalah bahwa di Genus Anda dapat memenuhi batasan yang sama dengan tipe yang sama di lebih dari satu cara, tidak seperti di Haskell. Misalnya, jika Anda memiliki HashSet[T] , Anda dapat menulis HashSet[String] ke string hash dengan cara biasa tetapi HashSet[String with CaseInsens] ke hash dan membandingkan string dengan CaseInsens model, yang mungkin memperlakukan string dengan cara yang tidak peka huruf besar-kecil. Genus sebenarnya membedakan kedua jenis ini; ini mungkin berlebihan untuk Go. Bahkan jika sistem tipe tidak melacaknya, tampaknya masih penting untuk dapat mengesampingkan operasi default yang disediakan oleh suatu tipe.

kind Any interface{} // menerima semua tipe yang memenuhi antarmuka{}.
type T Any // Mendeklarasikan tipe Any kind. Juga mengikatnya ke pengidentifikasi.
jenis Persamaan T == T // menerima jenis apa pun yang persamaannya didefinisikan.
ketik Map[K Eq, V Any] struct { ...
}

Persamaan moral dari ini dalam Genus adalah:

constraint Any[T] {}
// Just use Any as if it were a type
constraint Eq[K] {
   boolean equals(K);
}
class Map[K, V] where Eq[K] { ... }

Di Familia kami hanya akan menulis:

interface Eq {
    boolean equals(This);
}
class Map[K where Eq, V] { ... }

Sunting: mencabut ini demi solusi berbasis refleksi seperti yang dijelaskan dalam # 4146 Solusi berbasis generik seperti yang saya jelaskan di bawah tumbuh secara linier dalam jumlah komposisi. Sementara solusi berbasis refleksi akan selalu memiliki cacat kinerja, ia dapat mengoptimalkan dirinya sendiri saat runtime sehingga cacatnya konstan terlepas dari jumlah komposisi.

Ini bukan proposal tetapi kasus penggunaan potensial untuk dipertimbangkan saat merancang proposal.

Dua hal yang umum dalam kode Go hari ini

• membungkus nilai antarmuka untuk menyediakan fungsionalitas tambahan (membungkus http.ResponseWriter untuk kerangka kerja)
• memiliki metode opsional yang terkadang dimiliki nilai antarmuka (seperti Temporary() bool pada net.Error )

Ini baik dan berguna tetapi mereka tidak bercampur. Setelah Anda membungkus antarmuka, Anda kehilangan kemampuan untuk mengakses metode apa pun yang tidak ditentukan pada jenis pembungkusnya. Artinya, diberikan

type MyError struct {
  error
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.error)
}

Jika Anda membungkus kesalahan dalam struct itu, Anda menyembunyikan metode tambahan apa pun pada kesalahan asli.

Jika Anda tidak membungkus kesalahan dalam struct, Anda tidak dapat memberikan konteks tambahan.

Katakanlah proposal umum yang diterima memungkinkan Anda mendefinisikan sesuatu seperti berikut (sintaks arbitrer yang saya coba buat dengan sengaja jelek sehingga tidak ada yang akan fokus padanya)

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.E)
}

Dengan memanfaatkan penyematan, kami dapat menyematkan jenis beton apa pun yang memenuhi antarmuka kesalahan dan keduanya membungkusnya dan memiliki akses ke metode lainnya. Sayangnya ini hanya membuat kita setengah jalan ke sana.

Yang benar-benar kita butuhkan di sini adalah mengambil nilai sembarang dari antarmuka kesalahan dan menyematkan tipe dinamisnya.

Ini segera menimbulkan dua kekhawatiran

• tipenya harus dibuat saat runtime (mungkin diperlukan oleh refleksi)
• pembuatan tipe harus panik jika nilai kesalahannya nihil

Jika itu belum membuat Anda berpikir, Anda juga memerlukan mekanisme untuk "melompati" antarmuka ke tipe dinamisnya, baik dengan anotasi dalam daftar parameter generik untuk mengatakan "selalu instantiate pada tipe dinamis dari nilai antarmuka " atau dengan beberapa fungsi ajaib yang hanya dapat dipanggil selama instantiasi tipe untuk membuka kotak antarmuka sehingga jenis dan nilainya dapat disambungkan dengan benar.

Tanpa itu, Anda hanya membuat instance MyError pada jenis kesalahan itu sendiri, bukan pada jenis antarmuka yang dinamis.

Katakanlah kita memiliki fungsi ajaib unbox untuk ditarik dan (entah bagaimana) menerapkan informasi:

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  return MyError{
    E: unbox(err),
    extraContext: ec,
  }
}

Sekarang katakanlah kita memiliki kesalahan non-nil, err , yang tipe dinamisnya adalah *net.DNSError . Lalu ini

wrapped := wrap(getExtraContext(), err)
//wrapped 's dynamic type is a MyStruct embedding E=*net.DNSError
_, ok := wrapped.(net.Error)
fmt.Println(ok)

akan mencetak true . Tetapi jika tipe dinamis dari err adalah *os.PathError itu akan dicetak salah.

Saya harap semantik yang diusulkan jelas mengingat sintaks tumpul yang digunakan dalam demonstrasi.

Saya juga berharap ada cara yang lebih baik untuk menyelesaikan masalah itu dengan mekanisme dan upacara yang lebih sedikit, tetapi saya pikir cara di atas bisa berhasil.

@jimmyfrasche Jika saya mengerti apa yang Anda inginkan, ini adalah mekanisme adaptasi tanpa pembungkus. Anda ingin dapat memperluas kumpulan operasi yang ditawarkan suatu tipe tanpa membungkusnya dengan objek lain yang menyembunyikan aslinya. Ini adalah fungsi yang ditawarkan Genus.

@andrewcmyers no.

Struct di Go memungkinkan penyematan. Jika Anda menambahkan bidang tanpa nama tetapi dengan tipe ke struct, ia melakukan dua hal: Ini membuat bidang dengan nama yang sama dengan jenisnya dan memungkinkan pengiriman transparan ke metode apa pun dari jenis itu. Kedengarannya sangat seperti warisan tetapi tidak. Jika Anda memiliki tipe T yang memiliki metode Foo() maka berikut ini setara

type S struct {
  T
}

dan

type S struct {
  T T
}
func (s S) Foo() {
  s.T.Foo()
}

(ketika Foo disebut "ini" selalu bertipe T).

Anda juga dapat menyematkan antarmuka dalam struct. Ini memberikan struct semua metode dalam kontrak antarmuka (meskipun Anda perlu menetapkan beberapa nilai dinamis ke bidang implisit atau itu akan menyebabkan kepanikan dengan pengecualian pointer nol yang setara)

Go memiliki antarmuka yang mendefinisikan kontrak dalam istilah metode tipe. Nilai jenis apa pun yang memenuhi kontrak dapat dimasukkan ke dalam nilai antarmuka itu. Nilai antarmuka adalah penunjuk ke manifes tipe internal (tipe dinamis) dan penunjuk ke nilai tipe dinamis itu (nilai dinamis). Anda dapat melakukan jenis pernyataan pada nilai antarmuka untuk (a) mendapatkan nilai dinamis jika Anda menegaskan ke jenis non-antarmuka atau (b) mendapatkan nilai antarmuka baru jika Anda menegaskan ke antarmuka yang berbeda bahwa nilai dinamis juga memenuhi. Itu umum untuk menggunakan yang terakhir untuk "menguji fitur" suatu objek untuk melihat apakah itu mendukung metode opsional. Untuk menggunakan kembali contoh sebelumnya, beberapa kesalahan memiliki metode "Temporary() bool" sehingga Anda dapat melihat apakah ada kesalahan yang bersifat sementara dengan:

func isTemp(err error) bool {
  if t, ok := err.(interface{ Temporary() bool}); ok {
    return t.Temporary()
  }
  return false
}

Itu juga umum untuk membungkus jenis dalam jenis lain untuk menyediakan fitur tambahan. Ini berfungsi baik dengan tipe non-antarmuka. Saat Anda membungkus antarmuka, Anda juga menyembunyikan metode yang tidak Anda ketahui dan Anda tidak dapat memulihkannya dengan pernyataan tipe "uji fitur": tipe yang dibungkus hanya memperlihatkan metode antarmuka yang diperlukan meskipun memiliki metode opsional . Mempertimbangkan:

type A struct {}
func (A) Foo()
func (A) Bar()

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

Anda tidak dapat memanggil Bar pada i atau bahkan mengetahui bahwa itu ada kecuali Anda tahu bahwa tipe dinamis saya adalah B sehingga Anda dapat membukanya dan membuka bidang I untuk mengetikkan pernyataan itu .

Ini menyebabkan masalah nyata, terutama berurusan dengan antarmuka umum seperti kesalahan, atau Pembaca.

Jika ada cara untuk mengangkat tipe dan nilai dinamis dari antarmuka (dalam beberapa cara yang aman dan terkendali), Anda dapat membuat parameter tipe baru dengan itu, menyetel bidang yang disematkan ke nilai, dan mengembalikan antarmuka baru. Kemudian Anda mendapatkan nilai yang memenuhi antarmuka asli, memiliki fungsionalitas yang ditingkatkan yang ingin Anda tambahkan, tetapi sisa metode dari tipe dinamis asli masih ada untuk diuji fitur.

@jimmyfrasche Memang. Apa Genus memungkinkan Anda lakukan adalah menggunakan satu jenis untuk memenuhi kontrak "antarmuka" tanpa tinju itu. Nilai masih memiliki tipe aslinya dan operasi aslinya. Lebih lanjut, program dapat menentukan operasi mana yang harus digunakan tipe untuk memenuhi kontrak -- secara default, ini adalah operasi yang disediakan tipe, tetapi program dapat menyediakan operasi baru jika tipe tidak memiliki operasi yang diperlukan. Itu juga dapat menggantikan operasi yang akan digunakan oleh tipe tersebut.

@jimmyfrasche @andrewcmyers Untuk kasus penggunaan itu, lihat juga https://github.com/golang/go/issues/4146#issuecomment -318200547.

@jimmyfrasche Bagi saya, sepertinya masalah utama di sini adalah mendapatkan tipe/nilai dinamis dari suatu variabel. Mengesampingkan embedding, contoh yang disederhanakan adalah

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  e E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.e)
}

Nilai yang ditetapkan ke e harus memiliki tipe dinamis (atau konkret) seperti *net.DNSError , yang mengimplementasikan error . Berikut adalah beberapa kemungkinan cara perubahan bahasa di masa mendatang dapat mengatasi masalah ini:

1. Memiliki fungsi ajaib unbox -seperti yang mengungkap nilai dinamis variabel. Ini berlaku untuk semua jenis yang tidak konkret, misalnya serikat pekerja.
2. Jika perubahan bahasa mendukung variabel tipe, sediakan sarana untuk mendapatkan tipe dinamis dari variabel. Dengan informasi tipe, kita dapat menulis sendiri fungsi unbox . Sebagai contoh,

func unbox(v T1) T2 {
    t := dynTypeOf(v)
    return v.(t)
}

wrap dapat ditulis dengan cara yang sama seperti sebelumnya, atau sebagai

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  t := dynTypeOf(err)
  return MyError{
    e: v.(t),
    extraContext: ec,
  }
}

1. Jika perubahan bahasa mendukung batasan tipe, berikut adalah ide alternatif:

type E1 which_is_a_type_satisfying error
type E2 which_is_a_type_satisfying error

func wrap(ec extraContext, err E1) E2 {
  if err == nil {
    return nil
  }
  return MyError{
    e: err,
    extraContext: ec,
  }
}

Dalam contoh ini, kami menerima nilai jenis apa pun yang mengimplementasikan kesalahan. Setiap pengguna wrap yang mengharapkan error akan menerimanya. Namun, jenis e di dalam MyError sama dengan err yang diteruskan, yang tidak terbatas pada jenis antarmuka. Jika seseorang menginginkan perilaku yang sama dengan 2,

var iface error = ...
wrap(getExtraContext(), unbox(iface))

Karena tampaknya tidak ada orang lain yang melakukannya, saya ingin menunjukkan "laporan pengalaman" yang sangat jelas untuk obat generik seperti yang diminta oleh https://blog.golang.org/toward-go2.

Yang pertama adalah tipe map bawaan:

m := make(map[string]string)

Berikutnya adalah tipe chan bawaan:

c := make(chan bool)

Akhirnya, perpustakaan standar dipenuhi dengan alternatif interface{} di mana obat generik akan bekerja lebih aman:

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• sync.Map mendatang (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Mungkin ada orang lain yang saya lewatkan. Intinya, masing-masing di atas adalah di mana saya berharap obat generik berguna.

(Catatan: Saya tidak menyertakan sort.Sort di sini karena ini adalah contoh yang sangat baik tentang bagaimana antarmuka dapat digunakan daripada generik.)

http://www.yinwang.org/blog-cn/2014/04/18/golang
Saya pikir generik itu penting. Jika tidak, tidak dapat menangani tipe yang serupa. Kadang-kadang antarmuka tidak dapat menyelesaikan masalah.

Sintaks sederhana dan sistem tipe adalah kelebihan penting dari Go. Jika Anda menambahkan obat generik, bahasa akan menjadi berantakan seperti Scala atau Haskell. Juga fitur ini akan menarik fanboy pseudo-akademik, yang pada akhirnya akan mengubah nilai-nilai komunitas dari "Ayo selesaikan ini" menjadi "Ayo bicara tentang teori dan matematika CS". Hindari obat generik, ini adalah jalan menuju jurang maut.

@bxqgit tolong jaga kesopanan ini. Tidak perlu menghina siapa pun.

Adapun apa yang akan terjadi di masa depan, kita akan lihat, tetapi saya tahu bahwa selama 98% waktu saya, saya tidak membutuhkan obat generik, kapan pun saya membutuhkannya, saya berharap dapat menggunakannya. Bagaimana mereka digunakan vs bagaimana mereka digunakan secara salah adalah diskusi yang berbeda. Mendidik pengguna harus menjadi bagian dari proses.

@bxqgit
Ada situasi di mana generik diperlukan, seperti struktur data generik (Pohon, Tumpukan, Antrian, ...) atau fungsi generik (Peta, Filter, Kurangi, ...) dan hal-hal ini tidak dapat dihindari, menggunakan antarmuka alih-alih generik dalam situasi ini hanya menambah kompleksitas besar baik untuk penulis kode dan pembaca kode dan juga memiliki efek buruk pada efisiensi kode saat run-time sehingga harus jauh lebih rasional untuk menambahkan ke bahasa generik daripada mencoba menggunakan antarmuka dan mencerminkan untuk menulis kompleks dan kode yang tidak efisien.

@bxqgit Menambahkan obat generik tidak selalu menambah kompleksitas bahasa, ini dapat dicapai dengan sintaks sederhana juga. Dengan obat generik, Anda menambahkan batasan tipe waktu kompilasi variabel yang sangat berguna dengan struktur data, seperti yang dikatakan @riwogo .

Sistem antarmuka saat ini di go sangat berguna, namun sangat buruk ketika Anda membutuhkan, misalnya, implementasi umum daftar, yang dengan antarmuka memerlukan batasan tipe waktu eksekusi, namun jika Anda menambahkan generik, tipe generik dapat diganti di kompilasi waktu dengan tipe aktual, membuat batasan tidak perlu.

Juga, ingat, orang-orang di belakang pergi, kembangkan bahasa menggunakan apa yang Anda sebut "teori dan matematika CS", dan juga orang-orang yang "menyelesaikan ini".

Juga, ingat, orang-orang di belakang pergi, kembangkan bahasa menggunakan apa yang Anda sebut "teori dan matematika CS", dan juga orang-orang yang "menyelesaikan ini".

Secara pribadi saya tidak melihat banyak teori CS dan matematika dalam desain bahasa Go. Ini adalah bahasa yang cukup primitif, yang menurut saya bagus. Juga orang-orang yang Anda bicarakan memutuskan untuk menghindari obat generik dan menyelesaikan sesuatu. Jika bekerja dengan baik, mengapa mengubah sesuatu? Secara umum, saya berpikir bahwa terus-menerus mengembangkan dan memperluas sintaksis bahasa adalah praktik yang buruk. Itu hanya menambah kerumitan yang mengarah pada kekacauan Haskell dan Scala.

Templatenya rumit tetapi Generik itu sederhana

Lihat fungsi SortInts, SortFloats, SortStrings dalam paket sortir. Atau SearchInts, SearchFloats, SearchStrings. Atau metode Len, Less, dan Swap dari byName dalam paket io/ioutil. Penyalinan boilerplate murni.

Fungsi salin dan tambahkan ada karena membuat irisan jauh lebih berguna. Generik berarti bahwa fungsi-fungsi ini tidak diperlukan. Generik akan memungkinkan untuk menulis fungsi serupa untuk peta dan saluran, belum lagi tipe data yang dibuat pengguna. Memang, irisan adalah tipe data komposit yang paling penting, dan itulah mengapa fungsi ini diperlukan, tetapi tipe data lain masih berguna.

Pilihan saya adalah tidak untuk aplikasi generik yang digeneralisasi, ya untuk lebih banyak fungsi generik bawaan seperti append dan copy yang bekerja pada beberapa tipe dasar. Mungkin sort dan search dapat ditambahkan untuk jenis koleksi?

Untuk aplikasi saya, satu-satunya tipe yang hilang adalah kumpulan yang tidak berurutan (https://github.com/golang/go/issues/7088), saya ingin ini sebagai tipe bawaan sehingga mendapatkan pengetikan umum seperti slice dan map . Masukkan pekerjaan ke dalam kompilator (pembandingan untuk setiap tipe dasar dan set yang dipilih dari tipe struct kemudian atur untuk kinerja terbaik) dan jauhkan anotasi tambahan dari kode aplikasi.

smap built-in bukannya sync.Map juga tolong. Dari pengalaman saya menggunakan interface{} untuk keamanan tipe runtime adalah cacat desain. Pengecekan tipe waktu kompilasi adalah alasan utama untuk menggunakan Go.

@pciet

Dari pengalaman saya menggunakan antarmuka{} untuk keamanan tipe waktu proses adalah cacat desain.

Bisakah Anda menulis pembungkus kecil (jenis brankas)?
https://play.golang.org/p/tG6hd-j5yx

@pierrre Pembungkus itu lebih baik daripada cek reflect.TypeOf(item).AssignableTo(type) . Tetapi menulis tipe Anda sendiri dengan map + sync.Mutex atau sync.RWMutex adalah kerumitan yang sama tanpa pernyataan tipe yang diperlukan sync.Map .

Penggunaan peta saya yang disinkronkan adalah untuk peta global mutex dengan var myMapLock = sync.RWMutex{} di sebelahnya alih-alih membuat tipe. Ini bisa lebih bersih. Tipe bawaan yang umum terdengar tepat bagi saya tetapi membutuhkan pekerjaan yang tidak dapat saya lakukan, dan saya lebih suka pendekatan saya daripada tipe yang menegaskan.

Saya menduga bahwa reaksi negatif yang mendalam terhadap obat generik yang tampaknya muncul oleh banyak programmer Go karena paparan utama mereka terhadap obat generik adalah melalui template C++. Ini sangat disayangkan karena C++ mendapatkan generik yang salah secara tragis sejak hari pertama dan telah menambah kesalahan sejak itu. Generik untuk Go bisa menjadi jauh lebih sederhana dan tidak rawan kesalahan.

Akan mengecewakan melihat Go menjadi semakin kompleks dengan menambahkan tipe parameter bawaan. Akan lebih baik hanya menambahkan dukungan bahasa untuk programmer untuk menulis tipe parameter mereka sendiri. Kemudian tipe khusus hanya bisa disediakan sebagai perpustakaan daripada mengacaukan bahasa inti.

@andrewcmyers "Generik untuk Go bisa menjadi jauh lebih sederhana dan tidak terlalu rawan kesalahan." --- seperti obat generik di C#.

Sangat mengecewakan melihat Go menjadi semakin kompleks dengan menambahkan tipe parameter bawaan.

Terlepas dari spekulasi dalam masalah ini, saya pikir ini sangat tidak mungkin terjadi.

Eksponen pada ukuran kompleksitas tipe parameter adalah varians.
Tipe Go (kecuali antarmuka) tidak berubah dan ini dapat dan harus
menjaga aturan.

Implementasi generik "type copy-paster" mekanis, dibantu kompiler
akan memecahkan 99% masalah dengan cara yang sesuai dengan dasar Go
prinsip kedangkalan dan tidak mengejutkan.

Omong-omong, ini dan lusinan ide layak lainnya telah dibahas
sebelumnya dan beberapa bahkan mencapai puncaknya dengan pendekatan yang baik dan bisa diterapkan. Pada ini
intinya, saya sangat membenci kertas timah tentang bagaimana mereka semua menghilang
diam-diam ke dalam kehampaan.

Pada 28 November 2017 23:54, "Andrew Myers" [email protected] menulis:

Saya menduga bahwa reaksi mendalam negatif terhadap obat generik yang banyak Go
programmer tampaknya muncul karena paparan utama mereka terhadap obat generik adalah
melalui template C++. Ini sangat disayangkan karena C++ mendapatkan obat generik secara tragis
salah dari hari 1 dan telah memperparah kesalahan sejak itu. Obat generik untuk
Go bisa menjadi jauh lebih sederhana dan tidak rawan kesalahan.

Sangat mengecewakan melihat Go menjadi semakin kompleks dengan menambahkan
tipe parameter bawaan. Akan lebih baik hanya menambahkan bahasa
dukungan bagi programmer untuk menulis tipe parameter mereka sendiri. Kemudian
tipe khusus hanya bisa disediakan sebagai perpustakaan daripada berantakan
bahasa inti.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-347691444 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
.

Ya, Anda dapat memiliki obat generik tanpa template. Template adalah bentuk polimorfisme parametrik canggih sebagian besar untuk fasilitas metaprogramming.

@ianlancetaylor Rust memungkinkan program untuk mengimplementasikan suatu sifat T pada tipe yang ada Q , asalkan peti mereka mendefinisikan T atau Q .

Hanya sebuah pemikiran: Saya ingin tahu apakah Simon Peyton Jones (ya, dari ketenaran Haskell) dan/atau pengembang Rust mungkin dapat membantu. Rust dan Haskell mungkin memiliki dua sistem tipe paling canggih dari semua bahasa produksi, dan Go harus belajar dari mereka.

Ada juga Phillip Wadler , yang mengerjakan Generic Java , yang akhirnya mengarah pada implementasi generik yang dimiliki Java saat ini.

@tarcieri Saya tidak berpikir bahwa obat generik Java sangat bagus, tetapi mereka telah teruji dalam pertempuran.

@DemiMarie Kami telah mengundang Andrew Myers di sini, untungnya.

Berdasarkan pengalaman pribadi saya, saya pikir orang yang tahu banyak tentang bahasa yang berbeda dan sistem tipe yang berbeda dapat sangat membantu dalam memeriksa ide. Tetapi untuk menghasilkan ide-ide di tempat pertama, yang kita butuhkan adalah orang-orang yang sangat akrab dengan Go, cara kerjanya hari ini, dan cara kerjanya yang wajar di masa depan. Go dirancang untuk menjadi, antara lain, bahasa yang sederhana. Mengimpor ide dari bahasa seperti Haskell atau Rust, yang jauh lebih rumit daripada Go, sepertinya tidak cocok. Dan secara umum ide-ide dari orang-orang yang belum pernah menulis kode Go dalam jumlah yang wajar sepertinya tidak cocok; bukan karena idenya akan buruk, hanya saja mereka tidak cocok dengan bahasa lainnya.

Misalnya, penting untuk dipahami bahwa Go sudah memiliki dukungan parsial untuk pemrograman generik menggunakan tipe antarmuka dan sudah (hampir) memiliki dukungan lengkap menggunakan paket refleksi. Sementara dua pendekatan untuk pemrograman generik tersebut tidak memuaskan karena berbagai alasan, setiap proposal untuk generik di Go harus berinteraksi dengan baik dengan keduanya sekaligus mengatasi kekurangannya.

Sebenarnya, ketika saya di sini, beberapa waktu lalu saya berpikir tentang pemrograman generik dengan antarmuka untuk sementara waktu, dan muncul dengan tiga alasan mengapa gagal memuaskan.

1. Antarmuka membutuhkan semua operasi untuk dinyatakan sebagai metode. Itu membuatnya sulit untuk menulis antarmuka untuk tipe bawaan, seperti tipe saluran. Semua jenis saluran mendukung operator <- untuk operasi kirim dan terima, dan cukup mudah untuk menulis antarmuka dengan metode Send dan Receive , tetapi untuk menetapkan nilai saluran untuk tipe antarmuka itu Anda harus menulis metode pelat boilerplate Send dan Receive . Metode boilerplate tersebut akan terlihat persis sama untuk setiap jenis saluran yang berbeda, yang membosankan.

2. Antarmuka diketik secara dinamis, sehingga kesalahan yang menggabungkan nilai yang diketik secara statis berbeda hanya ditangkap pada waktu berjalan, bukan waktu kompilasi. Misalnya, fungsi Merge yang menggabungkan dua saluran menjadi satu saluran menggunakan metode Send dan Receive akan mengharuskan kedua saluran memiliki elemen dengan tipe yang sama, tetapi pemeriksaan hanya dapat dilakukan pada saat run time.

3. Antarmuka selalu kotak. Misalnya, tidak ada cara untuk menggunakan antarmuka untuk menggabungkan sepasang tipe lain tanpa menempatkan tipe lain tersebut ke dalam nilai antarmuka, yang memerlukan alokasi memori tambahan dan pengejaran pointer.

Saya senang untuk mengoceh pada proposal generik untuk Go. Mungkin yang juga menarik adalah meningkatnya jumlah penelitian tentang obat generik di Cornell akhir-akhir ini, yang tampaknya relevan dengan apa yang mungkin dilakukan dengan Go:

http://www.cs.cornell.edu/andru/papers/familia/ (Zhang & Myers, OOPSLA'17)
http://io.livecode.ch/learn/namin/unsound (Amin & Tate, OOPSLA'16)
http://www.cs.cornell.edu/projects/genus/ (Zhang et al., PLDI '15)
https://www.cs.cornell.edu/~ross/publications/shapes/shapes-pldi14.pdf (Greenman, Muehlboeck & Tate, PLDI '14)

Dalam pembandingan peta vs. irisan untuk tipe set yang tidak berurutan, saya menulis unit test terpisah untuk masing-masing, tetapi dengan tipe antarmuka saya dapat menggabungkan dua daftar tes tersebut menjadi satu:

type Item interface {
    Equal(Item) bool
}

type Set interface {
    Add(Item) Set
    Remove(Item) Set
    Combine(...Set) Set
    Reduce() Set
    Has(Item) bool
    Equal(Set) bool
    Diff(Set) Set
}

Pengujian menghapus item:

type RemoveCase struct {
    Set
    Item
    Out Set
}

func TestRemove(t *testing.T) {
    for i, c := range RemoveCases {
        if c.Out.Equal(c.Set.Remove(c.Item)) == false {
            t.Fatalf("%v failed", i)
        }
    }
}

Dengan cara ini saya dapat menyatukan kasing saya yang sebelumnya terpisah menjadi satu irisan kasing tanpa masalah:

var RemoveCases = []RemoveCase{
    {
        Set: MapPathSet{
            &Path{{0, 0}}:         {},
            &Path{{0, 1}, {1, 1}}: {},
        },
        Item: Path{{0, 0}},
        Out: MapPathSet{
            &Path{{0, 1}, {1, 1}}: {},
        },
    },
    {
        Set: SlicePathSet{
            {{0, 0}},
            {{0, 1}, {1, 1}},
        },
        Item: Path{{0, 0}},
        Out: SlicePathSet{
            {{0, 1}, {1, 1}},
        },
    },
}

Untuk setiap tipe beton saya harus mendefinisikan metode antarmuka. Sebagai contoh:

func (the MapPathSet) Remove(an Item) Set {
    return MapDelete(the, an.(Path))
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an.(Path))
}

Tes generik ini dapat menggunakan pemeriksaan tipe waktu kompilasi yang diusulkan:

type Item generic {
    Equal(Item) bool
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an)
}

Sumber: https://github.com/pciet/pathsetbenchmark

Memikirkan hal itu lebih jauh, sepertinya pemeriksaan tipe waktu kompilasi tidak mungkin dilakukan untuk tes semacam itu karena Anda harus menjalankan program untuk mengetahui apakah suatu tipe diteruskan ke metode antarmuka yang sesuai.

Jadi bagaimana dengan tipe "generik" yang merupakan antarmuka dan memiliki pernyataan tipe tak terlihat yang ditambahkan oleh kompiler saat digunakan secara konkret?

@andrewcmyers Makalah "Familia" menarik (dan jauh di atas kepala saya). Gagasan kuncinya adalah warisan. Bagaimana konsep akan berubah untuk bahasa seperti Go yang mengandalkan komposisi alih-alih pewarisan?

Terima kasih. Bagian warisan tidak berlaku untuk Go -- jika Anda hanya tertarik pada obat generik untuk Go, Anda dapat berhenti membaca setelah bagian 4 makalah. Hal utama tentang makalah yang relevan dengan Go adalah bahwa makalah ini menunjukkan cara menggunakan antarmuka baik dalam cara mereka digunakan untuk Go sekarang maupun sebagai batasan pada tipe untuk abstraksi umum. Yang berarti Anda mendapatkan kekuatan kelas tipe Haskell tanpa menambahkan konstruksi yang sama sekali baru ke bahasa.

@andrewcmyers Bisakah Anda memberi contoh bagaimana tampilannya di Go?

Hal utama tentang makalah yang relevan dengan Go adalah bahwa makalah ini menunjukkan cara menggunakan antarmuka baik dalam cara mereka digunakan untuk Go sekarang maupun sebagai batasan pada tipe untuk abstraksi umum.

Pemahaman saya adalah bahwa antarmuka Go mendefinisikan batasan pada suatu tipe (misalnya "tipe ini dapat dibandingkan untuk kesetaraan menggunakan 'jenis antarmuka yang Sebanding' karena memenuhi metode Persamaan"). Saya tidak yakin saya mengerti apa yang Anda maksud dengan batasan tipe.

Saya tidak akrab dengan Haskell tetapi membaca tinjauan singkat membuat saya menebak bahwa tipe yang sesuai dengan antarmuka Go akan masuk ke dalam kelas tipe itu. Bisakah Anda menjelaskan apa yang berbeda tentang kelas tipe Haskell?

Perbandingan konkret antara Familia dan Go akan menarik. Terima kasih telah membagikan makalah Anda.

Antarmuka Go dapat dilihat sebagai penggambaran batasan pada tipe, melalui subtipe struktural. Namun, batasan tipe itu, sebagaimana adanya, tidak cukup ekspresif untuk menangkap batasan yang Anda inginkan untuk pemrograman generik. Misalnya, Anda tidak dapat mengungkapkan batasan tipe bernama Eq di makalah Familia.

Beberapa pemikiran tentang motivasi untuk fasilitas pemrograman yang lebih umum di Go:

Jadi ada daftar tes generik saya yang tidak benar-benar membutuhkan apa pun yang ditambahkan ke bahasa. Menurut pendapat saya bahwa tipe generik yang saya usulkan tidak memenuhi tujuan Go dari pemahaman langsung, itu tidak ada hubungannya dengan istilah pemrograman yang diterima secara umum, dan melakukan pernyataan tipe di sana tidak jelek karena kepanikan pada kegagalan adalah bagus. Saya puas dengan fasilitas pemrograman generik Go untuk kebutuhan saya.

Tapi sync.Map adalah kasus penggunaan yang berbeda. Ada kebutuhan di perpustakaan standar untuk implementasi peta tersinkronisasi generik yang matang di luar hanya struct dengan peta dan mutex. Untuk penanganan tipe, kita bisa membungkusnya dengan tipe lain yang menyetel tipe{} non-antarmuka dan melakukan penegasan tipe, atau kita bisa menambahkan pemeriksaan refleksi secara internal sehingga item yang mengikuti tipe pertama harus cocok dengan tipe yang sama. Keduanya memiliki pemeriksaan runtime, pembungkusnya memerlukan penulisan ulang setiap metode untuk setiap jenis penggunaan tetapi ia menambahkan pemeriksaan jenis waktu kompilasi untuk input dan menyembunyikan pernyataan tipe output, dan dengan pemeriksaan internal kita tetap harus melakukan pernyataan tipe output. Apa pun itu, kami melakukan konversi antarmuka tanpa penggunaan antarmuka yang sebenarnya; interface{} adalah peretasan bahasa dan tidak akan jelas bagi programmer Go baru. Meskipun json.Marshal adalah desain yang bagus menurut saya (termasuk tag struct yang jelek tapi masuk akal).

Saya akan menambahkan bahwa karena sync.Map ada di perpustakaan standar, idealnya itu harus menukar implementasi untuk kasus penggunaan yang diukur di mana struct sederhana lebih berkinerja. Peta yang tidak disinkronkan adalah jebakan awal yang umum dalam pemrograman bersamaan Go dan perbaikan pustaka standar seharusnya berfungsi.

Peta biasa hanya memiliki pemeriksaan tipe waktu kompilasi dan tidak memerlukan perancah ini. Saya berpendapat bahwa sync.Map harus sama atau tidak boleh ada di perpustakaan standar untuk Go 2.

Saya mengusulkan untuk menambahkan sync.Map ke daftar tipe bawaan dan melakukan hal yang sama untuk kebutuhan serupa di masa mendatang. Tetapi pemahaman saya adalah memberi programmer Go cara untuk melakukan ini tanpa harus bekerja pada kompiler dan melalui tantangan penerimaan open source adalah ide di balik diskusi ini. Dalam pandangan saya, memperbaiki sync.Map adalah kasus nyata yang mendefinisikan sebagian proposal generik ini.

Jika Anda menambahkan sync.Map sebagai built-in, lalu seberapa jauh Anda melangkah? Apakah Anda kasus khusus setiap wadah?
sync.Map bukan satu-satunya wadah dan beberapa lebih baik untuk beberapa kasus daripada yang lain.

@Azareal : @chowey mendaftarkan ini pada bulan Agustus:

Terakhir, pustaka standar dipenuhi dengan alternatif{} antarmuka di mana obat generik akan bekerja lebih aman:

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• sync.Map yang akan datang (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Mungkin ada orang lain yang saya lewatkan. Intinya, masing-masing di atas adalah di mana saya berharap obat generik berguna.

Dan saya ingin set yang tidak berurutan untuk tipe yang dapat dibandingkan untuk kesetaraan.

Saya ingin banyak pekerjaan dimasukkan ke dalam implementasi variabel di runtime untuk setiap jenis berdasarkan pembandingan sehingga implementasi terbaik biasanya yang digunakan.

Saya ingin tahu apakah ada implementasi alternatif yang masuk akal dengan Go 1 yang mencapai tujuan yang sama untuk tipe pustaka standar ini tanpa antarmuka{} dan tanpa generik.

antarmuka golang dan kelas tipe haskell mengatasi dua hal (yang sangat hebat!):

1.) (Jenis Kendala) Mereka mengelompokkan jenis yang berbeda dengan satu tag, nama antarmuka
2.) (Pengiriman) Mereka menawarkan untuk mengirim secara berbeda pada setiap jenis untuk serangkaian fungsi tertentu melalui implementasi antarmuka

Tetapi,

1.) Terkadang Anda hanya menginginkan grup anonim seperti grup int, float64, dan string. Bagaimana Anda memberi nama antarmuka seperti itu, NumericandString?

2.) Sangat sering, Anda tidak ingin mengirimkan secara berbeda untuk setiap jenis antarmuka tetapi hanya menyediakan satu metode untuk semua jenis antarmuka yang terdaftar (Mungkin mungkin dengan metode antarmuka default )

3.) Sangat sering, Anda tidak ingin menghitung semua jenis yang mungkin untuk suatu grup. Alih-alih, Anda pergi dengan cara yang malas dan mengatakan saya ingin semua tipe T mengimplementasikan beberapa Antarmuka A dan kompiler kemudian mencari semua jenis di semua file sumber yang Anda edit dan di semua perpustakaan yang Anda gunakan untuk menghasilkan fungsi yang sesuai pada waktu kompilasi.

Meskipun poin terakhir dimungkinkan melalui polimorfisme antarmuka, ini memiliki kelemahan menjadi polimorfisme runtime yang melibatkan gips dan bagaimana Anda membatasi input parameter suatu fungsi untuk memuat tipe yang mengimplementasikan lebih dari satu antarmuka atau salah satu dari banyak antarmuka. Cara yang baik adalah dengan memperkenalkan antarmuka baru yang memperluas antarmuka lain (dengan antarmuka bersarang) untuk mencapai sesuatu yang serupa tetapi tidak dengan praktik terbaik.

Ngomong-ngomong.
Saya mengakui kepada mereka yang mengatakan bahwa go sudah memiliki polimorfisme dan oleh karena itu go bukan lagi bahasa sederhana seperti C. Ini adalah bahasa pemrograman sistem tingkat tinggi. Jadi mengapa tidak memperluas penawaran polimorfisme.

Inilah perpustakaan yang saya mulai hari ini untuk jenis kumpulan umum yang tidak berurutan: https://github.com/pciet/unordered

Ini memberikan contoh dokumentasi dan pengujian yang mengetik pola pembungkus (terima kasih @pierrre) untuk keamanan tipe waktu kompilasi dan juga memiliki pemeriksaan refleksi untuk keamanan tipe run-time.

Apa kebutuhan yang ada untuk obat generik? Sikap negatif saya terhadap tipe generik pustaka standar sebelumnya berpusat pada penggunaan antarmuka{}; keluhan saya dapat diselesaikan dengan tipe khusus paket untuk antarmuka{} (seperti type Item interface{} dalam pciet/unordered) yang mendokumentasikan batasan yang tidak dapat diungkapkan yang dimaksud.

Saya tidak melihat perlunya fitur bahasa tambahan ketika hanya dokumentasi yang bisa membawa kita ke sana sekarang. Sudah ada sejumlah besar kode yang teruji pertempuran di perpustakaan standar yang menyediakan fasilitas umum (lihat https://github.com/golang/go/issues/23077).

Jenis kode Anda diperiksa saat runtime (dan dari perspektif itu sama sekali tidak lebih baik daripada hanya interface{} jika tidak lebih buruk). Dengan obat generik Anda bisa memiliki tipe koleksi dengan pemeriksaan tipe waktu kompilasi.

@zerkms pemeriksaan run-time dapat dimatikan dengan mengatur asserting = false (ini tidak akan masuk ke perpustakaan standar), ada pola penggunaan untuk pemeriksaan waktu kompilasi, dan lagi pula pemeriksaan tipe hanya melihat struct antarmuka (menggunakan antarmuka menambahkan lebih banyak biaya daripada pemeriksaan jenis). Jika antarmuka tidak berfungsi maka Anda harus menulis tipe Anda sendiri.

Anda mengatakan kode generik kinerja maksimal adalah kebutuhan utama. Belum untuk kasus penggunaan saya, tetapi mungkin perpustakaan standar bisa menjadi lebih cepat, dan mungkin orang lain membutuhkan hal seperti itu.

pemeriksaan run-time dapat dimatikan dengan mengatur pernyataan = false

maka tidak ada yang menjamin kebenaran

Anda mengatakan kode generik kinerja maksimal adalah kebutuhan utama.

Saya tidak mengatakan itu. Keamanan jenis akan sangat membantu. Solusi Anda masih interface{} -terinfeksi.

tapi mungkin perpustakaan standar bisa menjadi lebih cepat, dan mungkin orang lain membutuhkan hal seperti itu.

mungkin, jika tim pengembang inti dengan senang hati mengimplementasikan apa pun yang saya butuhkan sesuai permintaan dan dengan cepat.

@pciet

Saya tidak melihat perlunya fitur bahasa tambahan ketika hanya dokumentasi yang bisa membawa kita ke sana sekarang.

Anda mengatakan ini, namun Anda tidak memiliki masalah menggunakan fitur bahasa generik dalam bentuk irisan dan fungsi make.

Saya tidak melihat perlunya fitur bahasa tambahan ketika hanya dokumentasi yang bisa membawa kita ke sana sekarang.

Lalu mengapa repot-repot menggunakan bahasa yang diketik secara statis? Anda dapat menggunakan bahasa yang diketik secara dinamis seperti Python dan mengandalkan dokumentasi untuk memastikan tipe data yang benar dikirim ke API Anda.

Saya pikir salah satu keuntungan dari Go adalah fasilitas untuk memberlakukan beberapa kendala oleh kompiler untuk mencegah bug di masa depan. Fasilitas tersebut dapat diperluas (dengan dukungan generik) untuk menerapkan beberapa kendala lain untuk mencegah beberapa bug lagi di masa mendatang.

Anda mengatakan ini, namun Anda tidak memiliki masalah menggunakan fitur bahasa generik dalam bentuk irisan dan fungsi make.

Saya mengatakan fitur yang ada membawa kita ke titik keseimbangan yang baik yang memang memiliki solusi pemrograman generik dan harus ada alasan nyata yang kuat untuk berubah dari sistem tipe Go 1. Bukan bagaimana perubahan akan meningkatkan bahasa tetapi masalah apa yang dihadapi orang sekarang, seperti mempertahankan banyak pergantian tipe waktu proses untuk antarmuka{} dalam paket pustaka standar fmt dan database, yang akan diperbaiki.

Lalu mengapa repot-repot menggunakan bahasa yang diketik secara statis? Anda dapat menggunakan bahasa yang diketik secara dinamis seperti Python dan mengandalkan dokumentasi untuk memastikan tipe data yang benar dikirim ke API Anda.

Saya telah mendengar saran untuk menulis sistem dengan Python alih-alih bahasa dan organisasi yang diketik secara statis.

Kebanyakan programmer Go yang menggunakan library standar menggunakan tipe yang tidak dapat dijelaskan secara lengkap tanpa dokumentasi atau tanpa melihat implementasinya. Tipe dengan subtipe parametrik atau tipe umum dengan batasan yang diterapkan hanya memperbaiki subset dari kasus ini secara terprogram dan akan menghasilkan banyak pekerjaan yang sudah dilakukan di pustaka standar.

Dalam proposal untuk tipe sum, saya menyarankan fitur build untuk sakelar tipe antarmuka di mana antarmuka yang digunakan dalam suatu fungsi atau metode memiliki kesalahan build yang dipancarkan ketika nilai yang mungkin ditetapkan ke antarmuka tidak cocok dengan kasus sakelar tipe antarmuka apa pun yang terkandung.

Fungsi/metode yang mengambil antarmuka dapat menolak beberapa tipe saat dibangun dengan tidak memiliki case default dan tidak ada case untuk tipe tersebut. Ini sepertinya tambahan pemrograman generik yang masuk akal jika fitur tersebut layak untuk diterapkan.

Jika antarmuka Go dapat menangkap tipe pelaksana, mungkin ada bentuk generik yang sepenuhnya kompatibel dengan sintaks Go saat ini - bentuk parameter tunggal generik ( demonstrasi ).

@dc0d untuk tipe wadah generik Saya percaya fitur itu menambahkan pemeriksaan tipe waktu kompilasi tanpa memerlukan tipe pembungkus: https://Gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet Anda benar. Dalam kode yang disediakan, No. 4, sampel menyatakan bahwa tipe ditangkap untuk irisan dan saluran (dan larik). Tapi tidak untuk peta, karena hanya ada satu dan hanya satu jenis parameter: pelaksana. Dan karena peta membutuhkan dua parameter tipe, antarmuka pembungkus diperlukan.

BTW saya harus menekankan tujuan demonstrasi kode itu, sebagai garis pemikiran. Saya bukan perancang bahasa. Ini hanyalah cara berpikir hipotetis tentang implementasi obat generik di Go:

• Kompatibel dengan Go
• Sederhana (parameter tipe generik tunggal, yang _terasa_ seperti _ini_ di OO lain, mengacu pada pelaksana saat ini)

Diskusi tentang generikitas dan semua kasus penggunaan yang mungkin dalam konteks keinginan untuk meminimalkan dampak sambil memaksimalkan kasus penggunaan yang penting dan fleksibilitas ekspresi adalah analisis yang sangat kompleks. Tidak yakin apakah ada di antara kita yang dapat menyaringnya menjadi prinsip-prinsip singkat alias esensi generatif. Saya mencoba. Bagaimanapun, inilah beberapa pemikiran awal saya dari _cursory_ saya membaca utas ini…

@adg menulis:

Mendampingi masalah ini adalah proposal generik umum oleh @ianlancetaylor yang mencakup empat proposal cacat spesifik dari mekanisme pemrograman generik untuk Go.

Afaics, bagian tertaut yang dikutip sebagai berikut gagal untuk menyatakan kasus generik yang kurang dengan antarmuka saat ini, _“Tidak ada cara untuk menulis metode yang mengambil antarmuka untuk tipe T yang disediakan pemanggil, untuk T apa pun, dan mengembalikan nilai tipe T yang sama.”_.

Tidak ada cara untuk menulis antarmuka dengan metode yang mengambil argumen tipe T, untuk T apa pun, dan mengembalikan nilai dengan tipe yang sama.

Jadi bagaimana lagi kode di jenis situs panggilan memeriksa apakah ia memiliki tipe T sebagai nilai hasil? Misalnya, antarmuka tersebut mungkin memiliki metode pabrik untuk membangun tipe T. Inilah mengapa kita perlu memparametrikan antarmuka pada tipe T.

Antarmuka bukan sekadar tipe; mereka juga nilai. Tidak ada cara untuk menggunakan tipe antarmuka tanpa menggunakan nilai antarmuka, dan nilai antarmuka tidak selalu efisien.

Setuju bahwa karena antarmuka saat ini tidak dapat diparametrikan secara eksplisit pada tipe T yang dioperasikannya, tipe T tidak dapat diakses oleh programmer.

Jadi, inilah yang dilakukan oleh batas kelas tipe di situs definisi fungsi yang mengambil sebagai input tipe T dan memiliki klausa where atau requires yang menyatakan antarmuka yang diperlukan untuk tipe T. Dalam banyak keadaan kamus antarmuka ini dapat secara otomatis dimonomorfisasi pada waktu kompilasi sehingga tidak ada penunjuk kamus (untuk antarmuka) yang diteruskan ke fungsi saat runtime (monomorfisasi yang saya anggap kompiler Go berlaku untuk antarmuka saat ini?). Dengan 'nilai' dalam kutipan di atas, saya kira yang dia maksud adalah tipe input T dan bukan kamus metode untuk tipe antarmuka yang diimplementasikan oleh tipe T.

Jika kemudian kita mengizinkan parameter tipe pada tipe data (misalnya struct ), maka tipe T di atas dapat diparameterisasi sendiri sehingga kita benar-benar memiliki tipe T<U> . Pabrik untuk tipe seperti itu yang perlu mempertahankan pengetahuan tentang U disebut tipe tipe yang lebih tinggi (HKT) .

Generik mengizinkan kontainer polimorfik yang aman untuk tipe.

Lihat juga masalah wadah _heterogen_ yang dibahas di bawah ini. Jadi dengan polimorfik yang kami maksud adalah generikitas dari jenis nilai wadah (misalnya jenis elemen koleksi), namun ada juga masalah apakah kita dapat menempatkan lebih dari satu jenis nilai dalam wadah secara bersamaan sehingga menjadikannya heterogen.

@tamird menulis:

Persyaratan ini tampaknya mengecualikan misalnya sistem yang mirip dengan sistem sifat Rust, di mana tipe generik dibatasi oleh batas sifat.

Batas sifat Rust pada dasarnya adalah batas kelas tipe.

@alex menulis:

Ciri-ciri karat. Sementara saya pikir mereka adalah model yang baik secara umum, mereka tidak cocok untuk Go seperti yang ada saat ini.

Mengapa menurut Anda mereka tidak cocok? Mungkin Anda memikirkan objek sifat yang menggunakan pengiriman runtime sehingga kurang berkinerja daripada monomorfisme? Tetapi itu dapat dipertimbangkan secara terpisah dari prinsip generikitas batas kelas tipe (lih diskusi saya tentang wadah/koleksi heterogen di bawah). Afaics, antarmuka Go sudah terikat sifat-seperti dan mencapai tujuan kelas tipe yang terlambat mengikat kamus ke tipe data di situs panggilan, daripada anti-pola OOP yang mengikat awal (bahkan jika masih di kompilasi- waktu) kamus ke tipe data (pada instantiasi/konstruksi). Kelas tipe dapat (setidaknya sebagian peningkatan derajat kebebasan) memecahkan Masalah Ekspresi yang tidak dapat dilakukan OOP.

@jimmyfrasche menulis:

• https://golang.org/doc/faq#covariant_types

Saya setuju dengan tautan di atas bahwa kelas tipe memang tidak membuat subtipe dan tidak mengekspresikan hubungan pewarisan apa pun. Dan setuju dengan tidak perlu menggabungkan "kedermawanan" (sebagai konsep penggunaan kembali atau modularitas yang lebih umum daripada polimorfisme parametrik) dengan pewarisan seperti halnya subkelas.

Namun saya juga ingin menunjukkan bahwa hierarki pewarisan (alias subtipe) tidak dapat dihindari ¹ pada penugasan ke (input fungsi) dan dari (keluaran fungsi) jika bahasa mendukung serikat pekerja dan persimpangan, karena misalnya int ν string dapat menerima tugas dari int atau string tetapi keduanya tidak dapat menerima tugas dari int ν string . Tanpa serikat pekerja, satu-satunya cara alternatif untuk menyediakan wadah/koleksi heterogen yang diketik secara statis adalah subkelas atau polimorfisme yang dibatasi secara eksistensial (alias objek sifat di Rust dan kuantifikasi eksistensial di Haskell). Tautan di atas berisi diskusi tentang kompromi antara eksistensial dan serikat pekerja. Afaik, satu-satunya cara untuk melakukan wadah/koleksi heterogen di Go sekarang adalah dengan memasukkan semua jenis ke interface{} kosong yang membuang informasi pengetikan dan akankah saya anggap memerlukan pemeriksaan tipe gips dan runtime, yang semacam ² mengalahkan titik pengetikan statis.

"Anti-pola" yang harus dihindari adalah subkelas alias pewarisan virtual (lih juga "EDIT#2" tentang masalah dengan subsumsi implisit dan kesetaraan, dll).

¹ _{Terlepas dari apakah mereka cocok secara struktural atau nominal karena subtipe disebabkan oleh Prinsip Substitusi Liskov berdasarkan set komparatif dan arah penugasan dengan input fungsi yang berlawanan dengan nilai yang dikembalikan, misalnya parameter tipe dari struct atau interface tidak dapat berada di kedua input fungsi dan mengembalikan nilai kecuali invarian alih-alih co- atau kontra-varian.}

² _{Absolutisme tidak akan berlaku karena kita tidak dapat mengetik periksa alam semesta non-determinisme tak terbatas. Jadi seperti yang saya pahami, utas ini adalah tentang memilih batas ("sweet spot") yang optimal untuk tingkat menyatakan mengetik wrt ke masalah generik.}

@andrewcmyers menulis:

Tidak seperti generik Java dan C#, mekanisme generik Genus tidak didasarkan pada subtipe.

Ini adalah pewarisan dan subkelas ( bukan subtipe struktural ) yang merupakan anti-pola terburuk yang tidak ingin Anda salin dari Java, Scala, Ceylon, dan C++ (tidak terkait dengan masalah dengan template C++ ).

@thwd menulis:

Eksponen pada ukuran kompleksitas tipe parameter adalah varians. Tipe Go (kecuali antarmuka) bersifat invarian dan ini dapat dan harus tetap menjadi aturan.

Subtipe dengan kekekalan mengesampingkan kompleksitas kovarians. Kekekalan juga memperbaiki beberapa masalah dengan subkelas (misalnya Rectangle vs. Square ) tetapi tidak untuk yang lain (misalnya subsumsi implisit, kesetaraan, dll).

@bxqgit menulis:

Sintaks sederhana dan sistem tipe adalah kelebihan penting dari Go. Jika Anda menambahkan obat generik, bahasa akan menjadi berantakan seperti Scala atau Haskell.

Perhatikan bahwa Scala mencoba untuk menggabungkan OOP, subsclassing, FP, modul generik, HKT, dan kelas tipe (melalui implicit ) semuanya menjadi satu PL. Mungkin kelas tipe saja mungkin sudah cukup.

Haskell tidak selalu tumpul karena generik kelas tipe, tetapi lebih mungkin karena itu menegakkan fungsi murni di mana-mana dan menggunakan teori kategori monadik untuk memodelkan efek imperatif yang terkontrol.

Jadi saya pikir itu tidak benar untuk mengasosiasikan kebodohan dan kompleksitas PL tersebut dengan kelas tipe misalnya Rust. Dan jangan salahkan kelas tipe untuk masa hidup Rust + abstraksi peminjaman mutabilitas eksklusif.

Afaics, di bagian Semantik dari _Type Parameters di Go_, masalah yang dihadapi oleh @ianlancetaylor adalah masalah konseptualisasi karena dia (afaics) tampaknya tanpa disadari menciptakan kembali kelas tipe :

Bisakah kita menggabungkan SortableSlice dan PSortableSlice untuk mendapatkan yang terbaik dari kedua dunia? Tidak terlalu; tidak ada cara untuk menulis fungsi berparameter yang mendukung tipe dengan metode Less atau tipe bawaan. Masalahnya adalah SortableSlice.Less tidak dapat dipakai untuk suatu tipe tanpa metode Less , dan tidak ada cara untuk hanya membuat instance metode untuk beberapa tipe tetapi tidak untuk yang lain.

Klausa requires Less[T] untuk terikat kelas tipe (bahkan jika secara implisit disimpulkan oleh kompiler) pada metode Less untuk []T ada di T bukan []T . Implementasi kelas tipe Less[T] (yang berisi metode Less metode) untuk setiap T akan memberikan implementasi di badan fungsi metode atau menetapkan < fungsi bawaan sebagai implementasi. Namun saya percaya ini memerlukan HKT U[T] jika metode Sortable[U] memerlukan parameter tipe U yang mewakili tipe implementasi, misalnya []T . Afair @keean memiliki cara lain untuk menyusun semacam menggunakan kelas tipe terpisah untuk tipe nilai T yang tidak memerlukan HKT.

Perhatikan metode tersebut untuk []T mungkin mengimplementasikan kelas tipe Sortable[U] , di mana U adalah []T .

(Selain teknis: tampaknya kita dapat menggabungkan SortableSlice dan PSortableSlice dengan memiliki beberapa mekanisme untuk hanya membuat instance metode untuk beberapa jenis argumen tetapi tidak yang lain. Namun, hasilnya adalah mengorbankan kompilasi -keamanan tipe waktu, karena menggunakan tipe yang salah akan menyebabkan kepanikan runtime. Di Go, seseorang sudah dapat menggunakan tipe dan metode antarmuka dan tipe pernyataan untuk memilih perilaku saat runtime. Tidak perlu menyediakan cara lain untuk melakukan ini menggunakan parameter tipe .)

Pemilihan kelas tipe terikat di situs panggilan diselesaikan pada waktu kompilasi untuk T yang dikenal secara statis. Jika pengiriman dinamis heterogen diperlukan, lihat opsi yang saya jelaskan di posting saya sebelumnya.

Saya harap @keean dapat meluangkan waktu untuk datang ke sini dan membantu menjelaskan kelas tipe karena dia lebih ahli dan membantu saya mempelajari konsep-konsep ini. Saya mungkin memiliki beberapa kesalahan dalam penjelasan saya.

Catatan PS bagi mereka yang sudah membaca posting saya sebelumnya, perhatikan saya mengeditnya secara ekstensif sekitar 10 jam setelah mempostingnya (setelah tidur) semoga poin tentang wadah heterogen lebih koheren.

Bagian Siklus tampaknya salah. Konstruksi runtime dari instance S[T]{e} dari struct tidak ada hubungannya dengan pemilihan implementasi fungsi generik yang dipanggil. Dia mungkin berpikir bahwa kompiler tidak tahu apakah itu mengkhususkan implementasi fungsi generik untuk jenis argumen, tetapi semua jenis itu diketahui pada waktu kompilasi.

Mungkin spesifikasi bagian Pengecekan Tipe dapat disederhanakan dengan mempelajari konsep @keean tentang graf terhubung dari tipe berbeda sebagai simpul untuk algoritme penyatuan. Setiap tipe berbeda yang dihubungkan oleh sebuah edge harus memiliki tipe yang kongruen, dengan edge yang dibuat untuk semua tipe yang terhubung melalui penetapan atau sebaliknya dalam kode sumber. Jika ada serikat dan persimpangan (dari posting saya sebelumnya), maka arah penugasan harus diperhitungkan ( entah bagaimana? ). Setiap jenis yang tidak diketahui yang berbeda dimulai dengan batas atas terkecil (LUB) dari Atas dan batas bawah terbesar (GLB) dari Bawah dan kemudian kendala dapat mengubah batas ini. Jenis yang terhubung harus memiliki batas yang kompatibel. Batasan semua harus berupa batas kelas tipe.

Dalam Implementasi :

Misalnya, selalu mungkin untuk mengimplementasikan fungsi berparameter dengan membuat salinan baru dari fungsi untuk setiap instantiasi, di mana fungsi baru dibuat dengan mengganti parameter tipe dengan argumen tipe.

Saya percaya istilah teknis yang benar adalah monomorfisasi .

Pendekatan ini akan menghasilkan waktu eksekusi yang paling efisien dengan biaya waktu kompilasi ekstra yang cukup besar dan peningkatan ukuran kode. Ini mungkin menjadi pilihan yang baik untuk fungsi parameter yang cukup kecil untuk inline, tetapi itu akan menjadi tradeoff yang buruk dalam kebanyakan kasus lainnya.

Pembuatan profil akan memberi tahu programmer fungsi mana yang paling diuntungkan dari monomorfisasi. Mungkin pengoptimal Java Hotspot melakukan pengoptimalan monomorfisasi saat runtime?

@egonelbre menulis:

Ada Summary of Go Generics Discussions , yang mencoba memberikan gambaran umum tentang diskusi dari berbagai tempat.

Bagian Ikhtisar tampaknya menyiratkan bahwa penggunaan universal referensi tinju Java untuk instance dalam wadah adalah satu-satunya sumbu desain yang secara diametris menentang monomorfisasi template C++. Tetapi batas kelas tipe (yang juga dapat diimplementasikan dengan templat C++ namun selalu monomorfis) diterapkan pada fungsi, bukan pada parameter tipe wadah. Dengan demikian, gambaran umum tidak memiliki sumbu desain untuk kelas tipe di mana kita dapat memilih apakah akan memonomorfisasikan setiap fungsi yang dibatasi kelas tipe. Dengan kelas tipe, kami selalu membuat programmer lebih cepat (lebih sedikit boilerplate) dan bisa mendapatkan keseimbangan yang lebih halus antara membuat kompiler/eksekusi lebih cepat/lebih lambat dan kode mengasapi lebih besar/lebih kecil. Per posting saya sebelumnya, mungkin yang optimal adalah jika pilihan fungsi untuk monomorphise didorong oleh profiler (secara otomatis atau lebih mungkin dengan anotasi).

Di bagian Masalah : Struktur Data Umum :

Kontra

• Struktur umum cenderung mengakumulasi fitur dari semua penggunaan, menghasilkan peningkatan waktu kompilasi atau kode mengasapi atau membutuhkan tautan yang lebih cerdas.

Untuk kelas tipe ini tidak benar atau kurang menjadi masalah, karena antarmuka hanya perlu diimplementasikan untuk tipe data yang dipasok ke fungsi yang menggunakan antarmuka tersebut. Kelas tipe adalah tentang pengikatan implementasi yang terlambat ke antarmuka, tidak seperti OOP yang mengikat setiap tipe data ke metodenya untuk implementasi class .

Selain itu, tidak semua metode perlu dimasukkan ke dalam satu antarmuka. Klausa requires (bahkan jika secara implisit disimpulkan oleh kompiler) pada kelas tipe yang terikat untuk deklarasi fungsi dapat memadupadankan antarmuka yang diperlukan.

• Struktur umum dan API yang beroperasi di atasnya cenderung lebih abstrak daripada API yang dibuat khusus, yang dapat membebani kognitif penelepon

Argumen tandingan yang menurut saya secara signifikan memperbaiki kekhawatiran ini adalah bahwa beban kognitif untuk mempelajari sejumlah kasus khusus yang tidak terbatas, implementasi ulang dari algoritma generik yang pada dasarnya sama, tidak terbatas. Padahal, mempelajari API generik abstrak terbatas.

• Pengoptimalan mendalam sangat non-generik dan spesifik konteks, oleh karena itu lebih sulit untuk mengoptimalkannya dalam algoritme generik.

Ini bukan penipu yang valid. Aturan 80/20 mengatakan jangan menambahkan kompleksitas tak terbatas (misalnya optimasi prematur) untuk kode yang ketika diprofilkan tidak memerlukannya. Pemrogram bebas untuk mengoptimalkan dalam 20% kasus sementara 80% sisanya ditangani oleh kompleksitas terbatas dan beban kognitif API generik.

Apa yang benar-benar kami maksudkan di sini adalah keteraturan bahasa dan bantuan API generik, tidak ada salahnya. Kontra itu benar-benar tidak dikonseptualisasikan dengan benar.

Solusi alternatif:

• gunakan struktur yang lebih sederhana daripada struktur yang rumit
  
  
  
  • misalnya gunakan map[int]struct{} alih-alih Set
  
  

Rob Pike (dan saya juga melihat dia membuat poin itu di video) tampaknya kehilangan poin bahwa wadah generik tidak cukup untuk membuat fungsi generik. Kita membutuhkan T di map[T] sehingga kita dapat meneruskan tipe data generik di sekitar fungsi untuk input, output, dan untuk struct kita sendiri. Generik hanya pada parameter tipe kontainer sepenuhnya tidak cukup untuk mengekspresikan API generik dan API generik diperlukan untuk kompleksitas terbatas dan beban kognitif serta memperoleh keteraturan dalam ekosistem bahasa. Saya juga belum melihat peningkatan level refactoring (sehingga berkurangnya komposisi modul yang tidak dapat dengan mudah di-refactored) yang dibutuhkan kode non-generik, itulah yang menjadi Masalah Ekspresi yang saya sebutkan di posting pertama saya.

Di bagian Pendekatan Umum :

Template paket
Ini adalah pendekatan yang digunakan oleh Modula-3, OCaml, SML (disebut "functors"), dan Ada. Alih-alih menentukan jenis individu untuk spesialisasi, seluruh paket bersifat generik. Anda mengkhususkan paket dengan memperbaiki parameter tipe saat mengimpor.

Saya mungkin salah tetapi ini sepertinya tidak sepenuhnya benar. Fungsi ML (jangan dikelirukan dengan fungsi FP) juga dapat mengembalikan output yang tetap tipe parametrised. Tidak akan ada cara untuk menggunakan algoritme dalam fungsi generik lainnya, jadi modul generik tidak akan dapat digunakan kembali (dengan mengimpor dengan tipe konkret ke) modul generik lainnya. Ini tampaknya merupakan upaya untuk menyederhanakan dan kemudian sepenuhnya kehilangan titik generik, penggunaan kembali modul, dll.

Sebaliknya pemahaman saya adalah bahwa parameter tipe paket (alias modul) memungkinkan kemampuan untuk menerapkan parameter tipe ke pengelompokan struct , interface , dan func .

Sistem tipe yang lebih rumit
Ini adalah pendekatan yang dilakukan Haskell dan Rust.
[…]
Kontra:

• sulit untuk menyesuaikan dengan bahasa yang lebih sederhana (https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)

Mengutip @ianlancetaylor dalam dokumen tertaut:

Jika Anda percaya itu, maka perlu ditunjukkan bahwa inti dari
peta dan kode irisan di runtime Go tidak umum dalam arti
menggunakan polimorfisme tipe. Ini generik dalam artian terlihat
ketik informasi refleksi untuk melihat cara memindahkan dan membandingkan jenis
nilai-nilai. Jadi kami memiliki bukti dengan keberadaan bahwa menulis dapat diterima
kode "generik" di Go dengan menulis kode non-polimorfik yang menggunakan type
refleksi informasi secara efisien, dan kemudian untuk membungkus kode itu dalam
boilerplate aman tipe waktu kompilasi (dalam kasus peta dan irisan
pelat ketel ini, tentu saja, disediakan oleh kompiler).

Dan itulah yang dilakukan oleh kompiler yang mentranspilasikan dari superset Go dengan tambahan generik, akan ditampilkan sebagai kode Go. Tetapi pembungkusnya tidak akan didasarkan pada beberapa penggambaran seperti paket, karena itu akan kekurangan komposisi yang telah saya sebutkan. Intinya adalah bahwa tidak ada jalan pintas ke sistem tipe generik yang dapat dikomposisi dengan baik. Entah kita melakukannya dengan benar atau tidak melakukan apa pun, karena menambahkan beberapa peretasan yang tidak dapat dikomposisi yang tidak benar-benar generik pada akhirnya akan menciptakan inersia clusterfuck dari tambal sulam setengah-setengah generikitas dan ketidakteraturan kasus sudut dan solusi membuat kode ekosistem Go tidak dapat dimengerti.

Juga benar bahwa kebanyakan orang yang menulis program Go kompleks yang besar memiliki
tidak menemukan kebutuhan yang signifikan untuk obat generik. Sejauh ini lebih seperti
kutil yang menjengkelkan - kebutuhan untuk menulis tiga baris boilerplate untuk
setiap jenis untuk diurutkan--bukan penghalang utama untuk menulis berguna
kode.

Ya, ini telah menjadi salah satu pemikiran di benak saya apakah pergi ke sistem kelas tipe yang meledak sepenuhnya dapat dibenarkan. Jika semua perpustakaan Anda berbasis di sekitarnya, maka tampaknya itu bisa menjadi harmoni yang indah, tetapi jika kita merenungkan tentang kelambanan peretasan Go yang ada untuk generik, maka mungkin sinergi tambahan yang diperoleh akan rendah untuk banyak proyek. ?

Tetapi jika transpiler dari sintaks kelas tipe meniru cara manual yang ada Go dapat memodelkan obat generik (Sunting: yang baru saja saya baca bahwa @andrewcmyers menyatakan masuk akal ), ini mungkin kurang memberatkan dan menemukan sinergi yang bermanfaat. Sebagai contoh, saya menyadari bahwa dua kelas tipe parameter dapat ditiru dengan interface diimplementasikan pada struct yang mengemulasi Tuple, atau @jba menyebutkan ide untuk menggunakan interface inline dalam konteks . Rupanya struct secara struktural alih-alih diketik secara nominal kecuali diberi nama dengan type ? Saya juga mengkonfirmasi metode interface dapat memasukkan interface lain sehingga mungkin dimungkinkan untuk melakukan transpile dari HKT dalam contoh pengurutan Anda yang saya tulis di posting saya sebelumnya di sini. Tapi saya perlu memikirkan ini lebih jauh ketika saya tidak begitu mengantuk.

Saya pikir cukup adil untuk mengatakan bahwa sebagian besar tim Go tidak menyukai C++
templat, di mana satu bahasa lengkap Turing telah dilapisi
bahasa Turing lain yang lengkap sehingga kedua bahasa tersebut memiliki
sintaks yang sama sekali berbeda, dan program dalam kedua bahasa adalah
ditulis dengan cara yang sangat berbeda. Template C++ berfungsi sebagai peringatan
kisah karena implementasi yang kompleks telah merasuki keseluruhan
pustaka standar, menyebabkan pesan kesalahan C++ menjadi sumber
heran dan takjub. Ini bukan jalan yang akan diikuti Go.

Saya ragu siapa pun akan tidak setuju! Manfaat monomorfisasi adalah ortogonal dengan kerugian dari mesin metaprogramming generik lengkap Turing.

Btw, kesalahan desain template C++ bagi saya tampaknya merupakan esensi generatif yang sama dari cacat fungsi ML generatif (sebagai lawan dari aplikatif). Prinsip Kekuatan Terkecil berlaku.

@ianlancetaylor menulis:

Sangat mengecewakan melihat Go menjadi semakin kompleks dengan menambahkan tipe parameter bawaan.

Terlepas dari spekulasi dalam masalah ini, saya pikir ini sangat tidak mungkin terjadi.

Saya berharap begitu. Saya sangat yakin bahwa Go harus menambahkan sistem generik yang koheren atau hanya menerima bahwa ia tidak akan pernah memiliki sistem generik.

Saya pikir garpu ke transpiler lebih mungkin terjadi, sebagian karena saya memiliki dana untuk mengimplementasikannya dan saya tertarik untuk melakukannya. Namun saya masih menganalisis situasinya.

Itu akan merusak ekosistem, tapi setidaknya Go bisa tetap murni dengan prinsip minimalisnya. Jadi untuk menghindari retaknya ekosistem dan memungkinkan beberapa inovasi lain yang saya inginkan, saya mungkin tidak akan menjadikannya superset dan menamakannya Zero sebagai gantinya.

@pciet menulis:

Pilihan saya adalah tidak untuk aplikasi generik yang digeneralisasi, ya untuk lebih banyak fungsi generik bawaan seperti append dan copy yang bekerja pada beberapa tipe dasar. Mungkin sort dan search dapat ditambahkan untuk jenis koleksi?

Memperluas kelembaman ini mungkin akan mencegah fitur generik yang komprehensif untuk membuatnya menjadi Go. Mereka yang menginginkan obat generik cenderung pergi ke padang rumput yang lebih hijau. @andrewcmyers mengulangi ini:

Ini ~adalah~ akan mengecewakan melihat Go menjadi lebih dan lebih kompleks dengan menambahkan tipe parameter bawaan. Akan lebih baik hanya menambahkan dukungan bahasa untuk programmer untuk menulis tipe parameter mereka sendiri.

@shelby3

Afaik, satu-satunya cara untuk melakukan wadah/pengumpulan heterogen di Go sekarang adalah dengan memasukkan semua tipe ke antarmuka kosong{} yang membuang informasi pengetikan dan akan saya anggap memerlukan pemeriksaan tipe cast dan runtime, yang semacam2 mengalahkan titik mengetik statis.

Lihat pola pembungkus dalam komentar di atas untuk pemeriksaan tipe statis kumpulan{} antarmuka di Go.

Intinya adalah bahwa tidak ada jalan pintas ke sistem tipe generik yang dapat dikomposisi dengan baik. Entah kami melakukannya dengan benar atau tidak melakukan apa pun, karena menambahkan beberapa peretasan yang tidak dapat dikomposisi yang sebenarnya bukan obat generik…

Bisakah Anda menjelaskan ini lebih lanjut? Untuk kasus tipe koleksi yang memiliki antarmuka yang mendefinisikan perilaku umum yang diperlukan dari item yang terkandung tampaknya masuk akal untuk menulis fungsi.

@pciet kode ini benar-benar melakukan hal yang persis seperti yang dijelaskan oleh @shelby3 dan mempertimbangkan antipattern. Mengutip Anda dari sebelumnya:

Ini memberikan contoh dokumentasi dan pengujian yang mengetik pola pembungkus (terima kasih @pierrre) untuk keamanan tipe waktu kompilasi dan juga memiliki pemeriksaan refleksi untuk keamanan tipe run-time.

Anda mengambil kode yang tidak memiliki informasi tipe dan, berdasarkan tipe per tipe, menambahkan gips dan inspeksi tipe runtime menggunakan refleksi. Inilah yang dikeluhkan oleh @shelby3 . Saya cenderung menyebut pendekatan ini "monomorphization-by-hand" dan merupakan jenis tugas yang membosankan yang menurut saya paling baik digunakan oleh kompiler.

Pendekatan ini memiliki sejumlah kelemahan:

• Memerlukan pembungkus tipe demi tipe, dipelihara dengan tangan atau alat seperti go generate
• (Jika dilakukan dengan tangan alih-alih alat) peluang untuk membuat kesalahan di boilerplate yang tidak akan ditangkap sampai runtime
• Memerlukan pengiriman dinamis alih-alih pengiriman statis, yang keduanya lebih lambat dan menggunakan lebih banyak memori
• Menggunakan refleksi runtime daripada pernyataan tipe waktu kompilasi, yang juga lambat
• Tidak dapat dikomposisi: bertindak sepenuhnya pada tipe konkret tanpa peluang untuk menggunakan batas tipe-kelas (atau bahkan seperti antarmuka) pada tipe, kecuali jika Anda melakukan handroll lapisan tipuan lain untuk setiap antarmuka non-kosong yang juga ingin Anda abstraksi

Bisakah Anda menjelaskan ini lebih lanjut? Untuk kasus tipe koleksi yang memiliki antarmuka yang mendefinisikan perilaku umum yang diperlukan dari item yang terkandung tampaknya masuk akal untuk menulis fungsi.

Sekarang di mana pun Anda ingin menggunakan ikatan alih-alih atau sebagai tambahan untuk tipe beton, Anda juga harus menulis boilerplate pengecekan tipe yang sama untuk setiap tipe antarmuka. Itu hanya semakin menambah ledakan (mungkin kombinatorial) dari pembungkus tipe statis yang harus Anda tulis.

Ada juga ide yang, sejauh yang saya tahu, sama sekali tidak dapat diekspresikan dalam sistem tipe Go saat ini, seperti ikatan pada kombinasi antarmuka. Bayangkan kita memiliki:

type Foo interface {
    ...
}

type Bar interface {
    ...
}

Bagaimana kita mengekspresikan, menggunakan pemeriksaan tipe statis murni, bahwa kita menginginkan tipe yang mengimplementasikan Foo dan Bar ? Sejauh yang saya tahu ini tidak mungkin di Go (singkat dari menggunakan pemeriksaan runtime yang mungkin gagal, menghindari keamanan tipe statis).

Dengan sistem generik berbasis kelas tipe, kita dapat menyatakan ini sebagai:

func baz<T Foo + Bar>(t T) {
    ...
}

@tarcieri

Bagaimana kita mengekspresikan, menggunakan pemeriksaan tipe statis murni, bahwa kita menginginkan tipe yang mengimplementasikan Foo dan Bar?

hanya seperti ini:

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet rapi, TIL

Secara pribadi saya menganggap refleksi runtime sebagai fitur yang salah, tetapi itu hanya saya ... Saya dapat menjelaskan alasannya jika ada yang tertarik.

Saya pikir siapa pun yang mengimplementasikan obat generik dalam bentuk apa pun harus membaca "Elemen Pemrograman" Stepanov beberapa kali terlebih dahulu. Itu akan menghindari banyak masalah Tidak Diciptakan Di Sini dan menemukan kembali roda. Setelah membaca itu harus jelas mengapa "Konsep C++" dan "Haskell Typeclasses" adalah cara yang tepat untuk melakukan obat generik.

Saya melihat masalah ini tampaknya aktif kembali
Ini adalah taman bermain proposal strawman
https://go-li.github.io/test.html
cukup rekatkan program demo dari sini
https://github.com/go-li/demo

Terima kasih banyak atas evaluasi Anda terhadap parameter tunggal ini
fungsi generik.

Kami memelihara gccgo yang diretas dan
proyek ini tidak akan mungkin tanpamu, jadi kami
ingin berkontribusi kembali.

Kami juga menantikan obat generik apa pun yang Anda adopsi, teruslah bekerja dengan baik!

@anlhord di mana detail implementasi tentang ini? Di mana seseorang dapat membaca tentang sintaks? Apa yang diimplementasikan? Apa yang tidak diimplementasikan? Apa spesifikasi untuk implementasi ini? Apa pro dan kontra untuk itu?

Tautan taman bermain berisi kemungkinan terburuk dari ini:

package main

import "fmt"

func main() {
    fmt.Println("Hello, playground")
}

Kode itu tidak memberi tahu saya cara menggunakannya dan apa yang bisa saya uji.

Jika Anda dapat memperbaiki hal-hal itu, itu akan membantu lebih memahami apa proposal Anda dan bagaimana perbandingannya dengan yang sebelumnya / lihat bagaimana poin-poin lain yang diangkat di sini berlaku atau tidak.

Semoga ini membantu Anda memahami masalah dengan komentar Anda.

@joho menulis:

Akankah ada nilai pada literatur akademis untuk panduan dalam mengevaluasi pendekatan?

Satu-satunya makalah yang saya baca tentang topik ini adalah Apakah pengembang mendapat manfaat dari tipe generik ? (maaf paywall, Anda mungkin mencari cara untuk mengunduh pdf di Google) yang memiliki yang berikut untuk dikatakan

Akibatnya, interpretasi konservatif dari eksperimen
adalah bahwa tipe generik dapat dianggap sebagai tradeoff
antara karakteristik dokumentasi positif dan
karakteristik ekstensibilitas negatif.

Saya menganggap OOP dan subkelas (misalnya kelas di Java dan C++) tidak akan dianggap serius karena Go sudah memiliki interface seperti kelas tipe (tanpa parameter tipe generik T eksplisit), Java adalah dikutip sebagai apa yang tidak boleh disalin, dan karena banyak yang berpendapat bahwa itu adalah anti-pola. Upthread Saya telah menautkan ke beberapa argumen itu. Kita bisa masuk lebih dalam ke analisis itu jika ada yang tertarik.

Saya belum mempelajari penelitian yang lebih baru seperti sistem Genus yang disebutkan di atas . Saya waspada terhadap sistem "wastafel dapur" yang mencoba menggabungkan begitu banyak paradigma (misalnya subkelas, pewarisan berganda, OOP, linearisasi sifat, implicit , kelas tipe, tipe abstrak, dll), karena keluhan tentang Scala memiliki begitu banyak kasus sudut dalam praktik, meskipun mungkin itu akan membaik dengan Scala 3 (alias Dotty dan kalkulus DOT). Saya ingin tahu apakah tabel perbandingan mereka membandingkan dengan Scala 3 eksperimental atau versi Scala saat ini?

Jadi biasanya, yang tersisa adalah fungsi ML dan kelas tipe Haskell dalam hal sistem generik yang terbukti, yang secara signifikan meningkatkan ekstensibilitas dan fleksibilitas dibandingkan dengan subkelas OOP+.

Saya menuliskan beberapa diskusi pribadi @keean dan saya tentang modul functor ML versus kelas tipe. Sorotan tampaknya:

• typeclasses _modelkan aljabar_ (tetapi tanpa aksioma yang dicentang ) dan implementasikan setiap tipe data untuk setiap antarmuka hanya dengan satu cara. Sehingga memungkinkan pemilihan implisit dari implementasi oleh kompiler tanpa anotasi di situs panggilan.

• Fungsi aplikatif memiliki transparansi referensial sedangkan fungsi generatif membuat instance baru pada setiap instantiasi, yang berarti mereka bukan invarian urutan inisialisasi.

• Fungsi ML lebih kuat/fleksibel daripada kelas tipe, tetapi hal ini memerlukan lebih banyak anotasi dan berpotensi lebih banyak interaksi kasus sudut. Dan menurut @keean mereka memerlukan tipe dependen (untuk tipe terkait ) yang merupakan sistem tipe yang lebih kompleks. @keean berpikir _ekspresi generikitas Stepanov sebagai aljabar_ plus kelas tipe cukup kuat dan fleksibel , sehingga tampaknya menjadi sweet spot untuk generik yang canggih, terbukti dengan baik (di Haskell dan sekarang di Rust). Namun, aksioma tidak ditegakkan oleh kelas tipe.

• Saya telah menyarankan untuk menambahkan serikat pekerja untuk wadah heterogen dengan kelas tipe untuk diperluas di sepanjang sumbu lain dari Masalah Ekspresi, meskipun ini membutuhkan kekekalan atau penyalinan (hanya untuk kasus di mana ekstensibilitas heterogen digunakan) yang diketahui memiliki O(log n) perlambatan dibandingkan dengan imperativity bisa berubah tak terkendali.

@larsth menulis:

Mungkin menarik untuk memiliki satu atau lebih transpiler eksperimental - kode sumber generik Go ke kompiler kode sumber Go 1.xy.

_{PS Saya ragu Go akan mengadopsi sistem pengetikan yang begitu canggih, tetapi saya sedang mempertimbangkan transpiler ke sintaks Go yang ada seperti yang saya sebutkan di posting saya sebelumnya (lihat edit di bagian bawah). Dan saya ingin sistem generik yang kuat bersama dengan fitur Go yang sangat diinginkan itu. Obat generik kelas tipe di Go tampaknya seperti yang saya inginkan.}

@bcmils menulis tentang proposalnya tentang fungsi waktu kompilasi untuk generik:

Saya pernah mendengar argumen yang sama yang digunakan untuk menganjurkan mengekspor tipe interface daripada tipe konkret di Go API, dan kebalikannya ternyata lebih umum: abstraksi prematur membatasi tipe dan menghalangi ekstensi API. (Untuk satu contoh seperti itu, lihat #19584.) Jika Anda ingin mengandalkan garis argumen ini, saya pikir Anda perlu memberikan beberapa contoh konkret.

Memang benar bahwa abstraksi sistem tipe harus mengabaikan beberapa derajat kebebasan dan kadang-kadang kita telah keluar dari batasan tersebut dengan "tidak aman" (yaitu melanggar abstraksi yang diperiksa secara statis), namun itu harus ditukar dengan manfaat dari decoupling modular dengan invarian beranotasi ringkas.

Saat merancang sistem untuk generik, kami cenderung ingin meningkatkan keteraturan dan prediktabilitas ekosistem sebagai salah satu tujuan utama, terutama jika filosofi inti Go dipertimbangkan (misalnya rata-rata pemrogram adalah prioritas).

Prinsip Kekuatan Terkecil berlaku. Kekuatan/fleksibilitas fungsi waktu kompilasi "tersembunyi" invarian untuk generikitas harus ditimbang terhadap kemampuannya untuk membahayakan misalnya keterbacaan kode sumber dalam ekosistem (di mana decoupling modular sangat penting karena pembaca tidak 'tidak perlu membaca jumlah kode yang berpotensi tidak terbatas karena dependensi transitif implisit, untuk memahami modul/paket yang diberikan!). Resolusi implisit contoh implementasi kelas tipe memiliki masalah ini jika aljabar mereka tidak dipatuhi .

Tentu, tapi itu sudah berlaku untuk banyak kendala implisit di Go yang terlepas dari mekanisme pemrograman umum apa pun.

Misalnya, suatu fungsi dapat menerima parameter tipe antarmuka dan awalnya memanggil metodenya secara berurutan. Jika fungsi itu kemudian berubah untuk memanggil metode tersebut secara bersamaan (dengan memunculkan goroutine tambahan), batasan "harus aman untuk penggunaan bersamaan" tidak tercermin dalam sistem tipe.

Namun afaik Go tidak mencoba merancang abstraksi untuk memodulasi efek tersebut. Rust memiliki abstraksi seperti itu (yang menurut saya berlebihan pita/tsuris/membatasi untuk beberapa/sebagian besar kasus penggunaan dan saya berpendapat untuk abstraksi model utas tunggal yang lebih mudah namun sayangnya Go tidak mendukung pembatasan semua goroutine yang muncul ke utas yang sama ) . Dan Haskell memerlukan kontrol monadik atas efek karena menegakkan fungsi murni untuk transparansi referensial .

@alercah menulis:

Saya pikir kelemahan terbesar dari batasan yang disimpulkan adalah mereka membuatnya mudah untuk menggunakan tipe dengan cara yang memperkenalkan batasan tanpa sepenuhnya memahaminya. Dalam kasus terbaik, ini hanya berarti bahwa pengguna Anda mungkin mengalami kegagalan waktu kompilasi yang tidak terduga, tetapi dalam kasus terburuk, ini berarti Anda dapat merusak paket untuk konsumen dengan memperkenalkan batasan baru secara tidak sengaja. Batasan yang ditentukan secara eksplisit akan menghindari hal ini.

Sepakat. Mampu secara diam-diam memecahkan kode di modul lain karena invarian dari tipe tidak dijelaskan secara eksplisit sangat berbahaya.

@andrewcmyers menulis:

Untuk lebih jelasnya, saya tidak menganggap pembuatan kode gaya makro, baik yang dilakukan dengan gen, cpp, gofmt -r, atau alat makro/templat lainnya, sebagai solusi yang baik untuk masalah generik bahkan jika distandarisasi. Ini memiliki masalah yang sama dengan template C++: kode mengasapi, kurangnya pemeriksaan tipe modular, dan kesulitan debugging. Ini menjadi lebih buruk saat Anda mulai, seperti biasa, membangun kode generik dalam hal kode generik lainnya. Menurut saya, keuntungannya terbatas: itu akan membuat hidup relatif sederhana untuk penulis kompiler Go dan menghasilkan kode yang efisien — kecuali ada tekanan cache instruksi, situasi yang sering terjadi dalam perangkat lunak modern!

@keean tampaknya setuju dengan Anda.

@shelby3 terima kasih atas komentarnya. Bisakah Anda lain kali membuat komentar / pengeditan langsung di dokumen itu sendiri. Lebih mudah untuk melacak di mana hal-hal perlu diperbaiki dan lebih mudah untuk memastikan bahwa semua catatan mendapatkan respons yang tepat.

Bagian Ikhtisar tampaknya menyiratkan bahwa penggunaan universal referensi tinju Java untuk instance ...

Menambahkan komentar untuk memperjelas, bahwa itu tidak dimaksudkan sebagai daftar lengkap. Ini terutama ada sehingga orang mendapatkan inti dari pertukaran yang berbeda. Daftar lengkap pendekatan yang berbeda lebih lanjut di bawah ini.

Struktur umum cenderung mengakumulasi fitur dari semua penggunaan, menghasilkan peningkatan waktu kompilasi atau kode mengasapi atau membutuhkan tautan yang lebih cerdas.
Untuk kelas tipe ini tidak benar atau kurang menjadi masalah, karena antarmuka hanya perlu diimplementasikan untuk tipe data yang dipasok ke fungsi yang menggunakan antarmuka tersebut. Kelas tipe adalah tentang pengikatan implementasi yang terlambat ke antarmuka, tidak seperti OOP yang mengikat setiap tipe data ke metodenya untuk implementasi kelas.

Pernyataan itu adalah tentang apa yang terjadi pada struktur data generik dalam jangka panjang. Dengan kata lain, struktur data generik sering berakhir dengan mengumpulkan semua kegunaan yang berbeda -- daripada memiliki beberapa implementasi yang lebih kecil untuk tujuan yang berbeda. Sebagai contoh lihat https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

Penting untuk dicatat bahwa, hanya "desain mekanis" dan "fleksibilitas sebanyak mungkin" tidak cukup untuk menciptakan "solusi generik" yang baik. Itu juga membutuhkan instruksi yang baik, bagaimana sesuatu harus digunakan dan apa yang harus dihindari, dan mempertimbangkan bagaimana orang akhirnya menggunakannya.

Struktur umum dan API yang beroperasi di atasnya cenderung lebih abstrak daripada API yang dibuat khusus ...

Argumen tandingan yang menurut saya secara signifikan memperbaiki kekhawatiran ini adalah bahwa beban kognitif untuk mempelajari sejumlah kasus khusus yang tidak terbatas, implementasi ulang dari algoritma generik yang pada dasarnya sama, tidak terbatas ...

Menambahkan catatan tentang beban kognitif dari banyak API serupa.

Implementasi ulang kasus khusus tidak terbatas dalam praktiknya. Anda hanya akan melihat sejumlah spesialisasi.

Ini bukan penipu yang valid.

Anda mungkin tidak setuju dengan beberapa poin, saya tidak setuju dengan beberapa poin, tetapi saya memahami sudut pandang mereka dan mencoba memahami masalah yang dihadapi orang sehari-hari. Tujuan dari dokumen tersebut adalah untuk mengumpulkan pendapat yang berbeda, bukan untuk menilai "betapa menyebalkannya sesuatu bagi seseorang".

Namun, dokumen tersebut mengambil sikap pada "masalah yang dapat dilacak ke masalah dunia nyata", karena masalah yang abstrak dan difasilitasi di forum cenderung menjadi obrolan yang tidak berarti tanpa pemahaman apa pun yang dibangun.

Apa yang benar-benar kami maksudkan di sini adalah keteraturan bahasa dan bantuan API generik, tidak ada salahnya.

Tentu dalam praktiknya Anda mungkin memerlukan gaya pengoptimalan ini hanya untuk kurang dari 1% kasus.

Solusi alternatif:

Solusi alternatif tidak dimaksudkan sebagai pengganti obat generik. Tapi, lebih kepada daftar solusi potensial untuk berbagai jenis masalah.

Template paket

Saya mungkin salah tetapi ini sepertinya tidak sepenuhnya benar. Fungsi ML (jangan dikelirukan dengan fungsi FP) juga dapat mengembalikan output yang tetap tipe parametrised.

Bisakah Anda memberikan kata-kata yang lebih jelas dan jika perlu dibagi menjadi dua pendekatan yang berbeda?

@egonelbre terima kasih juga telah menanggapi sehingga saya dapat mengetahui poin mana yang perlu saya klarifikasi lebih lanjut.

Bisakah Anda lain kali membuat komentar / pengeditan langsung di dokumen itu sendiri.

Mohon maaf jika saya dapat mematuhinya tetapi saya tidak pernah menggunakan fitur diskusi Google Doc, tidak punya waktu untuk mempelajarinya, dan saya juga lebih suka dapat menautkan ke diskusi saya di Github untuk referensi di masa mendatang.

Sebagai contoh lihat https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

Desain perpustakaan koleksi Scala dikritik oleh banyak orang, termasuk salah satu mantan anggota tim kunci mereka . Sebuah komentar yang diposting ke LtU mewakili. Catatan Saya menambahkan yang berikut ini ke salah satu posting saya sebelumnya di utas ini untuk mengatasi ini:

Saya waspada terhadap sistem "wastafel dapur" yang mencoba mencampur begitu banyak paradigma (misalnya subkelas, pewarisan berganda, OOP, linearisasi sifat, implicit , kelas tipe, tipe abstrak, dll), karena keluhan tentang Scala memiliki begitu banyak kasus sudut dalam praktik, meskipun mungkin itu akan membaik dengan Scala 3 (alias Dotty dan kalkulus DOT).

Saya tidak berpikir perpustakaan koleksi Scala akan mewakili perpustakaan yang dibuat untuk PL dengan hanya kelas tipe untuk polimorfisme. Selain itu, koleksi Scala menggunakan anti-pola pewarisan , yang menyebabkan hierarki kompleks, dikombinasikan dengan implicit helper seperti CanBuildFrom yang meledakkan anggaran kompleksitas. Dan saya pikir jika poin @keean dipatuhi tentang _Elements of Programming_ Stepanov sebagai aljabar , perpustakaan koleksi yang elegan dapat dibuat. Itu adalah alternatif pertama yang saya lihat untuk perpustakaan koleksi berbasis functor (FP) (yaitu tidak menyalin Haskell ) juga berdasarkan matematika. Saya ingin melihat ini dalam praktik, yang merupakan salah satu alasan saya berkolaborasi/berdiskusi dengannya tentang desain PL baru. Dan mulai saat ini, saya berencana untuk mengubah bahasa itu menjadi Go (walaupun saya sudah bertahun-tahun mencoba mencari cara untuk menghindarinya). Jadi mudah-mudahan kita bisa segera bereksperimen untuk melihat bagaimana hasilnya.

Persepsi saya adalah bahwa komunitas/filsafat Go lebih suka menunggu untuk melihat apa yang berhasil dalam praktik dan mengadopsinya nanti setelah terbukti, daripada terburu-buru dan mencemari bahasa dengan eksperimen yang gagal. Karena seperti yang Anda ulangi, semua klaim abstrak ini tidak begitu konstruktif (kecuali mungkin untuk ahli teori desain PL). Juga mungkin tidak masuk akal untuk merancang sistem generik yang koheren oleh komite.

Itu juga membutuhkan instruksi yang baik, bagaimana sesuatu harus digunakan dan apa yang harus dihindari, dan mempertimbangkan bagaimana orang akhirnya menggunakannya.

Dan saya pikir itu akan membantu untuk tidak mencampur begitu banyak paradigma berbeda yang tersedia untuk programmer dalam bahasa yang sama. Tampaknya tidak perlu ( @keean dan saya perlu membuktikan klaim itu). Saya pikir kami berdua menganggap filosofi bahwa anggaran kompleksitas terbatas dan apa yang Anda tinggalkan dari PL yang sama pentingnya dengan fitur yang disertakan.

Namun, dokumen tersebut mengambil sikap pada "masalah yang dapat dilacak ke masalah dunia nyata", karena masalah yang abstrak dan difasilitasi di forum cenderung menjadi obrolan yang tidak berarti tanpa pemahaman apa pun yang dibangun.

Sepakat. Dan juga sulit bagi semua orang untuk mengikuti poin-poin abstrak. Iblis ada di detail dan hasil aktual di alam liar.

Tentu dalam praktiknya Anda mungkin memerlukan gaya pengoptimalan ini hanya untuk kurang dari 1% kasus.

Go sudah memiliki interface untuk generik, sehingga dapat menangani kasus di mana tidak perlu polimorfisme parametrik pada tipe T untuk instance antarmuka yang disediakan oleh situs panggilan.

Saya pikir membaca di suatu tempat, mungkin itu upthread, argumen bahwa sebenarnya perpustakaan standar Go menderita inkonsistensi penggunaan optimal dari idiom terbaru. Saya tidak tahu apakah itu benar, karena saya belum berpengalaman dengan Go. Maksud saya adalah bahwa paradigma generik yang dipilih menginfeksi semua perpustakaan. Jadi ya sampai sekarang Anda dapat mengklaim hanya 1% dari kode yang membutuhkannya, karena sudah ada inersia dalam idiom yang menghindari kebutuhan akan obat generik.

Anda mungkin benar. Saya juga skeptis tentang seberapa banyak saya akan menggunakan fitur bahasa tertentu. Saya pikir eksperimen untuk mencari tahu adalah cara saya akan melanjutkan. Perancangan PL merupakan proses yang iteratif, maka permasalahan yang melawan inersia yang berkembang membuat proses iterasi menjadi sulit. Jadi saya kira Rob Pike benar dalam video di mana dia menyarankan menulis program yang menulis kode untuk program (artinya pergi menulis alat generasi dan transpiler) untuk bereksperimen dan menguji ide.

Ketika kami dapat menunjukkan bahwa serangkaian fitur tertentu lebih unggul dalam praktik (dan mudah-mudahan juga popularitas penggunaan) dibandingkan yang saat ini ada di Go, maka kami mungkin dapat melihat beberapa bentuk konsensus seputar menambahkannya ke Go. Saya mendorong orang lain untuk juga membuat sistem eksperimental yang berubah menjadi Go.

Bisakah Anda memberikan kata-kata yang lebih jelas dan jika perlu dibagi menjadi dua pendekatan yang berbeda?

Saya menambahkan suara saya kepada mereka yang ingin mencegah upaya untuk menempatkan beberapa fitur templating yang terlalu sederhana di Go dan mengklaim itu generik. IOW, saya pikir sistem generik yang berfungsi dengan baik yang tidak akan berakhir dengan inersia buruk pada dasarnya tidak sesuai dengan keinginan untuk memiliki desain yang terlalu sederhana untuk obat generik. Afaik, sistem generik membutuhkan desain holistik yang dipikirkan dengan matang dan terbukti dengan baik. Menggemakan apa yang @larsth tulis , saya mendorong mereka yang memiliki proposal serius untuk terlebih dahulu membuat transpiler (atau mengimplementasikannya dalam fork dari gccgo frontend) dan kemudian bereksperimen dengan proposal tersebut sehingga kita semua dapat lebih memahami batasannya. Saya didorong untuk membaca upthread bahwa @ianlancetaylor tidak berpikir polusi inersia buruk akan ditambahkan ke Go. Adapun keluhan khusus saya tentang proposal parametrisasi tingkat paket, saran saya untuk siapa yang pernah mengusulkannya, silakan renungkan apakah akan membuat kompiler yang bisa kita semua gunakan untuk bermain dan kemudian kita semua bisa berbicara tentang contoh apa yang kita suka dan tidak' tidak suka tentang itu. Kalau tidak, kita berbicara melewati satu sama lain karena mungkin saya bahkan tidak mengerti dengan benar proposal seperti yang dijelaskan secara abstrak. Saya pasti tidak mengerti proposalnya, karena saya tidak mengerti bagaimana paket parametrised dapat digunakan kembali di paket lain yang juga parametrised. TKI, jika sebuah paket membutuhkan parameter, maka paket tersebut juga perlu membuat instance paket lain dengan parameter. Tetapi tampaknya proposal tersebut menyatakan bahwa satu-satunya cara untuk membuat instance paket parametrised adalah dengan tipe beton, bukan parameter tipe.

Permintaan maaf yang begitu bertele-tele. Ingin memastikan saya tidak salah paham.

@shelby3 ah, saya kemudian salah memahami keluhan awal. Pertama saya harus menjelaskan bahwa bagian dalam "Pendekatan Generik" bukanlah proposal yang konkret. Mereka adalah pendekatan atau, dengan kata lain, keputusan desain yang lebih besar yang mungkin diambil seseorang dalam pendekatan generik yang konkret. Namun, pengelompokan tersebut sangat dimotivasi oleh implementasi yang ada atau proposal konkrit/informal. Juga, saya menduga setidaknya ada 5 ide besar yang masih hilang dari daftar itu.

Untuk pendekatan "template paket" ada dua variasi (lihat diskusi terkait dalam dokumen):

1. paket generik berbasis "antarmuka",
2. paket generik secara eksplisit.

Untuk 1. tidak memerlukan paket generik untuk melakukan sesuatu yang istimewa -- misalnya container/ring saat ini akan dapat digunakan untuk spesialisasi. Bayangkan "spesialisasi" di sini sebagai mengganti semua instance antarmuka dalam paket dengan tipe konkret (dan mengabaikan impor melingkar). Ketika paket itu sendiri mengkhususkan paket lain, ia dapat menggunakan "antarmuka" sebagai spesialisasi - maka penggunaan ini juga akan terspesialisasi.

Untuk 2. Anda dapat melihatnya dalam dua cara. Salah satunya adalah spesialisasi beton rekursif pada setiap impor -- mirip dengan templating/makro, tidak akan ada "paket yang diterapkan sebagian". Tentu saja dapat juga dilihat dari sisi fungsional, bahwa paket generik adalah parsial dengan parameter dan kemudian Anda mengkhususkannya.

Jadi, ya, Anda dapat menggunakan satu paket berparameter di paket lain.

Menggemakan apa yang @larsth tulis, saya mendorong mereka yang memiliki proposal serius untuk terlebih dahulu membuat transpiler (atau mengimplementasikannya di fork frontend gccgo) dan kemudian bereksperimen dengan proposal tersebut sehingga kita semua dapat lebih memahami batasannya.

Saya tahu ini tidak secara eksplisit diarahkan pada pendekatan itu, tetapi ia memiliki 4 prototipe berbeda untuk menguji gagasan tersebut. Tentu saja, mereka bukan transpiler penuh, tetapi mereka cukup untuk menguji beberapa ide. yaitu saya tidak yakin apakah ada yang telah menerapkan kasus "menggunakan paket berparameter dari yang lain".

Paket berparameter terdengar sangat mirip dengan modul ML (dan fungsi ML adalah parameternya bisa berupa paket lain). Ada dua cara ini dapat bekerja "aplikatif" atau "generatif". Fungsi aplikatif seperti nilai, atau tipe-alias. Fungsi generatif harus dibangun dan setiap instance berbeda. Cara lain untuk memikirkan hal ini, adalah agar sebuah paket bersifat aplikatif, paket itu harus murni (yaitu tidak ada variabel yang bisa berubah di tingkat paket). Jika ada status di tingkat paket, itu harus generatif karena status itu perlu diinisialisasi, dan penting "instance" dari paket generatif mana yang benar-benar Anda lewati sebagai parameter ke paket lain yang pada gilirannya harus generatif. Misalnya paket Ada bersifat generatif.

Masalah dengan pendekatan paket generatif adalah ia menciptakan banyak boilerplate, di mana Anda membuat instance paket dengan parameter. Anda dapat melihat generik Ada untuk melihat seperti apa tampilannya.

Kelas tipe menghindari boilerplate ini dengan memilih kelas tipe secara implisit berdasarkan tipe yang digunakan dalam fungsi saja. Anda juga dapat melihat kelas tipe sebagai kelebihan muatan terbatas dengan pengiriman ganda, di mana resolusi kelebihan muatan hampir selalu terjadi secara statis pada waktu kompilasi, dengan pengecualian untuk rekursi polimorfik dan tipe eksistensial (yang pada dasarnya adalah varian yang tidak dapat Anda singkirkan, Anda hanya dapat menggunakan antarmuka yang dikonfirmasi oleh varian).

Fungsi aplikatif seperti nilai, atau tipe-alias. Fungsi generatif harus dibangun dan setiap instance berbeda. Cara lain untuk memikirkan hal ini, adalah agar sebuah paket bersifat aplikatif, paket itu harus murni (yaitu tidak ada variabel yang bisa berubah di tingkat paket). Jika ada status di tingkat paket, itu harus generatif karena status itu perlu diinisialisasi, dan penting "instance" dari paket generatif mana yang benar-benar Anda lewati sebagai parameter ke paket lain yang pada gilirannya harus generatif. Misalnya paket Ada bersifat generatif.

Terima kasih atas terminologi yang tepat, saya perlu berpikir bagaimana mengintegrasikan ide-ide ini ke dalam dokumen.

Juga, saya tidak dapat melihat alasan mengapa Anda tidak dapat memiliki "tipe-alias otomatis untuk paket yang dihasilkan" - dalam arti sesuatu antara pendekatan "functor aplikatif" dan "fungtor generatif". Jelas, ketika paket tersebut memang berisi beberapa bentuk status, itu bisa menjadi rumit untuk di-debug dan dipahami.

Masalah dengan pendekatan paket generatif adalah ia menciptakan banyak boilerplate, di mana Anda membuat instance paket dengan parameter. Anda dapat melihat generik Ada untuk melihat seperti apa tampilannya.

Sejauh yang saya lihat, itu akan membuat lebih sedikit boilerplate daripada template C++ tetapi lebih dari kelas tipe. Apakah Anda memiliki program dunia nyata yang bagus untuk Ada yang menunjukkan masalahnya? _(Dengan dunia nyata, maksud saya kode yang digunakan/digunakan seseorang dalam produksi.)_

Tentu, lihat go-board Ada saya: https://github.com/keean/Go-Board-Ada/blob/master/go.adb

Meskipun ini adalah definisi produksi yang cukup longgar, kodenya dioptimalkan, berkinerja sebaik versi C++, dan sumber terbukanya, dan algoritmenya telah disempurnakan selama beberapa tahun. Anda juga dapat melihat versi C++: https://github.com/keean/Go-Board/blob/master/go.cpp

Ini menunjukkan (saya pikir) bahwa Ada generik adalah solusi yang lebih rapi daripada template C++ (tapi itu tidak sulit), di sisi lain sulit untuk melakukan akses cepat ke struktur data di Ada karena pembatasan mengembalikan referensi .

Jika Anda ingin melihat sistem generik paket untuk bahasa imperatif, saya pikir Ada adalah salah satu yang terbaik untuk dilihat. Sayang sekali mereka memutuskan untuk menjadi multi-paradigma dan menambahkan semua hal OO ke Ada. Ada adalah Pascal yang disempurnakan, dan Pascal adalah bahasa yang kecil dan elegan. Pascal plus Ada generik masih merupakan bahasa yang cukup kecil, tetapi akan jauh lebih baik menurut saya. Karena fokus Ada bergeser ke pendekatan OO menemukan dokumentasi yang baik dan contoh bagaimana melakukan hal yang sama dengan obat generik tampaknya sulit ditemukan.

Meskipun saya pikir kelas tipe memiliki beberapa keuntungan, saya bisa hidup dengan generik gaya Ada, ada beberapa masalah yang menahan saya untuk menggunakan Ada secara lebih luas, saya pikir itu salah nilai/objek (saya pikir sangat sedikit bahasa yang benar, 'C' menjadi satu-satunya), sulit untuk bekerja dengan pointer (variabel akses) dan untuk membuat abstraksi safe-pointer, dan itu tidak menyediakan cara untuk menggunakan paket dengan polimorfisme runtime (ini menyediakan model objek untuk ini, tetapi ia menambahkan paradigma yang sama sekali baru alih-alih mencoba menemukan cara untuk memiliki polimorfisme runtime menggunakan paket).

Solusi untuk polimorfisme runtime adalah membuat paket kelas satu sehingga instance tanda tangan paket dapat diteruskan sebagai argumen fungsi, sayangnya ini memerlukan tipe dependen (lihat pekerjaan yang dilakukan pada Tipe Objek Dependen untuk Scala untuk membersihkan kekacauan yang mereka buat tipe-sistem aslinya).

Jadi saya pikir obat generik paket dapat bekerja, tetapi Ada beberapa dekade untuk menangani semua kasus tepi, jadi saya akan melihat sistem generik produksi untuk melihat penyempurnaan apa yang digunakan dalam produksi yang dihasilkan. Namun Ada masih gagal karena paketnya bukan kelas satu, dan tidak dapat digunakan dalam polimorfisme runtime, dan ini perlu ditangani.

@keean menulis :

Secara pribadi saya menganggap refleksi runtime sebagai fitur yang salah, tetapi itu hanya saya ... Saya dapat menjelaskan alasannya jika ada yang tertarik.

Penghapusan tipe memungkinkan "Teorema gratis", yang memiliki implikasi praktis . Dapat ditulis (dan mungkin bahkan dapat dibaca karena hubungan transitif dengan kode imperatif?) refleksi runtime membuat tidak mungkin untuk menjamin transparansi referensial dalam kode apa pun dan dengan demikian pengoptimalan kompiler tertentu tidak dimungkinkan dan mengetik monad yang aman tidak dimungkinkan. Saya menyadari Rust bahkan belum memiliki fitur kekekalan. OTOH, refleksi memungkinkan pengoptimalan lain yang tidak mungkin dilakukan jika tidak dapat diketik secara statis.

Saya juga telah menyatakan upthread:

Dan itulah yang dilakukan oleh kompiler yang mentranspilasikan dari superset Go dengan tambahan generik, akan ditampilkan sebagai kode Go. Tetapi pembungkusnya tidak akan didasarkan pada beberapa penggambaran seperti paket, karena itu akan kekurangan komposisi yang telah saya sebutkan. Intinya adalah bahwa tidak ada jalan pintas ke sistem tipe generik yang dapat dikomposisi dengan baik. Entah kita melakukannya dengan benar atau tidak melakukan apa pun, karena menambahkan beberapa peretasan yang tidak dapat dikomposisi yang tidak benar-benar generik pada akhirnya akan menciptakan inersia clusterfuck dari tambal sulam setengah-setengah generikitas dan ketidakteraturan kasus sudut dan solusi membuat kode ekosistem Go tidak dapat dimengerti.

@keean menulis:

[…] agar sebuah paket menjadi aplikatif, paket itu harus murni (tidak ada variabel yang bisa berubah di tingkat paket)

Dan tidak ada fungsi tidak murni yang dapat digunakan untuk menginisialisasi variabel yang tidak dapat diubah.

@egonelbre menulis:

Jadi, ya, Anda dapat menggunakan satu paket berparameter di paket lain.

Apa yang tampaknya saya pikirkan adalah "paket parametrised kelas satu" dan polimorfisme runtime (alias dinamis) yang sepadan yang kemudian disebutkan oleh @keean , karena saya menganggap paket parametrised diusulkan sebagai pengganti kelas tipe atau OOP.

EDIT: tetapi ada dua kemungkinan arti untuk modul "kelas satu": modul sebagai nilai kelas satu seperti di Successor ML dan MixML yang dibedakan dari modul sebagai nilai kelas satu dengan tipe kelas satu seperti dalam 1ML, dan tradeoff yang diperlukan dalam rekursi modul (yaitu pencampuran ) di antara mereka.

@keean menulis:

Solusi untuk polimorfisme runtime adalah membuat paket kelas satu sehingga instance tanda tangan paket dapat diteruskan sebagai argumen fungsi, sayangnya ini memerlukan tipe dependen (lihat pekerjaan yang dilakukan pada Tipe Objek Dependen untuk Scala untuk membersihkan kekacauan yang mereka buat tipe-sistem aslinya).

Apakah yang Anda maksud: tipe dependen (EDIT: Saya kira sekarang yang dia maksud adalah pengetikan "tidak bergantung pada nilai", yaitu " fungsi yang tipe hasilnya bergantung pada argumen [runtime?] [tipe]") Tentu saja tidak tergantung pada nilai misalnya int data, seperti di Idris. Saya pikir Anda mengacu pada pengetikan yang bergantung (yaitu pelacakan) jenis nilai yang mewakili instance modul yang dipakai di hierarki panggilan sehingga fungsi polimorfik seperti itu dapat dimonomorfisasi pada waktu kompilasi? Apakah polimorfisme runtime masuk karena tipe monomorfis seperti itu menjadi tipe eksistensial yang terikat untuk tipe dinamis? Modul F-ing menunjukkan bahwa tipe "tergantung" tidak mutlak diperlukan untuk memodelkan modul ML di sistem _F . Sudahkah saya menyederhanakan jika saya menganggap @rossberg memformulasi ulang model pengetikan untuk menghapus semua persyaratan monomorfisasi?

Masalah dengan pendekatan paket generatif adalah bahwa ia menciptakan banyak boilerplate [...]
Kelas tipe menghindari boilerplate ini dengan memilih kelas tipe secara implisit berdasarkan tipe yang digunakan dalam fungsi saja.

Bukankah ada juga boilerplate dengan fungsi ML aplikatif? Tidak ada penyatuan kelas tipe dan fungsi (modul) ML yang diketahui yang mempertahankan singkatnya tanpa memperkenalkan batasan yang diperlukan untuk mencegah (cf juga ) anti-modularitas yang melekat pada kriteria keunikan global dari instance implementasi kelas tipe.

Kelas tipe hanya dapat mengimplementasikan setiap tipe dalam satu cara dan sebaliknya memerlukan newtype wrapper boilerplate untuk mengatasi batasan. Berikut adalah contoh lain dari berbagai cara untuk mengimplementasikan suatu algoritme. Afaics, @keean mengatasi batasan ini dalam contoh pengurutan kelas tipenya dengan mengganti pilihan implisit dengan Relation yang dipilih secara eksplisit menggunakan tipe pembungkus data untuk memberi nama hubungan yang berbeda secara umum pada tipe nilai, tetapi saya ragu apakah taktik tersebut umum untuk semua varian modularitas. Namun solusi yang lebih umum (yang dapat membantu dalam memperbaiki masalah modularitas keunikan global yang mungkin dikombinasikan dengan pembatasan anak yatim sebagai peningkatan pada versi yang diusulkan untuk resolusi anak yatim dengan menggunakan non-default untuk implementasi yang dapat menjadi yatim piatu) mungkin memiliki parameter tipe tambahan secara implisit pada semua kelas tipe interface , yang ketika tidak ditentukan default ke pencocokan implisit normal, tetapi ketika ditentukan (atau ketika tidak ditentukan tidak cocok dengan ² lainnya) kemudian memilih implementasi yang memiliki nilai yang sama dalam daftar nilai kustom yang dipisahkan koma (jadi ini lebih umum, pencocokan modular daripada menamai instance implement tertentu). Daftar yang dipisahkan koma adalah agar implementasi dapat dibedakan dalam lebih dari satu derajat kebebasan, seperti jika memiliki dua spesialisasi ortogonal. Khusus non-default yang diinginkan dapat ditentukan baik di deklarasi fungsi atau situs panggilan. Di situs panggilan, misalnya f<non-default>(…) .

Jadi mengapa kita membutuhkan modul parametris jika kita memiliki kelas tipe? Afaics hanya untuk (← tautan penting untuk diklik) substitusi karena menggunakan kembali kelas tipe untuk tujuan itu tidak cocok dengan itu misalnya kami ingin modul paket dapat menjangkau banyak file dan kami ingin dapat secara implisit membuka konten modul ke dalam ruang lingkup tanpa boilerplate tambahan . Jadi mungkin maju dengan parameter paket _sintaksis-only_ substitusi-saja (bukan kelas satu) adalah langkah pertama yang masuk akal yang dapat mengatasi generikitas tingkat modul sambil tetap terbuka untuk kompatibilitas dengan dan fungsionalitas yang tidak tumpang tindih jika menambahkan kelas tipe nanti untuk tingkat fungsi kedermawanan. makro ini misalnya diketik atau hanya substitusi sintaksis (alias "praprosesor"). Jika diketik, maka modul menduplikasi fungsionalitas kelas tipe, yang tidak diinginkan baik dari sudut pandang meminimalkan paradigma/konsep yang tumpang tindih dari PL dan kasus sudut potensial karena interaksi tumpang tindih (seperti ketika mencoba menawarkan fungsi dan kelas tipe ML ). Modul yang diketik lebih modular karena modifikasi pada implementasi yang dienkapsulasi di dalam modul yang tidak mengubah tanda tangan yang diekspor tidak dapat menyebabkan konsumen modul menjadi tidak kompatibel (selain masalah anti-modularitas yang disebutkan di atas dari contoh implementasi tumpang tindih kelas tipe). Saya tertarik untuk membaca pemikiran @keean tentang ini.

[…] dengan pengecualian untuk rekursi polimorfik dan tipe eksistensial (yang pada dasarnya adalah varian yang tidak dapat Anda singkirkan, Anda hanya dapat menggunakan antarmuka yang dikonfirmasi oleh varian).

Untuk membantu pembaca lainnya. Dengan "rekursi polimorfik", saya pikir mengacu pada tipe berperingkat lebih tinggi, misalnya panggilan balik parametris yang disetel saat runtime di mana kompiler tidak dapat memonomorfisasi tubuh fungsi panggilan balik karena tidak diketahui pada waktu kompilasi. Tipe eksistensial seperti yang saya sebutkan sebelumnya setara dengan objek sifat Rust, yang merupakan salah satu cara untuk mencapai wadah heterogen dengan pengikatan nanti dalam Masalah Ekspresi daripada class mensubklasifikasikan warisan virtual, tetapi tidak terbuka untuk ekstensi dalam Ekspresi Masalah sebagai penyatuan dengan struktur data yang tidak dapat diubah atau penyalinan ³ yang memiliki biaya kinerja O(log n) .

¹ _{Yang tidak memerlukan HKT dalam contoh di atas, karena SET tidak memerlukan elem type adalah parameter type dari tipe generik set , yaitu bukan set<elem> .}

² _{Namun jika terdapat lebih dari satu implementasi non-default dan tidak ada implementasi default, maka pemilihannya akan menjadi ambigu sehingga kompilator harus menghasilkan kesalahan.}

³ _{Catatan bermutasi dengan struktur data yang tidak dapat diubah tidak perlu menyalin seluruh struktur data, jika struktur data cukup pintar untuk mengisolasi riwayat seperti daftar tertaut tunggal.}

Menerapkan func pick(a CollectionOfT, count uint) []T akan menjadi contoh aplikasi obat generik yang baik (dari https://github.com/golang/go/issues/23717):

// pick returns a slice (len = n) of pseudorandomly chosen elements 
// in unspecified order from c which is an array, slice, or map.
for i, e := range pick(c, n) {

Pendekatan{} antarmuka di sini rumit.

Saya telah berkomentar beberapa kali tentang masalah ini bahwa salah satu masalah utama dengan pendekatan template C++ adalah ketergantungannya pada resolusi yang berlebihan sebagai mekanisme untuk metaprogramming waktu kompilasi.

Tampaknya Herb Sutter telah sampai pada kesimpulan yang sama: sekarang ada proposal menarik untuk pemrograman waktu kompilasi di C++ .

Ini memiliki beberapa elemen yang sama dengan paket Go reflect dan proposal saya sebelumnya untuk fungsi waktu kompilasi di Go .

Hai.
Saya telah menulis proposal untuk obat generik dengan batasan untuk Go. Anda bisa membacanya di sini . Mungkin dapat ditambahkan sebagai dokumen 15292. Ini sebagian besar tentang kendala dan dibaca sebagai amandemen Parameter Tipe Taylor di Go .
Ini dimaksudkan sebagai contoh cara yang bisa diterapkan (saya percaya) untuk melakukan obat generik 'ketik aman' di Go, - semoga dapat menambahkan sesuatu ke diskusi ini.
Harap dicatat, bahwa sementara saya telah membaca (sebagian besar) utas yang sangat panjang ini, saya belum mengikuti semua tautan di dalamnya, jadi orang lain mungkin telah membuat saran serupa. Jika itu masalahnya, saya minta maaf.

br. Kr.

Sintaks pelepasan sepeda:

constraint[T] Array {
    :[#]T
}

bisa jadi

type [T] Array constraint {
    _ [...]T
}

yang lebih mirip Go to me. :-)

Beberapa elemen di sini.

Satu hal adalah mengganti : dengan _ dan mengganti # dengan ... .
Saya kira Anda bisa melakukannya jika itu lebih disukai.

Hal lain adalah mengganti constraint[T] Array dengan type[T] Array constraint .
Itu sepertinya menunjukkan bahwa kendala adalah tipe, yang menurut saya tidak benar. Secara formal, kendala adalah _predikat_ pada himpunan semua jenis, yaitu. pemetaan dari set tipe ke set { true , false }.
Atau jika Anda mau, Anda dapat menganggap batasan hanya sebagai _a set of_ tipe.
Ini bukan tipe _a_.

br. Kr.

Mengapa constraint itu tidak menjadi interface saja?

type [T io.Writer] List struct { 
    element T; 
    next *List[T];
}

Antarmuka akan sedikit lebih berguna sebagai kendala dengan proposal berikut: #23796 yang pada gilirannya juga akan memberikan beberapa manfaat untuk proposal itu sendiri.

Juga, jika proposal untuk jenis jumlah diterima dalam beberapa bentuk (#19412), maka itu harus digunakan untuk membatasi jenisnya.

Meskipun saya percaya kata kunci kendala, beberapa sesuatu seperti itu harus ditambahkan, agar tidak mengulangi kendala besar dan mencegah kesalahan karena linglung.

Akhirnya, untuk bagian bikeshedding, saya pikir batasan harus dicantumkan di akhir definisi, untuk menghindari kepadatan yang berlebihan (sepertinya karat memiliki ide bagus di sini):

// similar to the map[T]... syntax
// also no constraint
type List[T] struct {
    element T
    next *List[T]
}

// with constraint
type List[T] struct {
    element T
    next *List[T]
} where T is io.Writer | encoding.BinaryMarshaler

type BigConstraint constraint {
     io.Writer
     SomeFunc() int
     AnotherFunc()
     AField int64
     StringField string
}


// with predefined constraint
type List[T, U] struct {
    element T
    val U
    next *List[T, U]
} where T is BigConstraint | encoding.BinaryMarshaler,
    U is io.Reader

@urandom : Saya pikir ini adalah satu keuntungan besar untuk memiliki antarmuka yang diimplementasikan secara implisit alih-alih secara eksplisit. @surlykke proposal dalam komentar ini saya pikir jauh lebih dekat dengan sintaks Go lainnya dalam semangat.

@surlykke Saya minta maaf jika proposal memiliki jawaban untuk semua ini.

Penggunaan generik adalah untuk memungkinkan fungsi gaya bawaan. Bagaimana Anda menerapkan len tingkat aplikasi dengan ini? Tata letak memori berbeda untuk setiap input yang diizinkan, jadi bagaimana ini lebih baik daripada antarmuka?

"Pilihan" yang dijelaskan sebelumnya memiliki masalah serupa di mana pengindeksan ke dalam peta vs pengindeksan ke dalam irisan berbeda. Dalam kasus peta jika ada konversi untuk mengiris terlebih dahulu maka kode pengambilan yang sama dapat digunakan, tetapi bagaimana ini dilakukan?

Koleksi adalah kegunaan lain:

// An unordered collection of comparable items.
type [T Comparable] Set []T

func (a Set) Diff(from Set) Set {
    // the implementation is the same as one with
    //     type Comparable interface { Equal(Comparable) bool }
    //     type Set []Comparable
}

// compile error
d := Set[int]{1, 2}.Diff(Set[string]{“abc”, “def”})

// Go 1, easier to read but runtime error
d := Set{1, 2}.Diff(Set{“abc”, “def”})

Untuk kasus tipe koleksi, saya tidak yakin ini adalah kemenangan besar atas obat generik Go 1 karena ada pengorbanan keterbacaan.

Saya setuju bahwa parameter tipe harus memiliki beberapa bentuk batasan. Jika tidak, kami akan mengulangi kesalahan template C++. Pertanyaannya adalah, seberapa ekspresifkah batasan-batasan itu?

Di satu sisi, kita hanya bisa menggunakan antarmuka. Tetapi seperti yang Anda tunjukkan, banyak pola yang berguna tidak dapat ditangkap dengan cara itu.

Lalu ada ide Anda, dan ide serupa, yang mencoba mengukir serangkaian batasan yang berguna dan menyediakan sintaks baru untuk mengekspresikannya. Selain masalah menambahkan lebih banyak sintaks, tidak jelas di mana harus berhenti. Seperti yang Anda tunjukkan, proposal Anda menangkap banyak pola, tetapi tidak semuanya.

Di ekstrem lainnya adalah ide yang saya usulkan dalam dokumen ini . Ia menggunakan kode Go itu sendiri sebagai bahasa kendala. Anda dapat menangkap hampir semua kendala dengan cara itu, dan tidak memerlukan sintaks baru.

@jba
Ini sedikit bertele-tele. Mungkin jika Go memiliki sintaks lambda, itu akan sedikit lebih enak. Di sisi lain, tampaknya masalah terbesar yang coba dipecahkannya adalah memeriksa apakah suatu tipe mendukung semacam operator. Mungkin akan lebih mudah jika Go memiliki antarmuka yang telah ditentukan sebelumnya untuk berbagai operator:

func equal[T](x, y T) bool
    where T is runtime.Equitable {
    return x == y
}

func copyable[T](x, y []T) int {
    return copy(x, y)
}

atau sesuatu di sepanjang garis ini.

Jika masalahnya adalah dengan memperluas builtin, maka mungkin masalahnya terletak pada cara bahasa membuat tipe adaptor. Misalnya, bukankah kembung terkait dengan sort.Interface adalah alasan utama di balik https://github.com/golang/go/issues/16721 dan sort.Slice?
Melihat https://github.com/golang/go/issues/21670#issuecomment -325739411 , gagasan @Sajmani untuk memiliki literal antarmuka mungkin merupakan bahan yang diperlukan untuk parameter tipe agar mudah bekerja dengan bawaan.
Perhatikan definisi Iterator berikut ini:

type [T] Iterator interface {
    Next() (elem T, done bool)
}

Jika print adalah fungsi yang hanya mengulangi daftar dan mencetak isinya, maka contoh berikut menggunakan literal antarmuka untuk membangun antarmuka yang memuaskan untuk print .

func SliceIterator(slice []T) Iterator {
    i := 0
    return Iterator{
        Next: func() (elem int, done bool) {
            v := slice[i]
            if i+1 == len(slice) {
                return v, true
            }
            i++
            return v, false
        },
    }
}

func main() {
    arr := []int{1,2,3,4,5}
    // SliceIterator works for an arbitrary slice
    print(SliceIterator(arr))
}

Seseorang sudah dapat melakukan ini jika mereka secara global mendeklarasikan tipe yang satu-satunya tanggung jawab adalah untuk memenuhi antarmuka. Namun, konversi dari fungsi ke metode ini membuat antarmuka (dan karenanya "kendala") lebih mudah dipenuhi. Kami tidak mencemari deklarasi tingkat atas dengan adaptor sederhana (seperti "widgetsByName" dalam penyortiran).
Tipe yang ditentukan pengguna jelas juga dapat memanfaatkan fitur ini, seperti yang terlihat pada contoh LinkedList ini:

type ListNode struct {
    v string
    next *ListNode
}
func (l *ListNode) Iterator() Iterator {
    ptr := l
    return Iterator{
        Next: func() (elem int, done bool) {
            v := ptr.v
            if ptr.next == nil {
                return v, true
            }
            ptr = ptr.next
            return v, false
        },
    }
}

@geovanisouza92 : Batasan seperti yang saya jelaskan lebih ekspresif daripada antarmuka (bidang, operator). Saya memang secara singkat mempertimbangkan untuk memperluas antarmuka alih-alih memperkenalkan batasan, tetapi saya pikir itu akan menjadi perubahan yang terlalu mengganggu pada elemen Go yang ada.

@ pciet Saya tidak yakin apa yang Anda maksud dengan 'tingkat aplikasi'. Go memiliki fungsi len bawaan yang dapat diterapkan ke array, penunjuk ke array, irisan, string, dan saluran, jadi, dalam proposal saya, jika parameter tipe dibatasi untuk memiliki salah satu dari ini sebagai tipe dasarnya , len dapat diterapkan padanya.

@pciet Tentang contoh Anda dengan batasan/antarmuka Comparable . Perhatikan bahwa jika Anda mendefinisikan (varian antarmuka):

type Comparable interface { Equal(Comparable) bool }
type Set []Comparable

Kemudian Anda dapat memasukkan apa pun yang mengimplementasikan Comparable ke dalam Set . Bandingkan dengan:

constraint [T] Comparable { Equal(t T) bool }
type [T Comparable[T]] Set []T
...
type FooSet Set[Foo] // Where Foo satisfies constraint Comparable

di mana Anda hanya dapat memasukkan nilai tipe Foo ke dalam FooSet . Itu adalah keamanan tipe yang lebih kuat.

@urandom Sekali lagi, saya bukan penggemar:

type MyConstraint constraint {....}

karena saya tidak percaya kendala adalah tipe. Juga, saya pasti tidak akan mengizinkan:

var myVar MyConstraint

yang tidak masuk akal bagi saya. Indikasi lain bahwa kendala bukanlah tipe.

@urandom Di bikeshedding: Saya percaya Kendala harus dideklarasikan tepat di sebelah parameter tipe. Pertimbangkan fungsi biasa, yang didefinisikan seperti ini:

func MyFunc(i) {
     if (i>0) fmt.Println("It's positive")
} with i being an integer

Anda tidak dapat membaca ini dari kiri ke kanan. Sebagai gantinya, Anda terlebih dahulu membaca func MyFunc(i) untuk menentukan bahwa itu adalah definisi fungsi. Kemudian Anda harus melompat ke akhir untuk mencari tahu apa itu i , dan kemudian kembali ke badan fungsi. Tidak ideal, IMO. Dan saya tidak melihat bagaimana definisi umum harus berbeda.
Tapi jelas, diskusi ini ortogonal dengan diskusi tentang apakah Go harus memiliki kendala atau generik.

@surlykke
Saya baik-baik saja dengan itu bukan tipe. Yang paling penting adalah mereka memiliki nama sehingga mereka dapat disebut dengan beberapa jenis.

Untuk fungsi, jika kita mengikuti sintaks karat, itu akan menjadi:

func MyFunc[I](i I) int64
     where I is being an integer {
   return 42
}

Jadi itu tidak akan menyembunyikan hal-hal seperti nama fungsi atau parameternya, dan Anda tidak perlu pergi ke akhir badan fungsi untuk melihat batasan apa pada tipe generiknya.

@surlykke untuk anak cucu, dapatkah Anda menemukan di mana proposal Anda dapat ditambahkan ke:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Ini adalah tempat yang bagus untuk "mengkompilasi" semua proposal.

Pertanyaan lain yang saya ajukan kepada Anda semua adalah bagaimana seseorang akan menangani spesialisasi berbagai instantiasi dari tipe generik. Dalam proposal tipe-params , cara melakukannya adalah dengan menghasilkan fungsi templat yang sama untuk setiap tipe yang dipakai, mengganti parameter tipe dengan nama tipe. Untuk memiliki fungsionalitas terpisah untuk tipe yang berbeda, lakukan sakelar tipe pada parameter tipe.

Apakah aman untuk mengasumsikan bahwa ketika kompiler melihat sakelar tipe pada parameter tipe, itu diizinkan untuk menghasilkan implementasi terpisah untuk setiap pernyataan? Atau apakah itu terlalu melibatkan pengoptimalan, karena parameter tipe bersarang dalam struct yang ditegaskan dapat membuat aspek parametrik pada pembuatan kode?

Dalam proposal fungsi waktu kompilasi , karena kita tahu bahwa deklarasi ini dihasilkan pada waktu kompilasi, sakelar tipe tidak menimbulkan biaya runtime.

Skenario praktis: Jika kita mempertimbangkan kasus paket math/bits , melakukan penegasan tipe untuk memanggil OnesCount untuk setiap uintXX akan mengalahkan tujuan memiliki perpustakaan manipulasi bit yang efisien. Namun, jika tipe-pernyataan diubah menjadi berikut:

func OnesCount(x T) int {
    switch x.(type) {
    case uint:
        // separate uint functionality...
    case uint8:
        // separate uint8 functionality...
    case uint16:
        // separate uint16 functionality...
    case uint32:
        // separate uint32 functionality...
    case uint64:
        // separate uint64 functionality...
    }
}

Panggilan untuk

var x uint8 = 255
bits.OnesCount(x)

kemudian akan memanggil fungsi yang dihasilkan berikut (nama tidak penting di sini):

func $OnesCount_uint8(x uint8) {
    // separate uint8 functionality...
}

@jba Itu proposal yang menarik, tetapi bagi saya itu sebagian besar menyoroti fakta bahwa definisi fungsi parametrik itu sendiri biasanya cukup untuk mendefinisikan batasannya.

Jika Anda akan menggunakan "operator yang digunakan dalam suatu fungsi" sebagai batasan, lalu keuntungan apa yang Anda dapatkan untuk menulis fungsi kedua yang berisi subset dari operator yang digunakan di fungsi pertama?

@bcmils Salah satunya adalah spesifikasi dan yang lainnya adalah implementasinya. Ini adalah keuntungan yang sama dengan pengetikan statis: Anda dapat menangkap kesalahan lebih awal.

Jika implementasinya adalah spesifikasi, la C++ template, maka setiap perubahan pada implementasi berpotensi merusak tanggungan. Itu mungkin tidak ditemukan sampai lama kemudian, ketika tanggungan dikompilasi ulang, dan penemu tidak memiliki konteks untuk memahami pesan kesalahan. Dengan spesifikasi dalam paket yang sama, Anda dapat mendeteksi kerusakan secara lokal.

@mandolyte Saya tidak yakin di mana harus menambahkannya - mungkin paragraf di bawah 'Pendekatan generik' bernama 'Generik dengan kendala'?
Dokumen tersebut tampaknya tidak memuat banyak tentang batasan jenis parameter, jadi jika Anda menambahkan paragraf di mana proposal saya akan disebutkan, maka pendekatan lain untuk batasan dapat dicantumkan di sana juga.

@surlykke pendekatan umum pada dokumen adalah membuat perubahan apa yang terasa benar dan saya akan mencoba menerima, menggabungkan, dan mengaturnya dengan sisa dokumen. Saya menambahkan bagian di sini . Jangan ragu untuk menambahkan hal-hal yang saya lewatkan.

@egonelbre Itu sangat bagus. Terima kasih!

@jba
Saya suka proposal Anda, tapi saya pikir itu terlalu berat untuk golang. Itu mengingatkan saya banyak template di c++. Masalah utama yang saya pikir adalah Anda dapat menulis kode yang sangat kompleks dengannya.
Untuk memutuskan apakah dua instance antarmuka generik tumpang tindih karena kumpulan tipe yang dibatasi tumpang tindih akan menjadi tugas yang sulit yang menyebabkan waktu kompilasi lebih lambat. Hal yang sama untuk pembuatan kode.

Saya pikir batasan yang diusulkan lebih ringan untuk digunakan. Dari apa yang saya dengar adalah bahwa kendala alias kelas tipe dapat diimplementasikan secara ortogonal ke sistem tipe suatu bahasa.

Saya harus sangat setuju bahwa kita tidak boleh menggunakan batasan implisit dari tubuh fungsi. Mereka secara luas dianggap sebagai salah satu kesalahan paling signifikan dari template C++:

• Kendala tidak mudah terlihat. Sementara godoc secara teoritis dapat menghitung semua kendala ke dalam dokumentasi, mereka tidak terlihat dalam kode sumber kecuali secara implisit.
• Karena itu, ada kemungkinan untuk secara tidak sengaja menyertakan batasan tambahan yang hanya terlihat saat Anda mencoba menggunakan fungsi dengan cara yang tidak diharapkan. Dengan mensyaratkan spesifikasi eksplisit dari kendala, programmer harus tahu persis kendala apa yang mereka perkenalkan.
• Itu membuat keputusan tentang jenis kendala apa yang diizinkan jauh lebih ad-hoc. Misalnya, apakah saya diizinkan untuk mendefinisikan fungsi berikut? Apa kendala sebenarnya pada T, U, dan V di sini? Jika kami mengharuskan programmer untuk secara eksplisit menentukan batasan, maka kami konservatif dalam jenis batasan yang kami izinkan (membiarkan kami memperluasnya secara perlahan dan sengaja). Jika kita mencoba untuk tetap konservatif, bagaimana kita memberikan pesan kesalahan untuk fungsi seperti ini? "Kesalahan: tidak dapat menetapkan uv() ke T karena memberlakukan batasan ilegal"?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

• Memanggil fungsi generik dalam fungsi generik lainnya memperburuk situasi di atas, karena Anda sekarang perlu melihat semua batasan yang dipanggil untuk memahami batasan fungsi yang Anda tulis atau baca.
• Debugging bisa sangat sulit, karena pesan kesalahan harus tidak memberikan informasi yang cukup untuk menemukan sumber kendala, atau harus membocorkan detail internal fungsi. Misalnya, jika F memiliki beberapa persyaratan pada tipe T , dan penulis F mencoba mencari tahu dari mana persyaratan itu berasal, mereka ingin kompilernya beri tahu mereka dengan tepat pernyataan mana yang menimbulkan kendala (terutama jika itu berasal dari panggilan umum). Tetapi pengguna F tidak menginginkan informasi itu dan, memang, jika disertakan dalam pesan kesalahan, maka kami membocorkan detail implementasi F dalam pesan kesalahan dari penggunanya, yang adalah pengalaman pengguna yang mengerikan.

@alercah

Misalnya, apakah saya diizinkan untuk mendefinisikan fungsi berikut?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

Tidak. u.v(V) adalah kesalahan sintaks karena V adalah tipe, dan variabel t tidak digunakan.

Namun, Anda dapat mendefinisikan fungsi ini, yang mungkin merupakan fungsi yang Anda inginkan:

func[T, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

Apa kendala sebenarnya pada T, U, dan V di sini?

• Jenis V tidak dibatasi.
• Jenis U harus memiliki metode v yang menerima parameter tunggal atau varargs dari beberapa jenis yang dapat ditetapkan dari V , karena u.v dipanggil dengan satu argumen dari jenis V .
  
  
  
  • U.v bisa menjadi bidang tipe fungsi, tetapi bisa dibilang itu harus menyiratkan metode; lihat #23796.
  
  
• Jenis yang dikembalikan oleh U.v harus numerik, karena konstanta 1 ditambahkan ke dalamnya.
• Tipe kembalian U.v harus dapat ditetapkan ke T , karena u.v(…) + 1 ditetapkan ke variabel tipe T .
• Jenis T harus numerik, karena jenis kembalian U.v adalah numerik dan dapat ditetapkan ke T .

(Selain: Anda dapat berargumen bahwa U dan V harus memiliki batasan "dapat disalin" karena argumen dari tipe tersebut dilewatkan oleh nilai, tetapi sistem tipe non-generik yang ada tidak menegakkan kendala itu juga. Itu masalah untuk proposal terpisah.)

Jika kami mengharuskan programmer untuk secara eksplisit menentukan batasan, maka kami konservatif dalam jenis batasan yang kami izinkan (membiarkan kami memperluasnya secara perlahan dan sengaja).

Ya, itu benar: tetapi menghilangkan kendala akan menjadi cacat serius apakah kendala itu tersirat atau tidak. IMO, peran kendala yang lebih penting adalah menyelesaikan ambiguitas. Misalnya, dalam batasan di atas, kompiler harus siap untuk membuat instance u.v sebagai metode argumen tunggal atau variadik.

Ambiguitas yang paling menarik terjadi untuk literal, di mana kita perlu membedakan antara tipe struct dan tipe komposit:

func[T] Foo() (t T) {
    x := 42;
    t = T{x: "some string"}  // Is x an index, or a field name?
    _ = x
}

Jika kita mencoba untuk tetap konservatif, bagaimana kita memberikan pesan kesalahan untuk fungsi seperti ini? "Kesalahan: tidak dapat menetapkan uv() ke T karena memberlakukan batasan ilegal"?

Saya tidak yakin apa yang Anda tanyakan, karena saya tidak melihat kendala yang saling bertentangan untuk contoh ini. Apa yang Anda maksud dengan "pembatasan ilegal"?

Debugging bisa sangat sulit, karena pesan kesalahan harus tidak memberikan informasi yang cukup untuk menemukan sumber kendala, atau harus membocorkan detail internal fungsi.

Tidak setiap batasan yang relevan dapat diekspresikan oleh sistem tipe (lihat juga https://github.com/golang/go/issues/22876#issuecomment-347035323). Beberapa kendala diberlakukan oleh kepanikan run-time; beberapa ditegakkan oleh detektor balapan; kendala paling berbahaya hanya didokumentasikan dan tidak terdeteksi sama sekali.

Semua "kebocoran detail internal" itu sampai taraf tertentu. (Lihat juga https://xkcd.com/1172/.)

Misalnya, jika […] penulis F mencoba mencari tahu dari mana persyaratan itu berasal, mereka ingin kompiler memperingatkan mereka tentang pernyataan mana yang menimbulkan kendala (terutama jika itu berasal dari panggilan umum). Tetapi pengguna F tidak menginginkan informasi itu[.]

Mungkin? Begitulah cara penulis API menggunakan anotasi tipe dalam bahasa yang disimpulkan dengan tipe seperti Haskell dan ML, tetapi juga mengarah ke lubang kelinci tipe parametrik (“tingkat tinggi”) secara umum.

Misalnya, Anda memiliki fungsi ini:

func [F, Arg, Result] InvokeAsync(f F, x Arg) (<-chan Result) {
    c := make(chan result, 1)
    go func() { c <- f(x) }()
    return c
}

Bagaimana Anda mengekspresikan batasan eksplisit pada tipe Arg ? Mereka bergantung pada instantiasi spesifik F . Ketergantungan semacam itu tampaknya hilang dari banyak proposal kendala baru-baru ini.

Tidak. uv(V) adalah kesalahan sintaks karena V adalah tipe, dan variabel t tidak digunakan.

Namun, Anda dapat mendefinisikan fungsi ini, yang mungkin merupakan fungsi yang Anda inginkan:

Ya, itu tujuannya, saya minta maaf.

Jenis T harus numerik, karena jenis kembalian U.v adalah numerik dan dapat ditetapkan ke T .

Haruskah kita benar-benar menganggap ini sebagai kendala? Ini dapat dikurangkan dari batasan lain, tetapi apakah lebih atau kurang berguna untuk menyebut ini sebagai batasan yang berbeda? Kendala implisit mengajukan pertanyaan ini dengan cara yang tidak dilakukan oleh kendala eksplisit.

Ya, itu benar: tetapi menghilangkan kendala akan menjadi cacat serius apakah kendala itu tersirat atau tidak. IMO, peran kendala yang lebih penting adalah menyelesaikan ambiguitas. Misalnya, dalam batasan di atas, kompiler harus siap untuk membuat instance uv baik sebagai argumen tunggal atau metode variadik.

Maksud saya "batasan yang kami izinkan" seperti dalam bahasa. Dengan batasan eksplisit, jauh lebih mudah bagi kita untuk memutuskan batasan seperti apa yang ingin kita izinkan pengguna untuk menulis, daripada hanya mengatakan batasannya adalah "apa pun yang membuat sesuatu dikompilasi". Misalnya, contoh saya Foo di atas sebenarnya melibatkan tipe tambahan implisit yang terpisah dari T , U , atau V , karena kita harus mempertimbangkan tipe kembalian dari u.v . Jenis ini tidak secara eksplisit dirujuk dengan cara apa pun dalam deklarasi f ; properti yang harus dimiliki sepenuhnya implisit. Demikian juga, apakah kami bersedia mengizinkan jenis dengan peringkat lebih tinggi ( forall )? Saya tidak dapat memberikan contoh dari atas kepala saya, tetapi saya juga tidak dapat meyakinkan diri sendiri bahwa Anda tidak dapat secara implisit menulis tipe terikat dengan peringkat lebih tinggi.

Contoh lain adalah apakah kita harus mengizinkan suatu fungsi untuk memanfaatkan sintaks yang kelebihan beban. Jika fungsi yang dibatasi secara implisit melakukan for i := range t untuk beberapa t dari tipe generik T , sintaksnya berfungsi jika T adalah array, irisan, saluran, atau peta. Tetapi semantiknya sangat berbeda, terutama jika T adalah jenis saluran. Misalnya, jika t == nil (yang dapat terjadi selama T adalah array), maka iterasi tidak menghasilkan apa-apa, karena tidak ada elemen dalam irisan atau peta nihil, atau blok selamanya karena itulah yang diterima di saluran nil . Ini adalah senjata besar yang menunggu untuk terjadi. Demikian pula yang dilakukan m[i] = ... ; jika saya bermaksud m menjadi peta, saya harus menjaganya agar tidak benar-benar menjadi irisan karena kode bisa panik pada tugas di luar jangkauan jika tidak.

Faktanya, saya pikir ini cocok untuk argumen lain melawan batasan implisit: penulis API mungkin menulis pernyataan buatan hanya untuk menambahkan batasan. Misalnya for _, _ := range t { break } mencegah saluran sambil tetap mengizinkan peta, irisan, dan larik; x = append(x) memaksa x untuk memiliki tipe irisan. var _ = make(T, 0) memungkinkan irisan, peta, dan saluran tetapi tidak array. Akan ada buku resep tentang cara menambahkan batasan secara implisit sehingga seseorang tidak dapat memanggil fungsi Anda dengan tipe yang kodenya tidak Anda tulis dengan benar. Saya bahkan tidak bisa memikirkan cara untuk menulis kode yang hanya dikompilasi untuk tipe peta kecuali saya tahu tipe kuncinya juga. Dan saya tidak berpikir ini hipotetis sama sekali; peta dan irisan berperilaku sangat berbeda untuk sebagian besar aplikasi

Saya tidak yakin apa yang Anda tanyakan, karena saya tidak melihat kendala yang saling bertentangan untuk contoh ini. Apa yang Anda maksud dengan "pembatasan ilegal"?

Maksud saya batasan yang tidak diizinkan oleh bahasa, seperti jika bahasa memutuskan untuk melarang batasan peringkat yang lebih tinggi.

Tidak setiap batasan yang relevan dapat diekspresikan oleh sistem tipe (lihat juga #22876 (komentar)). Beberapa kendala diberlakukan oleh kepanikan run-time; beberapa ditegakkan oleh detektor balapan; kendala paling berbahaya hanya didokumentasikan dan tidak terdeteksi sama sekali.

Semua "kebocoran detail internal" itu sampai taraf tertentu. (Lihat juga https://xkcd.com/1172/.)

Saya tidak benar-benar melihat bagaimana #22876 masuk ke dalam ini; yang mencoba menggunakan sistem tipe untuk mengekspresikan jenis batasan yang berbeda. Akan selalu benar bahwa kita tidak dapat mengungkapkan beberapa batasan pada nilai, atau pada program, bahkan dengan sistem tipe dengan kompleksitas arbitrer. Tapi kita hanya berbicara tentang batasan pada tipe di sini. Kompiler harus dapat menjawab pertanyaan "Dapatkah saya membuat instance generik ini dengan tipe T ?" yang berarti bahwa ia harus memahami batasan, apakah itu implisit atau eksplisit. (Perhatikan bahwa beberapa bahasa, seperti C++ dan Rust, tidak dapat memutuskan pertanyaan ini secara umum karena dapat bergantung pada komputasi arbitrer dan dengan demikian beralih ke Masalah Penghentian, tetapi mereka masih mengungkapkan batasan yang perlu dipenuhi.)

Maksud saya lebih seperti "pesan kesalahan apa yang harus diberikan oleh contoh berikut?"

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

Kita dapat mengatakan Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Pesan kesalahan ini berguna bagi pengguna IndirectlyConstrained , karena dengan jelas menetapkan batasan yang tidak ada. Tetapi itu tidak memberikan informasi kepada seseorang yang mencoba men-debug mengapa IndirectlyConstrained memiliki batasan itu, yang merupakan masalah kegunaan besar jika itu adalah fungsi yang besar. Kami dapat menambahkan Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , tetapi sekarang kami membocorkan detail implementasi IndirectlyConstrained . Selanjutnya, kami belum menjelaskan mengapa IndirectlyConstrained memiliki batasan, jadi apakah kami menambahkan Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M lain? Bagaimana jika batasan implisit berasal dari beberapa callee empat tingkat di bawah tumpukan panggilan?

Selanjutnya, bagaimana kita memformat pesan kesalahan ini untuk jenis yang tidak secara eksplisit terdaftar sebagai parameter? Misalnya jika dalam contoh di atas, IndirectlyConstrained memanggil DirectlyConstrained(t.U()) . Bagaimana kita merujuk ke jenisnya? Dalam hal ini kita dapat mengatakan the type of t.U() , tetapi nilainya tidak selalu merupakan hasil dari satu ekspresi; itu bisa dibangun di atas beberapa pernyataan. Kemudian kita perlu menyintesis ekspresi dengan tipe yang benar untuk dimasukkan ke dalam pesan kesalahan, yang tidak pernah muncul dalam kode, atau kita perlu menemukan cara lain untuk merujuknya yang akan kurang jelas bagi penelepon miskin yang melanggar batasan.

Bagaimana Anda mengekspresikan batasan eksplisit pada tipe Arg? Mereka bergantung pada instantiasi spesifik F. Ketergantungan semacam itu tampaknya hilang dari banyak proposal batasan baru-baru ini.

Jatuhkan F dan miliki tipe f menjadi func (Arg) Result . Ya, itu mengabaikan fungsi variadik, tetapi Go lainnya juga melakukannya. Proposal untuk membuat varargs funcs dapat dialihkan ke tanda tangan yang kompatibel dapat dilakukan secara terpisah.

Untuk kasus di mana kami benar-benar memerlukan batas jenis orde tinggi, mungkin masuk akal atau tidak untuk memasukkannya ke dalam generik v1. Kendala eksplisit memang memaksa kita untuk memutuskan secara eksplisit apakah kita ingin mendukung tipe tingkat tinggi, dan bagaimana caranya. Kurangnya pertimbangan sejauh ini adalah gejala, menurut saya, dari fakta bahwa Go saat ini tidak memiliki cara untuk merujuk ke properti tipe bawaan. Ini adalah pertanyaan umum yang terbuka tentang bagaimana sistem generik mana pun akan mengizinkan fungsi generik di semua tipe numerik, atau semua tipe integer, dan sebagian besar proposal belum terlalu fokus pada hal ini.

Silakan evaluasi implementasi obat generik saya di proyek Anda berikutnya
http://go-li.github.io/

Kita dapat mengatakan Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Pesan kesalahan ini […] tidak memberikan informasi kepada seseorang yang mencoba men-debug mengapa IndirectlyConstrained memiliki batasan itu, yang merupakan masalah kegunaan besar jika itu adalah fungsi yang besar.

Saya ingin menunjukkan asumsi besar yang Anda buat di sini: bahwa pesan kesalahan dari go build adalah alat _only_ yang tersedia bagi pemrogram untuk mendiagnosis masalah.

Untuk menggunakan analogi: jika Anda menemukan error saat run-time, Anda memiliki beberapa opsi untuk debugging. Kesalahan itu sendiri hanya berisi pesan sederhana, yang mungkin atau mungkin tidak cukup untuk menggambarkan kesalahan. Tapi itu bukan satu-satunya informasi yang Anda miliki: misalnya, Anda juga memiliki pernyataan log apa pun yang dikeluarkan program, dan jika itu adalah bug yang sangat buruk, Anda dapat memuatnya ke dalam debugger interaktif.

Artinya, run-time debugging adalah proses interaktif. Jadi mengapa kita harus mengasumsikan debugging non-interaktif untuk kesalahan waktu kompilasi? Sebagai salah satu alternatif, kita dapat mengajarkan alat guru tentang batasan tipe. Kemudian, output dari kompiler akan menjadi seperti:

somefile.go:123: Argument `4` to DirectlyConstrained has type `int`,
    but DirectlyConstrained requires a type `T` with method `DoSomething()`.
    (For more detail, run `guru contraints path/to/somefile.go:#1033`.)

Itu memberi pengguna paket generik informasi yang mereka butuhkan untuk men-debug situs panggilan langsung, tetapi _also_ memberikan remah roti untuk pengelola paket (dan, yang penting, lingkungan pengeditan mereka!) untuk menyelidiki lebih lanjut.

Kami dapat menambahkan Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , tetapi sekarang kami membocorkan detail implementasi IndirectlyConstrained .

Ya, itulah yang saya maksud tentang bocornya informasi. Anda sudah dapat menggunakan guru describe untuk mengintip ke dalam implementasi. Anda dapat mengintip ke dalam program yang sedang berjalan menggunakan debugger, dan tidak hanya mencari tumpukan tetapi juga turun ke fungsi tingkat rendah yang sewenang-wenang.

Saya sangat setuju bahwa kita harus menyembunyikan informasi yang mungkin tidak relevan _secara default_, tetapi itu tidak berarti bahwa kita harus menyembunyikannya secara mutlak.

Jika fungsi yang dibatasi secara implisit berfungsi untuk i := range t untuk beberapa t dari tipe generik T , sintaksnya berfungsi jika T adalah array, irisan, saluran apa pun , atau peta. Tetapi semantiknya sangat berbeda, terutama jika T adalah jenis saluran.

Saya pikir itu argumen yang lebih menarik untuk batasan tipe, tetapi itu tidak memerlukan batasan eksplisit untuk mendekati verbose seperti yang diusulkan beberapa orang. Untuk membedakan situs panggilan, tampaknya cukup untuk membatasi parameter tipe dengan sesuatu yang lebih dekat ke reflect.Kind . Kita tidak perlu menjelaskan operasi yang sudah jelas dari kode; sebagai gantinya, kita hanya perlu mengatakan hal-hal seperti " T is a slice type". Itu mengarah ke serangkaian batasan yang lebih sederhana:

• jenis yang tunduk pada operasi indeks perlu diberi label sebagai linier atau asosiatif,
• jenis yang tunduk pada range operasi perlu diberi label sebagai nil-kosong atau nil-blocking,
• tipe dengan literal perlu diberi label memiliki bidang atau indeks, dan
• (mungkin) tipe dengan operasi numerik perlu diberi label sebagai titik tetap atau mengambang.

Itu mengarah ke bahasa batasan yang jauh lebih sempit, mungkin seperti:

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

dengan contoh seperti:

func[T:integer, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

func [S:sliceable, T] append(s S, x ...T) S {
    dst := s
    if cap(s) - len(s) < len(x) {
        dst = make(S, len(s), nextSizeClass(cap(s)))
        copy(dst, s)
    }
    copy(dst[len(s):cap(s)], x)
    return dst[:len(s)+len(x)]
}

Saya merasa kami telah mengambil langkah besar menuju generik khusus dengan memperkenalkan alias tipe.
Tipe alias memungkinkan tipe super (tipe tipe).
Kita dapat memperlakukan tipe seperti nilai dalam menggunakan.

Untuk mempermudah penjelasan, kita dapat menambahkan elemen kode baru, genre .
Hubungan antara genre dan tipe seperti hubungan antara tipe dan nilai.
Dengan kata lain, genre berarti jenis jenis.

Setiap jenis tipe, kecuali tipe struct dan antarmuka dan fungsi, sesuai dengan genre yang telah dideklarasikan sebelumnya.

• Bool
• Rangkaian
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• Float32, Float64
• Kompleks64, Kompleks128
• Array, Iris, Peta, Saluran, Pointer, UnsafePointer

Ada beberapa genre yang telah dideklarasikan sebelumnya, seperti Comaprable, Numeric, Interger, Float, Complex, Container, dll. Kita dapat menggunakan Type atau * untuk menunjukkan semua jenis genre.

Nama semua genre bawaan semuanya dimulai dengan huruf besar.

Setiap struct dan antarmuka dan tipe fungsi sesuai dengan genre.

Kami juga dapat mendeklarasikan genre khusus:

genre Addable = Numeric | String
genre Orderable = Interger | Float | String
genre Validator = func(int) bool // each parameter and result type must be a specified type.
genre HaveFieldsAndMethods = {
    width  int // we must use a specific type to define the fields.
    height int // we can't use a genre to define the fields.
    Load(v []byte) error // each parameter and result type must be a specified type.
    DoSomthing()
}
genre GenreFromStruct = aStructType // declare a genre from a struct type
genre GenreFromInterface = anInterfaceType // declare a genre from an interface type
genre GenreFromStructInterface = aStructType + anInterfaceType
genre ComparableStruct = HaveFieldsAndMethods & Comprable
genre UncomparableStruct = HaveFieldsAndMethods &^ Comprable

Untuk membuat penjelasan berikut konsisten, pengubah genre diperlukan.
Pengubah genre dilambangkan dengan Const . Sebagai contoh:

• Const Integer adalah genre (berbeda dari Integer ) dan turunannya harus berupa nilai konstan yang tipenya harus bilangan bulat. Namun, nilai konstan dapat dilihat sebagai tipe khusus.
• Const func(int) bool adalah genre (berbeda dari func(int) bool ) dan turunannya harus berupa nilai fungsi yang dihapus. Namun, deklarasi fungsi dapat dilihat sebagai tipe khusus.

(Solusi pengubah agak rumit, mungkin ada solusi desain lain yang lebih baik.)

Oke, mari kita lanjutkan.
Kami membutuhkan konsep lain. Menemukan nama yang baik untuk itu tidaklah mudah,
Sebut saja crate .
Secara umum, hubungan antara peti dan genre seperti hubungan antara fungsi dan jenis.
Peti dapat mengambil tipe sebagai parameter dan tipe pengembalian.

Deklarasi peti (anggap kode berikut dideklarasikan dalam paket lib ):

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

Menggunakan peti di atas.

import "lib"

// We can use AddFunc as a normal delcared function.
// Its genre is "Const func (a, b T) T"
type Rect, AddFunc, Array = lib.Example[float32, struct{x, y float32}, 100]

func demo() {
    var r Rect
    a, p = r.Area(), r.Perimeter()
    _ = AddFunc(a, p)
}

Ide-ide saya menyerap banyak ide-ide orang lain yang ditunjukkan di atas.
Mereka sangat tidak dewasa sekarang.
Saya mempostingnya di sini hanya karena saya merasa itu menarik,
dan saya tidak ingin memperbaikinya lagi.
Begitu banyak sel otak yang terbunuh dengan memperbaiki lubang-lubang ide.
Saya berharap ide-ide ini dapat membawa beberapa inspirasi untuk menghubungkan lainnya.

Apa yang Anda sebut "genre" sebenarnya disebut "jenis", dan terkenal di
komunitas pemrograman fungsional. Apa yang Anda sebut peti adalah terlarang
jenis fungsi ML.

Pada Rabu, 4 April 2018, 12:41, dotaheor [email protected] menulis:

Saya merasa kami telah mengambil langkah besar menuju generik khusus dengan memperkenalkan
ketik alias.
Tipe alias memungkinkan tipe super (tipe tipe).
Kita dapat memperlakukan tipe seperti nilai dalam menggunakan.

Untuk mempermudah penjelasan, kita dapat menambahkan elemen kode baru, genre.
Hubungan antara genre dan tipe seperti hubungan antar tipe
dan nilai-nilai.
Dengan kata lain, genre berarti jenis jenis.

Setiap jenis jenis, kecuali jenis struct dan antarmuka dan fungsi,
sesuai dengan genre yang telah dideklarasikan.

• Bool
• Rangkaian
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  & Float32, Float64
• Kompleks64, Kompleks128
• Array, Iris, Peta, Saluran, Pointer, UnsafePointer

Ada beberapa genre yang telah dideklarasikan sebelumnya, seperti Comaprable, Numeric,
Interger, Float, Complex, Container, dll. Kita bisa menggunakan Type atau * menunjukkan
genre semua jenis.

Nama semua genre bawaan semuanya dimulai dengan huruf besar.

Setiap struct dan antarmuka dan tipe fungsi sesuai dengan genre.

Kami juga dapat mendeklarasikan genre khusus:

genre Dapat ditambahkan = Numerik | Rangkaian
genre Dapat Diurutkan = Interger | mengambang | Rangkaian
genre Validator = func(int) bool // setiap parameter dan tipe hasil harus tipe yang ditentukan.
genre HaveFieldsAndMethods = {
width int // kita harus menggunakan tipe tertentu untuk mendefinisikan field.
height int // kita tidak bisa menggunakan genre untuk mendefinisikan field.
Load(v []byte) error // setiap parameter dan tipe hasil harus tipe yang ditentukan.
melakukan sesuatu()
}
genre GenreFromStruct = aStructType // mendeklarasikan genre dari tipe struct
genre GenreFromInterface = anInterfaceType // mendeklarasikan genre dari tipe antarmuka
genre GenreFromStructInterface = aStructType | sebuahInterfaceType

Untuk membuat penjelasan berikut konsisten, pengubah genre diperlukan.
Pengubah genre dilambangkan dengan Const. Sebagai contoh:

• Const Integer adalah genre dan instance-nya harus berupa nilai konstan
  tipe mana yang harus berupa bilangan bulat.
  Namun, nilai konstan dapat dilihat sebagai tipe khusus.
• Const func(int) bool adalah genre dan instance-nya harus delcared
  nilai fungsi.
  Namun, deklarasi fungsi dapat dilihat sebagai tipe khusus.

(Solusi pengubah agak rumit, mungkin ada desain lain yang lebih baik
solusi.)

Oke, mari kita lanjutkan.
Kami membutuhkan konsep lain. Menemukan nama yang baik untuk itu tidaklah mudah,
Sebut saja peti.
Secara umum, hubungan antara peti dan genre seperti hubungan
antara fungsi dan jenis.
Peti dapat mengambil tipe sebagai parameter dan tipe pengembalian.

Deklarasi peti (anggap kode berikut dideklarasikan di lib
kemasan):

peti Contoh [T Float, S {lebar, tinggi T}, N Const Integer] [*, *, *] {
ketik MyArray [N]T

func Tambah(a, b T) T {
kembali a+b
}

// Genre lingkup peti. Hanya bisa digunakan di peti.

// M adalah jenis genre G
tipe M struktur {
x T
y S
}

func (m *M) Luas() T {
m.Melakukan Sesuatu()
kembalikan lebarku * tinggiku
}

func (m *M) Keliling() T {
kembali 2 * Tambahkan (lebarku, tinggiku)
}

ekspor M, Tambah, MyArray
}

Menggunakan peti di atas.

impor "lib"

// Kita bisa menggunakan AddFunc sebagai fungsi delcared normal.
ketik Rect, AddFunc, Array = lib.Contoh(float32, struct{x, y float32})

fungsi demo() {
var r Rect
a, p = r.Area(), r.Perimeter()
_ = AddFunc(a, p)
}

Ide-ide saya menyerap banyak ide-ide orang lain yang ditunjukkan di atas.
Mereka sangat tidak dewasa sekarang.
Saya mempostingnya di sini hanya karena saya merasa itu menarik,
dan saya tidak ingin memperbaikinya lagi.
Begitu banyak sel otak yang terbunuh dengan memperbaiki lubang-lubang ide.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-378665695 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
.

Saya merasa ada beberapa perbedaan antara Jenis dan Genre.

Omong-omong, jika peti hanya mengembalikan satu jenis, kita dapat menggunakan panggilannya sebagai jenis secara langsung.

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

Gunakan:

import "lib"

var l lib.List[int]

Akan ada beberapa aturan "pengurangan genre", seperti "pengurangan jenis" dalam sistem saat ini.

@dotaheor , @DemiMarie benar. Konsep "genre" Anda terdengar persis seperti "jenis" dari teori tipe. (Proposal Anda kebetulan memerlukan aturan subkinding, tapi itu tidak biasa.)

Kata kunci genre dalam proposal Anda mendefinisikan jenis baru sebagai jenis super dari jenis yang sudah ada. Kata kunci crate mendefinisikan objek dengan "tanda tangan peti", yang merupakan jenis yang bukan subjenis Type .

Sebagai sistem formal, proposal Anda tampaknya seperti:

Peti ::= χ | ⋯.
Ketik ::= τ | χ | int | bool | | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

CrateSig ::= [κ₁, …] ⇒ [κₙ, …]
Baik ::= κ | exactly τ | kindOf κ | Map | Chan | | Const κ | Type | PetiSig

Untuk menyalahgunakan beberapa notasi teori tipe:

• Baca "⊢" sebagai "membutuhkan".
• Baca “ k1 k2 ” sebagai “ k1 adalah subjenis dari k2 ”.
• Baca ":" sebagai "baik hati".

Kemudian aturannya terlihat seperti:

τ : exactly τ
exactly τ kindOf exactly τ
kindOf exactly τ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ τ : κ₂

τ₁ : Type τ₂ : Type kindOf exactly map[τ₁]τ₂ Map
Map Type

κ₁ κ₂ Const κ₁ Const κ₂

[…]
(Dan seterusnya, untuk semua jenis bawaan)

Definisi jenis memberikan jenis, dan jenis yang mendasari runtuh ke jenis jenis bawaan:

type τ₁ τ₂ τ₂ : κ ⊢ τ₁ : kindOf κ

kindOf kindOf κ kindOf κ
kindOf Map Map
[…]

genre mendefinisikan hubungan subtipe baru:
genre κ = κ₁ | κ₂ κ₁ κ
genre κ = κ₁ | κ₂ κ₂ κ

(Anda dapat mendefinisikan Numeric dan sejenisnya dalam bentuk | .)

genre κ = κ₁ & κ₂ ( κ₃ ⊑ κ₁ ) ( κ₃ ⊑ κ₂ ) κ₃ κ

Aturan ekspansi peti serupa:
type τₙ, … = χ[τ₁, …] ( χ : [κ₁, …] ⇒ [κₙ, …] ) ( τ₁ : κ₁ ) τₙ : κₙ

Ini semua hanya berbicara tentang jenis, tentu saja. Jika Anda ingin mengubahnya menjadi sistem tipe, Anda juga memerlukan aturan tipe. 🙂.

Jadi apa yang Anda gambarkan adalah bentuk parametrik yang cukup dipahami. Itu bagus, karena dipahami dengan baik, tetapi mengecewakan karena tidak membantu menyelesaikan masalah unik yang diperkenalkan Go.

Masalah yang benar-benar menarik dan degil yang diperkenalkan Go terutama seputar pemeriksaan tipe dinamis. Bagaimana seharusnya parameter tipe berinteraksi dengan pernyataan dan refleksi tipe?

(Misalnya, apakah mungkin untuk mendefinisikan antarmuka dengan metode tipe parametrik? Jika demikian, apa yang terjadi jika Anda mengetik-menegaskan nilai antarmuka itu dengan parameter baru saat run-time?)

Pada catatan terkait, apakah ada diskusi tentang cara membuat kode generik di atas tipe bawaan dan tipe yang ditentukan pengguna? Seperti membuat kode yang dapat menangani bigint dan bilangan bulat primitif?

Pada catatan terkait, apakah ada diskusi tentang cara membuat kode generik di atas tipe bawaan dan tipe yang ditentukan pengguna? Seperti membuat kode yang dapat menangani bigint dan bilangan bulat primitif?

Mekanisme berbasis kelas tipe, seperti di Genus dan Familia, dapat melakukan ini secara efisien. Lihat makalah PLDI 2015 kami untuk detailnya.

@DemiMarie
Saya pikir "genre" == "set sifat".

[sunting]
Mungkin traits adalah keywrod yang lebih baik.
Kita dapat melihat setiap jenis juga merupakan kumpulan sifat.

Sebagian besar sifat didefinisikan hanya untuk satu jenis.
Tetapi sifat yang lebih kompleks dapat menentukan hubungan antara dua jenis.

[sunting 2]
asumsikan ada dua himpunan sifat A dan B, kita dapat melakukan operasi berikut:

A + B: union set
A - B: difference set
A & B: intersection set

Kumpulan sifat dari tipe argumen harus berupa kumpulan super dari genre parameter yang sesuai (kumpulan sifat).
Kumpulan sifat dari tipe hasil harus merupakan subkumpulan dari genre hasil yang sesuai (kumpulan sifat).

(MENURUT OPINI SAYA)

Masih saya pikir rebinding Alias ​​​​Tipe adalah cara yang harus dilakukan, untuk menambahkan obat generik ke Go. Itu tidak membutuhkan perubahan besar dalam bahasa. Paket yang digeneralisasi seperti ini, masih bisa digunakan di Go 1.x. Dan tidak perlu menambahkan batasan karena dimungkinkan untuk melakukannya dengan mengatur tipe default untuk tipe alias, ke sesuatu yang sudah memenuhi batasan tersebut. Dan aspek terpenting dari alias tipe rebinding adalah, tipe komposit bawaan (irisan, peta, dan saluran) tidak perlu diubah dan digeneralisasi.

@dc0d

Bagaimana seharusnya mengetik alias menggantikan obat generik?

@sighoya Rebinding Type Alias ​​​​dapat menggantikan obat generik (bukan hanya mengetik alias). Mari kita asumsikan sebuah paket memperkenalkan beberapa alias tipe level paket seperti:

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

Jika Type Alias ​​Rebinding (dan fasilitas kompiler) disediakan maka dimungkinkan untuk menggunakan paket ini, untuk membuat daftar tertaut untuk tipe beton yang berbeda, alih-alih antarmuka kosong:

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

Jika kita menggunakan alias seperti itu, cara berikut lebih bersih.

// pkg.go
package pkg

type ListNode struct {
    prev, next *ListNode
    element    ?Element
}

func Add(x, y ?T) ?T {
    return x+y
}



// main.go
package main

import "pkg"

type intList = pkg.ListNode[Element=int]
func stringAdd = pkg.Add[T=string]

func main() {
}

@dc0d dan bagaimana tepatnya itu akan diterapkan? Kodenya bagus tetapi tidak memberi tahu apa pun tentang cara kerjanya di dalam. Dan, melihat sejarah proposal obat generik, untuk Go itu sangat penting, bukan hanya tampilan dan rasanya.

@dotaheor Itu tidak kompatibel dengan Go 1.x.

@creker Saya telah menerapkan alat (bernama goreuse ) yang menggunakan teknik ini untuk menghasilkan kode dan lahir sebagai konsep untuk Type Alias ​​Rebinding.

Ini dapat ditemukan di sini . Ada video berdurasi 15 menit yang menjelaskan alat tersebut.

@dc0d sehingga berfungsi seperti template C++ yang menghasilkan implementasi khusus. Saya tidak berpikir itu akan diterima sebagai tim Go (dan, sejujurnya, saya dan banyak orang lain di sini) tampaknya menentang apa pun yang mirip dengan templat C++. Ini meningkatkan binari, memperlambat kompilasi, mungkin tidak akan dapat menghasilkan kesalahan yang berarti. Dan, selain itu, tidak kompatibel dengan paket biner saja yang didukung oleh Go. Itulah sebabnya C++ memilih untuk menulis template dalam file header.

@creker

jadi ini berfungsi seperti template C++ yang menghasilkan implementasi khusus untuk setiap jenis yang digunakan.

Saya tidak tahu (Sudah sekitar 16 tahun sejak saya menulis C++). Tapi dari penjelasan Anda sepertinya memang begitu. Namun saya tidak yakin apakah atau bagaimana mereka sama.

Saya tidak berpikir itu akan diterima sebagai tim Go (dan, sejujurnya, saya dan banyak orang lain di sini) tampaknya menentang apa pun yang mirip dengan templat C++.

Tentu semua orang di sini memiliki alasan bagus untuk preferensi mereka berdasarkan prioritas mereka. Pertama dalam daftar saya adalah kompatibilitas dengan Go 1.x.

Ini meningkatkan binari,

Itu mungkin.

memperlambat kompilasi,

Saya sangat meragukan itu (karena dapat dialami dengan goreuse ).

Dan, selain itu, tidak kompatibel dengan paket biner saja yang didukung oleh Go.

Saya tidak yakin. Apakah cara lain untuk mengimplementasikan obat generik mendukung ini?

mungkin tidak akan mampu menghasilkan kesalahan yang berarti.

Ini bisa sedikit merepotkan. Tetap saja itu terjadi pada waktu kompilasi dan dapat dikompensasi, menggunakan beberapa alat, untuk sebagian besar. Selain itu jika alias tipe yang bertindak sebagai parameter tipe untuk paket, adalah sebuah antarmuka, maka dapat dengan mudah diperiksa apakah dapat dialihkan dari tipe yang disediakan beton. Meskipun masalah untuk tipe primitif seperti int dan string dan struct tetap ada.

@dc0d

Saya memikirkannya sedikit.
Selain itu dibuat secara internal pada antarmuka, 'T' dalam contoh Anda

type T=interface{}

diperlakukan sebagai variabel tipe yang dapat diubah, tetapi harus berupa alias untuk tipe tertentu, yaitu referensi const ke suatu tipe.
Yang Anda inginkan adalah Tipe T, tetapi ini menyiratkan pengenalan obat generik.

@sighoya Saya tidak yakin apakah saya mengerti apa yang Anda katakan.

Ini dibuat secara internal pada antarmuka

Tidak benar. Seperti yang dijelaskan dalam komentar asli saya, dimungkinkan untuk menggunakan tipe tertentu yang memenuhi batasan. Misalnya tipe parameter tipe alias dapat dideklarasikan sebagai:

type T = int

Dan hanya tipe yang memiliki + operator (atau - atau * ; tergantung apakah operator tersebut digunakan di badan paket) yang dapat digunakan sebagai nilai tipe yang duduk di parameter tipe itu.

Jadi bukan hanya interface saja yang bisa digunakan sebagai parameter tipe place-holder.

tapi ini akan menyiratkan pengenalan obat generik.

Ini _adalah_ cara untuk memperkenalkan/mengimplementasikan obat generik dalam bahasa Go itu sendiri.

@dc0d

Untuk menyediakan polimorfisme, Anda akan menggunakan antarmuka{} karena ini memungkinkan untuk menyetel T ke tipe apa pun nanti.

Pengaturan 'type T=Int' tidak akan banyak berguna.

Jika Anda akan mengatakan bahwa 'tipe T' tidak dideklarasikan/tidak ditentukan terlebih dahulu yang dapat diatur nanti, maka Anda memiliki sesuatu seperti obat generik.

Masalahnya adalah 'T' menampung lebar modul/paket dan tidak lokal untuk fungsi atau struct apa pun (oke bagus, mungkin deklarasi tipe bersarang dalam struct yang dapat diakses dari luar).

Mengapa tidak menulis saja?:

fun<type T>(t T)

atau

fun[type T](t T)

Selanjutnya kita memerlukan beberapa mesin inferensi tipe untuk menyimpulkan tipe yang tepat saat memanggil fungsi generik atau struct tanpa spesialisasi parameter tipe pada awalnya.

@dc0d menulis

Dan hanya tipe yang memiliki + operator (atau - atau *; tergantung apakah operator tersebut digunakan di badan paket sama sekali) yang dapat digunakan sebagai nilai tipe yang berada di parameter tipe tersebut.

Bisakah Anda menguraikan lebih lanjut tentang ini?

@sighoya

Untuk menyediakan polimorfisme, Anda akan menggunakan antarmuka{} karena ini memungkinkan untuk menyetel T ke tipe apa pun nanti.

Polimorfisme tidak dicapai dengan memiliki tipe yang kompatibel, saat mengikat ulang alias tipe. Satu-satunya kendala sebenarnya adalah, isi paket generik. Mereka harus kompatibel secara mekanis.

Bisakah Anda menguraikan lebih lanjut tentang ini?

Misalnya jika alias tipe parameter tipe level paket didefinisikan seperti:

package genericadd

type T = int

func Add(a, b T) T { return a + b }

Kemudian hampir semua tipe numerik dapat ditetapkan ke T , seperti:

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

Namun saya tidak yakin apakah atau bagaimana mereka sama.

Mereka sama dalam arti bahwa mereka bekerja hampir identik dari apa yang saya lihat. Untuk setiap kompilator instantiasi templat kelas akan menghasilkan implementasi unik jika ini adalah pertama kalinya ia melihat penggunaan kombinasi tertentu dari templat kelas dan daftar parameternya. Itu meningkatkan ukuran biner karena Anda sekarang memiliki beberapa implementasi dari templat kelas yang sama. Memperlambat kompilasi karena kompiler sekarang perlu menghasilkan implementasi ini dan melakukan segala macam pemeriksaan. Dalam kasus C++, peningkatan waktu kompilasi bisa sangat besar. Contoh mainan Anda cepat tetapi begitu juga dengan C++.

Saya tidak yakin. Apakah cara lain untuk mengimplementasikan obat generik mendukung ini?

Bahasa lain tidak memiliki masalah dengan itu. Secara khusus, C# sebagai yang paling akrab bagi saya. Tapi itu menggunakan pembuatan kode runtime yang tim Go mengesampingkan sepenuhnya. Java juga berfungsi tetapi implementasinya bukan yang terbaik, untuk sedikitnya. Beberapa proposal ianlancetaylor hanya dapat menangani paket biner dari apa yang saya pahami.

Satu-satunya hal yang saya tidak mengerti adalah apakah paket biner saja harus didukung. Saya tidak melihat mereka disebutkan secara eksplisit dalam proposal. Saya tidak terlalu peduli dengan mereka tetapi tetap saja, ini adalah fitur bahasa.

Hanya untuk menguji pemahaman saya... pertimbangkan repo algoritme salin/tempel ini [ di sini ]. Kecuali jika Anda ingin menggunakan "int", kode tersebut tidak dapat digunakan secara langsung. Itu harus disalin dan ditempel dan dimodifikasi agar berfungsi. Dan dengan modifikasi, maksud saya setiap instance "int" harus diubah ke tipe apa pun yang Anda butuhkan.

Pendekatan tipe alias akan membuat modifikasi sekali, misalnya T, dan menyisipkan baris "tipe T int". Maka kompiler perlu mengikat ulang T ke sesuatu yang lain, katakanlah float64.

Karena itu:
a) Saya berpendapat bahwa tidak akan ada perlambatan kompiler kecuali Anda benar-benar menggunakan teknik ini. Jadi itu adalah pilihan Anda.
b) Mengingat hal-hal vgo baru, di mana beberapa versi dari kode yang sama dapat digunakan ... artinya harus ada beberapa metode untuk menyelipkan sumber yang digunakan agar tidak terlihat, maka pasti kompiler dapat melacak apakah dua penggunaan rebinding yang sama digunakan dan menghindari duplikasi. Jadi saya pikir kode mengasapi akan sama dengan teknik salin/tempel saat ini.

Tampaknya bagi saya bahwa antara alias tipe dan vgo yang akan datang, fondasi untuk pendekatan obat generik ini hampir selesai...

Ada beberapa "tidak diketahui" yang tercantum dalam proposal [ di sini ]. Jadi, alangkah baiknya jika dagingnya sedikit lebih banyak.

@mandolyte Anda dapat menambahkan tingkat tipuan lain dengan membungkus tipe khusus dalam beberapa wadah umum. Dengan begitu implementasi Anda bisa tetap sama. Kompiler kemudian akan melakukan semua keajaiban. Saya pikir proposal parameter tipe Ian berfungsi seperti itu.

Saya pikir pengguna membutuhkan pilihan antara penghapusan tipe dan monomorfisasi.
Yang terakhir adalah mengapa Rust menyediakan abstraksi tanpa biaya. Pergi juga harus.

Pada Senin, 9 April 2018, 8:32 Antonenko [email protected]
menulis:

@mandolyte https://github.com/mandolyte Anda dapat menambahkan level lain
tipuan dengan membungkus jenis khusus dalam beberapa wadah umum. Itu
cara implementasi Anda bisa tetap sama. Kompiler kemudian akan melakukan semua
sihir. Saya pikir proposal parameter tipe Ian berfungsi seperti itu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-379735199 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
.

Tampak bagi saya bahwa ada kebingungan yang dapat dimengerti dalam diskusi ini tentang tradeoff antara modularitas dan kinerja. Teknik C++ untuk memeriksa ulang dan membuat instance kode generik pada setiap jenis yang digunakannya buruk untuk modularitas, buruk untuk distribusi biner, dan karena kode mengasapi, buruk untuk kinerja. Bagian yang baik dari pendekatan itu adalah ia secara otomatis mengkhususkan kode yang dihasilkan ke tipe yang digunakan, yang sangat membantu ketika tipe yang digunakan adalah tipe primitif seperti int . Java menerjemahkan kode generik secara homogen, tetapi membayar harga dalam kinerjanya, terutama ketika kode tersebut menggunakan tipe T[] .

Untungnya, ada beberapa cara untuk mengatasi ini tanpa non-modularitas C++ dan tanpa pembuatan kode run-time penuh:

1. Hasilkan instantiasi khusus untuk tipe primitif. Ini dapat dilakukan baik secara otomatis atau dengan arahan programmer. Beberapa pengiriman diperlukan untuk mengakses instantiasi yang benar, tetapi dapat dilipat menjadi pengiriman yang sudah dibutuhkan oleh terjemahan yang homogen. Ini akan bekerja mirip dengan C#, tetapi tidak memerlukan pembuatan kode run-time penuh; sedikit dukungan ekstra mungkin diperlukan dalam waktu proses untuk menyiapkan tabel pengiriman saat kode dimuat.
2. Gunakan implementasi generik tunggal di mana array T sebenarnya direpresentasikan sebagai array tipe primitif ketika T dipakai sebagai tipe primitif. Pendekatan ini, yang kami gunakan di PolyJ, Genus, dan Familia, sangat meningkatkan kinerja dibandingkan dengan pendekatan Java, meskipun tidak secepat implementasi yang sepenuhnya terspesialisasi.

@dc0d

Polimorfisme tidak dicapai dengan memiliki tipe yang kompatibel, saat mengikat ulang alias tipe. Satu-satunya kendala sebenarnya adalah, isi paket generik. Mereka harus kompatibel secara mekanis.

Ketik alias adalah cara yang salah, karena harus menjadi referensi konstan.
Lebih baik untuk menulis 'T Type' secara langsung dan kemudian Anda melihat Anda memang menggunakan obat generik.

Mengapa Anda ingin menggunakan variabel tipe global 'T' untuk seluruh paket/modul, tipe lokal vars di <> atau [] lebih modular.

@creker

Secara khusus, C# sebagai yang paling akrab bagi saya. Tapi itu menggunakan pembuatan kode runtime yang tim Go mengesampingkan sepenuhnya.

Untuk tipe referensi, tetapi tidak untuk tipe nilai.

@DemiMarie

Saya pikir pengguna membutuhkan pilihan antara penghapusan tipe dan monomorfisasi.
Yang terakhir adalah mengapa Rust menyediakan abstraksi tanpa biaya. Pergi juga harus.

"Jenis Penghapusan" ambigu, saya akan menganggap maksud Anda Penghapusan Parameter Jenis, hal yang disediakan Java yang juga tidak sepenuhnya benar.
Java memiliki monomorfisasi, tetapi monomorfisasi (semi) terus-menerus ke batas atas dalam batasan generik yang sebagian besar adalah Object.
Untuk menyediakan metode dan bidang tipe lain, batas atas dicor secara internal ke tipe Anda yang sesuai yang cukup jelek.
Jika proyek Valhalla akan diterima, hal-hal akan berubah untuk tipe nilai tetapi sayangnya tidak untuk tipe referensi.

Pergi tidak harus melalui Jalan Jawa karena:

"Kompatibilitas biner untuk paket yang dikompilasi tidak dijamin di antara rilis"

sedangkan ini tidak mungkin di Jawa.

Tampak bagi saya bahwa ada kebingungan yang dapat dimengerti dalam diskusi ini tentang tradeoff antara modularitas dan kinerja. Teknik C++ untuk memeriksa ulang dan membuat instance kode generik pada setiap jenis yang digunakannya buruk untuk modularitas, buruk untuk distribusi biner, dan karena kode mengasapi, buruk untuk kinerja.

Jenis pertunjukan apa yang Anda bicarakan di sini?

Jika dengan "kode mengasapi" dan "kinerja" yang Anda maksud adalah "ukuran biner" dan "tekanan cache instruksi", maka masalahnya cukup mudah untuk diselesaikan: selama Anda tidak menyimpan informasi debug secara berlebihan untuk setiap spesialisasi, Anda dapat fungsi runtuh dengan tubuh yang sama ke dalam fungsi yang sama pada waktu link (yang disebut "model Borland" ). Itu secara sepele menangani spesialisasi untuk tipe dan tipe primitif tanpa panggilan ke metode non-sepele.

Jika dengan "kode mengasapi" dan "kinerja" yang Anda maksud adalah "ukuran input tautan" dan "waktu penautan", maka masalahnya juga cukup mudah, jika Anda dapat membuat asumsi tertentu (masuk akal) tentang sistem pembangunan Anda. Alih-alih memancarkan setiap spesialisasi di setiap unit kompilasi, Anda dapat menampilkan daftar spesialisasi yang diperlukan, dan meminta sistem build untuk membuat instance setiap spesialisasi unik tepat satu kali sebelum menautkan ("model Cfront"). IIRC, ini adalah salah satu masalah yang coba diatasi oleh modul C++ .

Jadi, kecuali Anda bermaksud jenis ketiga dari "kode mengasapi" dan "kinerja" yang saya lewatkan, sepertinya Anda sedang berbicara tentang masalah dengan implementasi, bukan spesifikasi: _as selama implementasi tidak terlalu mempertahankan debug informasi,_ masalah kinerja cukup mudah untuk diatasi.

Masalah yang lebih besar untuk Go adalah bahwa, jika kita tidak hati-hati, menjadi mungkin untuk menggunakan pernyataan tipe atau refleksi untuk menghasilkan contoh baru dari tipe parameter pada saat run-time, yang tidak ada jumlah kepintaran implementasi — kekurangan keseluruhan yang mahal -analisis program - dapat memperbaiki.

Itu memang kegagalan modularitas, tetapi ~ tidak ada hubungannya dengan kode mengasapi: sebaliknya, itu berasal dari fakta bahwa jenis fungsi (dan metode) Go tidak menangkap serangkaian kendala yang cukup lengkap pada argumen mereka.

@sighoya

Untuk tipe referensi, tetapi tidak untuk tipe nilai.

Dari apa yang saya baca, C# JIT melakukan spesialisasi saat runtime untuk setiap tipe nilai dan sekali untuk semua tipe referensi. Tidak ada spesialisasi waktu kompilasi (IL-time). Itulah sebabnya pendekatan C# benar-benar diabaikan - Tim Go tidak ingin bergantung pada pembuatan kode runtime karena membatasi platform yang dapat dijalankan Go. Secara khusus, di iOS Anda tidak diizinkan melakukan pembuatan kode saat runtime. Ini berfungsi dan saya benar-benar melakukan beberapa tetapi Apple tidak mengizinkannya di AppStore.

Bagaimana kamu melakukannya?

Pada Senin, 9 April 2018, 15:41 Antonenko [email protected]
menulis:

@sighoya https://github.com/sighoya

Untuk tipe referensi, tetapi tidak untuk tipe nilai.

Dari apa yang saya baca, C# JIT melakukan spesialisasi saat runtime untuk setiap nilai
ketik dan sekali untuk semua jenis referensi. Tidak ada waktu kompilasi
spesialisasi. Itulah sebabnya pendekatan C# benar-benar diabaikan - Go team
tidak ingin bergantung pada pembuatan kode runtime karena membatasi platform Go
dapat berjalan terus. Secara khusus, di iOS Anda tidak diizinkan melakukan pembuatan kode
saat berjalan. Ini berfungsi dan saya benar-benar melakukan beberapa tetapi Apple tidak mengizinkan
itu di AppStore.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-379870005 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
.

@DemiMarie meluncurkan kode penelitian lama saya hanya untuk memastikan (penelitian itu dibatalkan karena alasan lain). Sekali lagi, debugger menyesatkan saya. Saya mengalokasikan halaman, menulis beberapa instruksi untuk itu, mprotect dengan PROT_EXEC dan melompat ke sana. Di bawah debugger itu berfungsi. Tanpa aplikasi debugger SIGKILL dengan pesan CODESIGN di log kerusakan, seperti yang diharapkan. Jadi, itu tidak berfungsi bahkan tanpa AppStore. Argumen yang lebih kuat terhadap pembuatan kode runtime jika iOS penting untuk Go.

Pertama, akan sangat membantu untuk merenungkan 5 Aturan Pemrograman Rob Pike sekali lagi.

Kedua (IMHO):

Tentang kompilasi lambat dan ukuran biner, berapa banyak tipe generik yang digunakan dalam tipe umum aplikasi yang sedang dikembangkan menggunakan Go (_n biasanya kecil_ dari Aturan 3)? Kecuali jika masalahnya membutuhkan tingkat kardinalitas yang tinggi dalam konsep konkret (jumlah jenis yang tinggi) overhead dapat diabaikan. Bahkan kemudian saya akan berpendapat bahwa ada sesuatu yang salah dengan pendekatan itu. Saat menerapkan sistem e-niaga, tidak ada yang mendefinisikan jenis terpisah untuk setiap jenis produk dan variasinya serta kemungkinan penyesuaian.

Verbositas adalah bentuk kesederhanaan dan keakraban yang baik (misalnya dalam sintaksis) yang membuat segalanya lebih jelas dan bersih. Sementara saya ragu bahwa kode mengasapi akan lebih tinggi menggunakan Type Alias ​​Rebinding, saya suka sintaks Go-ish yang familiar dan verbositas yang jelas menyertainya. Salah satu tujuan Go adalah mudah dibaca (sementara saya pribadi merasa relatif mudah dan menyenangkan untuk menulis juga).

Saya tidak mengerti bagaimana hal itu dapat merusak kinerja karena pada saat runtime, hanya tipe terikat beton yang digunakan yang telah dihasilkan pada waktu kompilasi. Tidak ada overhead runtime.

Satu-satunya perhatian dengan Type Alias ​​Rebinding yang saya lihat, mungkin distribusi biner.

Kerusakan kinerja @dc0d biasanya berarti mengisi cache instruksi karena implementasi templat kelas yang berbeda. Bagaimana tepatnya kaitannya dengan kinerja nyata adalah pertanyaan terbuka, saya tidak tahu tolok ukur apa pun, tetapi secara teoritis itu adalah masalah.

Adapun ukuran biner. Ini adalah masalah teoretis lain yang biasanya diangkat orang (seperti yang saya lakukan sebelumnya) tetapi bagaimana kode sebenarnya akan menderita, sekali lagi, merupakan pertanyaan terbuka. Misalnya, spesialisasi untuk semua jenis pointer dan antarmuka mungkin sama, saya pikir. Tetapi spesialisasi untuk semua jenis nilai akan menjadi unik. Dan itu juga termasuk struct. Menggunakan wadah generik untuk menyimpannya adalah hal biasa dan akan menyebabkan kode yang membengkak karena implementasi wadah generik tidak kecil.

Satu-satunya perhatian dengan Type Alias ​​Rebinding yang saya lihat, mungkin distribusi biner.

Di sini saya masih tidak yakin. Apakah proposal generik harus mendukung paket biner saja atau kita bisa menyebutkan bahwa paket biner saja tidak mendukung generik. Itu akan jauh lebih mudah, itu pasti.

Seperti yang telah disebutkan sebelumnya, jika seseorang tidak perlu mendukung debugging, satu
dapat menggabungkan instantiasi template yang identik.

Pada Selasa, 10 Apr 2018, 5:46 Kaveh Shahbazian [email protected]
menulis:

Pertama, akan sangat membantu untuk merenungkan 5 Aturan Pemrograman Rob Pike
https://users.ece.utexas.edu/%7Eadnan/pike.html sekali lagi.

Kedua (IMHO):

Tentang kompilasi lambat dan ukuran biner, berapa banyak tipe generik yang digunakan dalam
jenis aplikasi umum yang sedang dikembangkan menggunakan Go ( n isbiasanya kecil dari Aturan 3)? Kecuali jika masalahnya membutuhkan tingkat yang tinggi
kardinalitas dalam konsep konkret (jumlah jenis tinggi) yang dapat di atas kepala
diabaikan. Bahkan kemudian saya akan berpendapat bahwa ada sesuatu yang salah dengan itu
mendekati. Saat menerapkan sistem e-niaga, tidak ada yang mendefinisikan secara terpisah
jenis untuk setiap jenis produk dan variasinya dan kemungkinannya
kustomisasi.

Verbositas adalah bentuk kesederhanaan dan keakraban yang baik (misalnya dalam
sintaks) yang membuat segalanya lebih jelas dan bersih. Sementara aku meragukan itu
kode mengasapi akan lebih tinggi menggunakan Type Alias ​​Rebinding, saya suka
sintaks Go-ish yang familier dan verbositas yang jelas menyertainya. Satu dari
tujuan Go adalah mudah dibaca (sementara saya pribadi menemukannya
relatif mudah dan menyenangkan untuk menulis juga).

Saya tidak mengerti bagaimana itu dapat merusak kinerja karena hanya saat runtime
jenis terikat beton sedang digunakan yang telah dihasilkan di
waktu kompilasi. Tidak ada overhead runtime.

Satu-satunya masalah dengan Type Alias ​​Rebinding yang saya lihat, mungkin biner
distribusi.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-380040032 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
.

Instansiasi bahkan tidak perlu "identik" dalam arti "menggunakan argumen yang sama", atau bahkan "menggunakan argumen dengan tipe dasar yang sama". Mereka hanya perlu cukup dekat untuk menghasilkan kode yang sama. (Untuk Go, itu juga menyiratkan "topeng penunjuk yang sama".)

@creker

Dari apa yang saya baca, C# JIT melakukan spesialisasi saat runtime untuk setiap tipe nilai dan sekali untuk semua tipe referensi. Tidak ada spesialisasi waktu kompilasi (IL-time).

Nah, ini terkadang sedikit rumit karena kode byte mereka ditafsirkan tepat pada waktunya sebelum kode dieksekusi, jadi pembuatan kode dilakukan sebelum menjalankan program tetapi setelah kompilasi, jadi Anda benar dalam arti vm yang sedang berjalan saat kode dihasilkan.

Saya pikir sistem generik c# akan baik-baik saja jika kita menghasilkan kode pada waktu kompilasi.
Pembuatan kode runtime dalam arti c# tidak dimungkinkan dengan go, karena go bukan vm.

@dc0d

Satu-satunya perhatian dengan Type Alias ​​Rebinding yang saya lihat, mungkin distribusi biner.

Bisakah Anda menguraikan sedikit.

@sighoya Kesalahan saya; Maksud saya bukan distribusi biner tetapi paket biner - yang secara pribadi saya tidak tahu betapa pentingnya itu.

@creker Kesimpulan yang bagus! (MO) Kecuali alasan kuat ditemukan, segala bentuk overloading konstruksi bahasa Go harus dihindari. Salah satu alasan untuk menggunakan Type Alias ​​Rebinding adalah untuk menghindari kelebihan beban tipe komposit bawaan seperti irisan atau peta.

Verbositas adalah bentuk kesederhanaan dan keakraban yang baik (misalnya dalam sintaksis) yang membuat segalanya lebih jelas dan bersih. Sementara saya ragu bahwa kode mengasapi akan lebih tinggi menggunakan Type Alias ​​Rebinding, saya suka sintaks Go-ish yang familiar dan verbositas yang jelas menyertainya. Salah satu tujuan Go adalah mudah dibaca (sementara saya pribadi merasa relatif mudah dan menyenangkan untuk menulis juga).

Saya tidak setuju dengan anggapan ini. Proposal Anda akan memaksa pengguna untuk melakukan hal tersulit yang diketahui oleh programmer mana pun - memberi nama. Jadi kita akan berakhir dengan kode yang penuh dengan notasi hungaria, yang tidak hanya terlihat buruk, tetapi juga bertele-tele dan menyebabkan gagap. Selain itu, proposal lain juga membawa sintaks go-ish, dan pada saat yang sama tidak memiliki masalah ini.

Ada tiga kategori nama yang harus kita pikirkan setiap hari:

• Untuk Entitas/Logika Domain
• Jenis Data/Logika Alur Kerja Program
• Layanan/Jenis Data/Logika Antarmuka

Berapa kali seorang programmer berhasil menghindari penamaan apa pun dalam kodenya?

Sulit atau tidak itu perlu dilakukan setiap hari. Dan sebagian besar rintangannya datang dari ketidakmampuan dalam menyusun basis kode - bukan kesulitan dari proses penamaan itu sendiri. Kutipan itu - setidaknya dalam bentuknya saat ini - telah merugikan dunia pemrograman sejauh ini. Ini hanya mencoba untuk menekankan pentingnya penamaan. Karena kita berkomunikasi melalui nama dalam kode kita.

Dan nama menjadi jauh lebih kuat ketika mereka menyertai praktik penataan kode; baik dalam hal tata letak kode (file, struktur direktori, paket/modul) dan praktik (pola desain, abstraksi layanan - seperti REST, manajemen sumber daya - pemrograman bersamaan, mengakses hard drive, throughput/latency).

Adapun sintaks dan verbositas, saya lebih menyukai verbositas daripada keringkasan yang cerdas (setidaknya dalam konteks Go) - sekali lagi, Go dimaksudkan agar mudah dibaca, belum tentu mudah untuk ditulis (yang anehnya menurut saya juga bagus dalam hal itu) .

@jba lihat https://github.com/golang/go/issues/8303 dan https://github.com/golang/go/issues/8082

Saya membaca banyak laporan pengalaman dan proposal tentang mengapa dan bagaimana menerapkan obat generik di Go.

Apakah Anda keberatan jika saya mencoba untuk benar-benar menerapkannya di gomacro juru bahasa Go saya?

Saya memiliki beberapa pengalaman tentang topik ini, setelah menambahkan obat generik ke dua bahasa di masa lalu

1. bahasa yang sekarang ditinggalkan yang saya buat kembali ketika saya masih naif :) Itu berubah menjadi kode sumber C
2. Common Lisp dengan perpustakaan saya cl-parametric-types - ini juga mendukung spesialisasi sebagian dan penuh dari tipe dan fungsi generik

@ cosmos72 itu akan membuat laporan pengalaman yang bagus untuk melihat prototipe teknik yang menjaga keamanan tipe.

Baru mulai mengerjakannya. Anda dapat mengikuti perkembangannya di https://github.com/cosmos72/gomacro/tree/generics-v1

Saat ini saya mulai dengan campuran (sedikit dimodifikasi) dari proposal Ian ketiga dan keempat yang tercantum di https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal

@cosmos72 Ada ringkasan proposal di tautan di bawah ini. Apakah paduan Anda salah satunya?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Saya telah membaca dokumen itu, itu merangkum banyak pendekatan berbeda untuk obat generik dengan berbagai bahasa pemrograman.

Saat ini saya akan menuju teknik "Spesialisasi tipe" yang digunakan oleh C++, Rust, dan lainnya, mungkin dengan sedikit "Cakupan templat berparameter" karena Go sintaks paling umum untuk tipe baru adalah type ( Foo ...; Bar ...) dan saya memperluas ke template[T1,T2...] type ( Foo ...; Bar ...) .
Juga, saya menjaga pintu tetap terbuka untuk "Spesialisasi terbatas".

Saya juga ingin mengimplementasikan "Spesialisasi fungsi polimorfik", yaitu untuk mengatur agar spesialisasi secara otomatis disimpulkan oleh bahasa di situs panggilan jika tidak ditentukan oleh programmer, tetapi saya kira itu mungkin agak rumit untuk diterapkan. Kita lihat.

Campuran yang saya maksud adalah antara https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md dan https://github.com/golang/proposal/blob/ master/design/15292/2013-12-type-params.md

Pembaruan: untuk menghindari spamming masalah Go resmi ini di luar pengumuman awal, mungkin lebih baik untuk melanjutkan diskusi khusus gomacro di gomacro edisi #24: tambahkan obat generik

Pembaruan 2: fungsi templat pertama berhasil dikompilasi dan dieksekusi. Lihat https://github.com/cosmos72/gomacro/tree/generics-v1

Sebagai catatan, dimungkinkan untuk mengulangi pendapat saya (tentang obat generik dan Type Alias ​​Rebinding):

Generik harus ditambahkan sebagai fitur kompiler (pembuatan kode, templat, dll), bukan fitur bahasa (campur tangan dengan sistem tipe Go di semua tingkatan).

@dc0d
Tetapi apakah templat C++ bukan fitur kompiler dan bahasa?

@sighoya Terakhir kali saya menulis C++ secara profesional adalah sekitar tahun 2001. Jadi saya mungkin salah. Tetapi dengan asumsi implikasi penamaan itu akurat - bagian "templat" - ya (atau lebih tepatnya tidak); itu mungkin fitur kompiler (dan bukan fitur bahasa), disertai dengan beberapa konstruksi bahasa, yang kemungkinan besar tidak membebani konstruksi bahasa apa pun yang terlibat dalam sistem tipe.

Saya mendukung @dc0d. Jika Anda mempertimbangkannya, fitur ini tidak lebih dari generator kode terintegrasi.

Ya: ukuran biner mungkin dan AKAN meningkat, tetapi saat ini kami menggunakan pembuat kode, yang hampir sama tetapi sebagai fitur eksternal. Jika saya harus membuat template saya sebagai:

type BinaryTreeOfStrings struct {
    left, right *BinaryTreeOfStrings;
    string content;
}

// Its methods here

type BinaryTreeOfBigInts struct {
    left, right *BinaryTreeOfBigInts;
    uint64 content;
}

// AGAIN the same methods but different type

... Saya sangat menyukai itu, daripada menyalin atau menggunakan alat eksternal, fitur ini menjadi bagian dari kompilator itu sendiri.

Tolong dicatat:

• Ya, kode akhir akan diduplikasi. Benar seperti kita menggunakan genset. Dan biner akan lebih besar.
• Ya, idenya tidak orisinal, tetapi dipinjam dari C++.
• Ya, fungsi MyTypetidak melibatkan apa pun dengan tipe T (langsung atau tidak langsung) juga akan diulang. Itu dapat dioptimalkan (mis. metode yang merujuk sesuatu dengan tipe T -selain penunjuk ke objek penerima pesan- akan dihasilkan untuk setiap T ; metode yang menyimpan pemanggilan ke metode yang akan dihasilkan untuk setiap T , juga akan dihasilkan untuk setiap T , secara rekursif - sementara metode di mana satu-satunya referensi mereka ke T adalah *T di penerima, dan metode lain yang hanya memanggil metode aman tersebut dan memenuhi kriteria yang sama, hanya dapat dibuat satu kali). Bagaimanapun, IMO poin ini besar dan kurang tepat: Saya akan cukup senang bahkan jika pengoptimalan ini tidak ada.
• Jenis argumen harus eksplisit menurut saya. Khususnya ketika suatu objek memenuhi antarmuka yang berpotensi tak terbatas. Sekali lagi: pembuat kode.

Sejauh ini dalam komentar saya, proposal saya adalah mengimplementasikannya apa adanya: sebagai pembuat kode yang didukung kompiler , alih-alih alat eksternal.

Akan sangat disayangkan jika Go mengikuti rute C++. Banyak orang melihat pendekatan C++ sebagai kekacauan yang telah membuat programmer menentang seluruh ide generik: kesulitan debugging, kurangnya modularitas, kode mengasapi. Semua solusi "pembuat kode" sebenarnya hanyalah substitusi makro — jika itu cara Anda ingin menulis kode, mengapa kami bahkan memerlukan dukungan kompiler?

@andrewcmyers Saya punya proposal ini Ketik Alias ​​​​Rebinding di mana kami hanya menulis paket normal dan alih-alih menggunakan interface{} secara eksplisit, kami hanya menggunakannya sebagai type T = interface{} sebagai parameter generik tingkat paket. Dan itu saja.

• Kami men-debugnya seperti paket normal - ini adalah kode aktual, bukan makhluk paruh waktu perantara.
• Tidak perlu campur tangan dengan sistem tipe Go di semua tingkatan - pikirkan tentang penugasan saja.
• Hal ini eksplisit. Tidak ada mojo tersembunyi. Tentu saja orang mungkin merasa tidak dapat menyambungkan panggilan umum dengan mulus, sebuah kelemahan. Saya melihatnya sebagai draw-forward! Mengubah jenis dalam dua panggilan berturut-turut, dalam satu pernyataan tidak Goish (IMO).
• Dan yang terbaik dari semuanya adalah kompatibel dengan seri Go 1.x (x >= 8).

Meskipun idenya bukanlah hal baru, cara yang memungkinkan Go untuk mengimplementasikannya adalah pragmatis dan jelas.

Bonus lebih lanjut: tidak ada operator yang kelebihan beban di Go. Tetapi dengan mendefinisikan nilai default dari alias tipe sebagai (misalnya) type T = int , bukan satu-satunya tipe valid yang dapat digunakan untuk menyesuaikan paket generik ini, adalah tipe numerik yang memiliki implementasi internal untuk + operator.

Juga parameter tipe alias dapat dipaksa untuk memenuhi lebih dari satu antarmuka hanya dengan menambahkan beberapa tipe dan pernyataan validator.

Sekarang, itu akan sangat buruk menggunakan notasi eksplisit apa pun untuk tipe generik yang memiliki parameter yang mengimplementasikan antarmuka Error dan Stringer dan juga merupakan tipe numerik yang mendukung operator + !

sekarang kami menggunakan pembuat kode, yang hampir sama tetapi sebagai fitur eksternal.

Perbedaannya adalah, bahwa cara yang diterima secara luas untuk melakukan pembuatan kode (melalui go generate ) terjadi pada waktu komit/pengembangan, bukan pada waktu kompilasi. Melakukannya pada waktu kompilasi menyiratkan bahwa Anda perlu mengizinkan eksekusi kode arbitrer di kompiler, perpustakaan dapat meledakkan waktu kompilasi berdasarkan urutan besarnya dan/atau Anda akan memiliki dependensi build yang terpisah (yaitu kode tidak lagi dapat dibangun hanya dengan Go alat). Saya suka Go karena mendorong permintaan pemrograman meta ke pengembang hulu.

Artinya, karena semua pendekatan untuk memecahkan masalah ini, pendekatan ini juga memiliki kelemahan dan melibatkan pengorbanan. Secara pribadi, saya berpendapat bahwa obat generik yang sebenarnya dengan dukungan dalam sistem tipe tidak hanya lebih baik (yaitu memiliki kumpulan fitur yang lebih kuat) tetapi juga dapat mempertahankan keunggulan kompilasi yang dapat diprediksi dan aman.

Saya akan membaca semua hal di atas, saya berjanji, namun saya akan menambahkan sedikit juga - GoLang SDK untuk Apache Beam tampaknya contoh yang cukup terang/pameran masalah yang harus ditanggung oleh perancang perpustakaan untuk melakukan apa pun _dengan benar_ tingkat tinggi.

Setidaknya ada dua implementasi eksperimental untuk generik Go. Awal minggu ini saya menghabiskan waktu dengan (1). Saya senang mengetahui bahwa dampak keterbacaan kode sangat minim. Dan saya menemukan penggunaan fungsi anonim untuk memberikan tes kesetaraan bekerja dengan baik; jadi saya yakin bahwa operator overloading tidak diperlukan. Satu-satunya masalah yang saya temukan adalah dalam penanganan kesalahan. Ungkapan umum "return nil,err" tidak akan berfungsi jika tipenya, katakanlah, integer atau string. Ada beberapa cara untuk menyiasatinya, semuanya dengan biaya yang rumit. Saya mungkin agak aneh, tapi saya suka penanganan kesalahan Go. Jadi ini mengarahkan saya untuk mengamati bahwa solusi generik Go harus memiliki kata kunci universal untuk nilai nol suatu tipe. Kompiler hanya akan menggantinya dengan nol untuk tipe numerik, string kosong untuk tipe string, dan nil untuk struct.

Meskipun implementasi ini tidak menerapkan pendekatan tingkat paket, tentu wajar untuk melakukannya. Dan, tentu saja, implementasi ini tidak membahas semua detail teknis tentang ke mana kode yang dibuat oleh kompiler harus pergi (jika di mana saja), bagaimana debugger kode akan bekerja, dll.

Cukup menyenangkan menggunakan kode algoritme yang sama untuk bilangan bulat dan sesuatu seperti Point:

type Point struct {
    x,y int
}

Lihat (2) untuk pengujian dan pengamatan saya.

(1) https://github.com/albrow/fo; yang lainnya adalah https://github.com/cosmos72/gomacro#generics yang disebutkan di atas
(2) https://github.com/mandolyte/fo-experiments

@mandolyte Anda dapat menggunakan *new(T) untuk mendapatkan nilai nol jenis apa pun.

Konstruksi bahasa seperti default(T) atau zero(T) (yang pertama adalah yang pertama
di C# IIRC) akan jelas, tetapi OTOH lebih panjang dari *new(T) (walaupun lebih
performans).

06-07-2018 9:15 GMT-05:00 Tom Thorogood [email protected] :

@mandolyte https://github.com/mandolyte Anda dapat menggunakan *new(T) untuk mendapatkan
nilai nol jenis apa pun.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-403046735 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
Ini adalah tes untuk tanda tangan email yang akan digunakan di TripleMint

19642 adalah untuk membahas nilai nol generik

@tmthrgd Entah bagaimana saya melewatkan berita gembira kecil itu. Terima kasih!

pendahuluan

Generik adalah tentang mengkhususkan konstruksi yang dapat disesuaikan. Tiga kategori spesialisasi adalah:

• Jenis Spesialisasi, Type<T> - sebuah _array_;
• Mengkhususkan Diri pada Komputasi, F<T>(T) atau F<T>(Type<T>) - _array yang dapat diurutkan_;
• Notasi Khusus, _LINQ_ misalnya - pernyataan select atau for di Go;

Tentu saja ada bahasa pemrograman yang menyajikan konstruksi yang lebih umum. Tetapi bahasa pemrograman konvensional seperti _C++_, _C#_ atau _Java_ menyediakan konstruksi bahasa yang kurang lebih terbatas pada daftar ini.

pikiran

Kategori pertama dari tipe/konstruksi generik harus tipe agnostik.

Kategori kedua dari tipe/konstruksi generik perlu _bertindak_ pada _properti_ dari parameter tipe. Misalnya _array yang dapat diurutkan_ harus dapat _membandingkan_ _properti yang dapat dibandingkan_ dari item-itemnya. Dengan asumsi T.(P) adalah properti dari T dan A(T.(P)) adalah perhitungan/tindakan yang bertindak atas properti itu, (A, .(P)) dapat diterapkan baik untuk setiap item individual atau dinyatakan sebagai komputasi khusus, diteruskan ke komputasi asli yang dapat disesuaikan. Contoh dari kasus terakhir di Go adalah antarmuka sort.Interface yang juga memiliki fungsi pasangan terpisah sort.Reverse .

Kategori ketiga dari tipe/konstruk generik adalah notasi bahasa _type-specialized_ - tampaknya bukan Go thing _in general_.

pertanyaan

bersambung ...

Umpan balik apa pun yang lebih deskriptif daripada emoji sangat disambut!

@dc0d Saya akan merekomendasikan mempelajari "Elemen Pemrograman" Sepanov sebelum mencoba mendefinisikan Generik. TL;DR adalah kita menulis kode konkret untuk memulai, katakanlah sebuah algoritma yang mengurutkan array. Kemudian kami menambahkan tipe koleksi lain seperti Btree, dll. Kami melihat kami menulis banyak salinan dari algoritma pengurutan yang pada dasarnya sama, jadi kami mendefinisikan beberapa konsep, katakanlah 'dapat diurutkan'. Sekarang kami ingin mengkategorikan algoritma pengurutan, mungkin dengan pola akses yang mereka butuhkan, katakan saja maju, satu pass (aliran), hanya teruskan beberapa pass (daftar tertaut tunggal), dua arah (daftar tertaut ganda), akses acak (daftar tertaut tunggal). Himpunan). Saat menambahkan tipe koleksi baru, kita hanya perlu menunjukkan kategori "koordinat" mana yang termasuk dalam kategori tersebut untuk mendapatkan akses ke semua algoritme pengurutan yang relevan. Kategori algoritme ini sangat mirip dengan antarmuka 'Go'. Saya akan mencari untuk memperluas antarmuka di Go untuk mendukung beberapa parameter tipe, dan tipe abstrak/terkait. Saya tidak berpikir fungsi memerlukan parameterisasi tipe ad-hoc.

@dc0d Sebagai upaya untuk memecah obat generik menjadi bagian-bagian komponen, saya tidak menganggap 3, "notasi khusus," sebagai bagiannya yang terpisah sebelumnya. Mungkin itu bisa dicirikan sebagai mendefinisikan DSL dengan memanfaatkan batasan tipe.

Saya mungkin berpendapat bahwa 1 dan 2 Anda adalah "struktur data" dan "algoritma", masing-masing. Dengan terminologi itu, sedikit lebih jelas mengapa mungkin sulit untuk memisahkan mereka secara bersih, karena mereka seringkali sangat bergantung satu sama lain. Tapi sort.Interface adalah contoh yang cukup bagus di mana Anda dapat menarik garis antara penyimpanan dan perilaku (dengan sedikit gula baru-baru ini untuk membuatnya lebih baik), karena mengkodekan persyaratan yang Dapat Diindeks dan Dapat Dibandingkan ke dalam perilaku minimum yang diperlukan untuk mengimplementasikan algoritme pengurutan dengan "swap" dan "kurang" (dan len). Tapi ini tampaknya memecah struktur data yang lebih rumit seperti pohon atau tumpukan, yang keduanya saat ini membutuhkan beberapa perubahan untuk dipetakan ke dalam perilaku murni sebagai antarmuka Go.

Saya bisa membayangkan tambahan generik yang relatif kecil untuk antarmuka (atau sebaliknya) yang dapat memungkinkan sebagian besar struktur data buku teks dan algoritme diimplementasikan relatif bersih tanpa liuk (seperti sort.Interface saat ini), tetapi tidak cukup kuat untuk merancang DSL. Apakah kita ingin membatasi diri kita pada implementasi obat generik yang dibatasi ketika kita akan kesulitan menambahkan obat generik sama sekali adalah pertanyaan yang berbeda.

Struktur koordinat @infogulch untuk pohon biner adalah "koordinat bifurkasi", dan ada persamaan untuk pohon lain. Namun Anda juga dapat memproyeksikan pemesanan pohon melalui salah satu dari tiga pesanan, pre-order, in-order, dan post-order. Setelah memutuskan salah satunya, pohon dapat dialamatkan sebagai koordinat dua arah, dan keluarga algoritma pengurutan yang didefinisikan pada koordinat dua arah akan menjadi efisien secara optimal.

Intinya adalah Anda mengkategorikan algoritma pengurutan berdasarkan pola aksesnya. Hanya ada sejumlah algoritma pengurutan yang optimal untuk setiap pola akses. Anda tidak peduli tentang struktur data pada saat ini. Berbicara tentang struktur yang lebih kompleks tidak tepat, kami ingin mengkategorikan keluarga algoritma pengurutan bukan struktur data. Data apa pun yang Anda miliki, Anda harus menggunakan salah satu algoritme yang ada untuk mengurutkannya, jadi pertanyaannya adalah kategorisasi pola-akses data yang mana dari algoritme pengurutan yang optimal untuk struktur data yang Anda miliki.

(MENURUT OPINI SAYA)

@infogulch

Mungkin itu bisa dicirikan sebagai mendefinisikan DSL dengan memanfaatkan batasan tipe

Kamu benar. Tetapi karena mereka adalah bagian dari rangkaian konstruksi bahasa, IMO menyebutnya DSL akan sedikit tidak akurat.

1 dan 2 ... seringkali sangat tergantung

Sekali lagi benar. Tetapi ada banyak kasus yang memerlukan jenis wadah untuk diedarkan, sementara penggunaan sebenarnya belum diputuskan - pada saat itu dalam sebuah program. Itu sebabnya 1 perlu dipelajari sendiri.

sort.Interface adalah contoh yang cukup bagus di mana Anda dapat menarik garis antara _storage_ dan _behavior_

Baik mengatakan;

ini tampaknya memecah struktur data yang lebih rumit

Itu adalah salah satu pertanyaan saya: untuk menggeneralisasi parameter tipe dan menggambarkannya dalam batasan (seperti List<T> where T:new, IDisposable ) atau untuk memberikan _protokol_ umum yang berlaku untuk semua item (dari satu set; dari tipe tertentu)?

@keean

pertanyaannya menjadi yang mana dari kategorisasi pola akses data yang tersedia dari algoritma pengurutan yang optimal untuk struktur data yang Anda miliki

Benar. Mengakses dengan indeks adalah _properti_ dari irisan (atau larik). Jadi persyaratan pertama untuk wadah yang dapat diurutkan (atau wadah yang dapat diurutkan _tree_ - apa pun algoritme _tree_nya) adalah menyediakan utilitas _access & mutate (swap)_. Persyaratan kedua adalah item harus sebanding. Itulah bagian yang membingungkan (bagi saya) tentang apa yang Anda sebut algoritme: persyaratan harus dipenuhi di kedua sisi (pada wadah dan pada parameter tipe). Itulah intinya saya tidak bisa membayangkan implementasi generik yang pragmatis di Go. Setiap sisi masalah dapat digambarkan dalam istilah antarmuka dengan sempurna. Tetapi bagaimana menggabungkan keduanya dalam notasi yang efektif?

Algoritma @dc0d membutuhkan antarmuka, struktur data menyediakannya. Ini cukup untuk generalisasi penuh, asalkan antarmukanya cukup kuat. Antarmuka diparameterisasi berdasarkan tipe, tetapi Anda memerlukan variabel tipe.

Mengambil contoh 'sort', 'Ord' adalah properti dari tipe yang disimpan dalam wadah, bukan wadah itu sendiri. Pola akses adalah properti dari wadah. Pola akses sederhana adalah 'iterator', tetapi nama itu berasal dari C++, Stepanov lebih memilih 'koordinat' karena dapat diterapkan ke wadah multi-dimensi yang lebih kompleks.

Mencoba mendefinisikan sort, kami menginginkan sesuatu seperti ini:

bubble_sort : forall T U I => T U -> T U requires
   ForwardIterator<T>, Readable<T>, Writable<T>,
   Ord<U>,  ValueType(T) == U, Distance type(T) == I

Catatan: Saya tidak menyarankan notasi ini, hanya mencoba menarik beberapa pekerjaan terkait lainnya, klausa require ada dalam sintaks yang disukai oleh Stepanov, tipe fungsinya berasal dari Haskell, yang kelas tipenya mungkin mewakili implementasi yang baik dari konsep ini.

@keean
Mungkin saya salah paham dengan Anda, tetapi saya rasa Anda tidak dapat membatasi algoritme hanya untuk antarmuka saja, setidaknya dalam cara antarmuka didefinisikan sekarang.
Pertimbangkan sort.Slice misalnya, kami tertarik untuk menyortir irisan, dan saya tidak melihat bagaimana seseorang akan membangun antarmuka yang akan mewakili semua irisan.

@urandom Anda mengabstraksikan algoritme, bukan koleksi. Jadi Anda bertanya, pola akses data apa yang ada dalam algoritme "sortir", dan kemudian mengklasifikasikannya. Jadi tidak masalah apakah wadahnya adalah "slice" kami tidak mencoba untuk mendefinisikan semua operasi yang mungkin ingin Anda lakukan pada sebuah slice, kami mencoba untuk menentukan persyaratan dari suatu algoritma dan menggunakannya untuk mendefinisikan sebuah antarmuka. Sebuah irisan tidak istimewa, itu hanya tipe T yang dapat kita definisikan satu set operasi.

Jadi antarmuka berhubungan dengan pustaka algoritme, dan Anda dapat menentukan antarmuka Anda sendiri untuk struktur data Anda sendiri agar dapat menggunakan algoritme tersebut. Pustaka bisa datang dengan antarmuka yang telah ditentukan sebelumnya untuk tipe bawaan.

@keean
Saya pikir itu yang Anda maksud. Tetapi dalam konteks Go, itu mungkin berarti bahwa perlu ada perombakan signifikan dari apa yang dapat didefinisikan oleh antarmuka. Saya membayangkan bahwa berbagai operasi bawaan, seperti iterasi, atau operator, perlu diekspos melalui metode agar hal-hal seperti sort.Slice atau math.Max dibuat generik melalui antarmuka.

Jadi, Anda harus memiliki dukungan untuk antarmuka berikut (kode semu):

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

dan semua irisan akan memiliki metode ini?

@urandom Iterator bukan abstraksi koleksi, tetapi abstraksi referensi/penunjuk ke dalam koleksi. Misalnya forward iterator dapat memiliki satu metode 'penerus' (terkadang 'berikutnya'). Mampu mengakses data di lokasi iterator bukanlah properti iterator (jika tidak, Anda akan berakhir dengan rasa iterator baca/tulis/bisa berubah). Yang terbaik adalah mendefinisikan "referensi" secara terpisah sebagai antarmuka yang Dapat Dibaca, Dapat Ditulis, dan Dapat Diubah:

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

Catatan: Jenis 'T' bukanlah irisan, tetapi jenis iterator pada irisan. Ini bisa menjadi penunjuk biasa, jika kita mengadopsi gaya C++ untuk meneruskan iterator awal dan akhir ke fungsi seperti sort.

Untuk iterator akses acak, kita akan berakhir dengan sesuatu seperti:

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

Jadi iterator/koordinat adalah abstraksi dari referensi ke koleksi, bukan koleksi itu sendiri. Nama 'koordinat' mengungkapkan ini dengan cukup baik, jika Anda menganggap iterator sebagai koordinat, dan koleksi sebagai peta.

Bukankah kami menjual Go short dengan tidak memanfaatkan penutupan fungsi dan fungsi anonim? Memiliki fungsi/metode sebagai tipe kelas satu di Go dapat membantu. Misalnya, menggunakan sintaks dari albrow/fo , pengurutan gelembung mungkin terlihat seperti ini:

type SortableContainer[C,T] struct {
    Less func(C,T,T) bool
    Swap func(C,int,int)
    Next func(C) (T,bool)
}

func (bs *SortableContainer[C,T]) BubbleSort(container C, e1,e2 T) {    
    swapCount := 1
    var item1, item2 T
    item1, ok1 = bs.Next()
    if !ok1 {return}
    item2, ok2 = bs.Next()
    if !ok2 {return}
    for swapCount > 0 {
        swapCount = 0
        for {
            if Less(item2, item1) { 
                bs.Swap(C,item2,item1)
                swapCount += 1
            }
        }
    }
}

Harap abaikan kesalahan apa pun... sama sekali belum teruji!

@mandolyte Saya tidak yakin apakah ini ditujukan kepada saya? Saya tidak benar-benar melihat perbedaan antara apa yang saya sarankan dan contoh Anda, kecuali Anda menggunakan antarmuka multi-parameter, dan saya memberikan contoh menggunakan tipe abstrak/terkait. Untuk lebih jelasnya, saya pikir Anda memerlukan antarmuka multi-parameter, dan tipe abstrak/terkait untuk generalisasi penuh, yang saat ini tidak didukung oleh Go.

Saya akan menyarankan antarmuka Anda kurang umum daripada yang saya usulkan, karena mereka mengikat urutan pengurutan, pola akses, dan aksesibilitas ke antarmuka yang sama, yang tentu saja akan menghasilkan proliferasi antarmuka, misalnya dua pesanan (kurang , lebih besar), tiga jenis akses (hanya-baca, hanya-tulis, dapat diubah) dan lima pola akses (terusan-single-pass, maju-multi-pass, dua arah, diindeks, acak) akan menghasilkan 36 antarmuka dibandingkan dengan hanya 11 jika masalah disimpan terpisah.

Anda dapat mendefinisikan antarmuka yang saya usulkan dengan antarmuka multi-parameter alih-alih tipe abstrak seperti ini:

type I ForwardIterator interface {
   successor(x I) I
}
type R V Readable interface {
   source(x R) V
}
type V Ord interface {
   less(x V, y V) : bool
}

Perhatikan bahwa satu-satunya yang membutuhkan dua parameter tipe adalah antarmuka Readable. Namun kami kehilangan kemampuan untuk objek iterator untuk 'mengandung' jenis objek yang diulang, yang merupakan masalah besar karena sekarang kami harus memindahkan tipe 'nilai' di dalam sistem tipe, dan kami harus memperbaikinya . Hal ini menyebabkan proliferasi parameter tipe yang tidak baik, dan meningkatkan kemungkinan kesalahan pengkodean. Kami juga kehilangan kemampuan untuk mendefinisikan 'DistanceType' pada iterator, yang merupakan tipe angka terkecil yang diperlukan untuk menghitung elemen dalam koleksi, yang berguna untuk pemetaan ke int8, int16, int32 dll, untuk memberikan tipe yang Anda butuhkan menghitung elemen tanpa overflow.

Ini terkait erat dengan konsep 'ketergantungan fungsional'. Jika suatu tipe secara fungsional bergantung pada tipe lain, itu harus menjadi tipe abstrak/terkait. Hanya jika kedua tipe tersebut independen, mereka akan menjadi parameter tipe yang terpisah.

Beberapa masalah:

1. Tidak dapat menggunakan sintaks f(x I) saat ini untuk antarmuka multi-parameter. Saya tidak suka sintaks ini membingungkan antarmuka (yang merupakan batasan pada tipe) dengan tipe.
2. Akan membutuhkan cara untuk mendeklarasikan tipe yang diparameterisasi.
3. Perlu ada cara untuk mendeklarasikan tipe terkait untuk antarmuka dengan serangkaian parameter tipe tertentu.

@keean Tidak yakin saya mengerti bagaimana atau mengapa jumlah antarmuka menjadi sangat tinggi. Berikut adalah contoh kerja yang lengkap: https://play.folang.org/p/BZa6BdsfBgZ (berbasis irisan, bukan wadah umum, sehingga tidak diperlukan metode Next()).

Ini hanya menggunakan satu jenis struct, tidak ada antarmuka sama sekali. Saya harus menyediakan semua fungsi dan penutupan anonim (mungkin di situlah trade offnya?). Contoh ini menggunakan algoritme pengurutan gelembung yang sama untuk mengurutkan potongan bilangan bulat dan potongan Poin "(x,y)", di mana jarak dari asal adalah dasar dari fungsi Less().

Bagaimanapun, saya berharap untuk menunjukkan bagaimana memiliki fungsi dalam sistem tipe dapat membantu.

@mandolyte Saya pikir saya salah mengerti apa yang Anda usulkan. Saya melihat apa yang Anda bicarakan adalah "folang" yang sudah memiliki beberapa fitur pemrograman fungsional yang bagus yang ditambahkan ke Go. Apa yang telah Anda terapkan pada dasarnya adalah membuat kelas tipe multi-parameter dengan tangan. Anda meneruskan apa yang dikenal sebagai kamus fungsi ke fungsi sortir. Ini melakukan secara eksplisit apa yang akan dilakukan antarmuka secara implisit. Fitur semacam ini mungkin diperlukan sebelum antarmuka multi-parameter dan tipe terkait, tetapi Anda akhirnya mengalami masalah saat melewati semua kamus itu. Saya pikir antarmuka menyediakan kode yang lebih bersih dan lebih mudah dibaca.

Menyortir irisan adalah masalah yang terpecahkan. Berikut kode untuk quicksort.go slice yang diimplementasikan menggunakan bahasa go-li (golang ditingkatkan) .

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

Anda dapat bereksperimen dengan ini di taman bermain

Contoh lengkap Anda dapat menempelkan ke taman bermain , karena mengimpor paket quicksort tidak berfungsi di taman bermain.

@go-li Saya yakin Anda dapat mengurutkan sepotong, akan sedikit buruk jika Anda tidak bisa. Intinya adalah secara umum Anda ingin dapat mengurutkan wadah linier apa pun dengan kode yang sama, sehingga Anda hanya perlu menulis algoritme pengurutan satu kali, apa pun wadah (struktur data) yang Anda urutkan dan apa pun jenisnya. konten adalah.

Ketika Anda dapat melakukan ini, pustaka standar dapat menyediakan fungsi penyortiran universal, dan tidak ada yang perlu menulisnya lagi. Ada dua manfaat untuk ini, lebih sedikit kesalahan karena lebih sulit daripada yang Anda pikirkan untuk menulis algoritma pengurutan yang benar, Stepanov menggunakan contoh bahwa sebagian besar programmer tidak dapat dengan benar mendefinisikan pasangan 'min' dan 'max', jadi apa harapan kita? benar untuk algoritma yang lebih kompleks. Manfaat lainnya adalah ketika hanya ada satu definisi dari setiap algoritma pengurutan, setiap peningkatan dalam kejelasan atau kinerja yang dapat dilakukan akan menguntungkan semua program yang menggunakannya. Orang dapat menghabiskan waktu mereka untuk mencoba meningkatkan algoritme umum daripada harus menulis sendiri untuk setiap tipe data yang berbeda.

@keean
Pertanyaan lain terkait dengan diskusi kita sebelumnya. Saya tidak tahu bagaimana seseorang dapat mendefinisikan fungsi pemetaan yang mengubah item dari iterable, mengembalikan tipe iterable beton baru yang itemnya mungkin dari tipe yang berbeda dari yang asli.

Dan saya membayangkan pengguna fungsi seperti itu ingin tipe konkret dikembalikan, bukan antarmuka lain.

@urandom Dengan asumsi kami tidak bermaksud melakukannya 'di tempat' yang tidak aman, yang Anda inginkan adalah fungsi peta yang memiliki 'read-iterator' dari satu jenis dan 'write-iterator' dari jenis lain, yang dapat didefinisikan sesuatu seperti:

map<I, O, U>(first I, last I, out O, fn U) requires
   ForwardIterator<I>, Readable<I>,
   ForwardIterator<O>, Writable<O>,
   UnaryFunction<U>, Domain(U) == ValueType(I), Codomain(U) == ValueType(O)

Untuk kejelasan, "ValueType" adalah jenis antarmuka yang terkait "Dapat dibaca" dan "Dapat ditulis", "Domain" dan "Codomain" adalah jenis antarmuka "UnaryFunction" yang terkait. Jelas sangat membantu jika kompiler dapat secara otomatis menurunkan antarmuka untuk tipe data seperti "UnaryFunction". Sementara ini tampak seperti refleksi, tidak, dan itu semua terjadi pada waktu kompilasi menggunakan tipe statis.

@keean Bagaimana memodelkan kendala Readable dan Writable tersebut dalam konteks antarmuka Go saat ini?

Maksud saya, ketika kita memiliki tipe A dan kita ingin mengonversi ke tipe B , tanda tangan dari UnaryFunction itu adalah func (input A) B (kan?), tapi bagaimana bisa? dimodelkan hanya menggunakan antarmuka dan bagaimana map generik itu (atau filter , reduce , dll.) akan dimodelkan untuk menjaga jenis pipa?

@geovanisouza92 Saya pikir "Jenis Keluarga" akan bekerja dengan baik karena mereka dapat diimplementasikan sebagai mekanisme ortogonal dalam sistem tipe, dan kemudian diintegrasikan ke dalam sintaks untuk antarmuka seperti yang dilakukan di Haskell.

Keluarga tipe seperti fungsi terbatas pada tipe (pemetaan). Karena implementasi antarmuka dipilih berdasarkan tipe, kami dapat menyediakan pemetaan tipe untuk setiap implementasi.

Jadi jika kita definisikan:

ValueType MyIntArrayIterator -> Int

Fungsi sedikit menipu tetapi fungsi memiliki tipe, misalnya:

fn(x : Int) Float

Kami akan menulis jenis ini:

Int -> Float

Penting untuk disadari bahwa -> hanyalah konstruktor tipe infix, seperti '[]' untuk Array adalah konstruktor tipe, kita bisa dengan mudah menulis ini;

Fn Int Float
Or
Fn<Int, Float>

Tergantung pada preferensi kami untuk jenis sintaks. Sekarang kita dapat dengan jelas melihat bagaimana kita dapat mendefinisikan:

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

Sekarang sementara kami dapat memberikan semua definisi ini dengan tangan, mereka dapat dengan mudah diturunkan oleh kompiler.

Mengingat keluarga tipe ini, kita dapat melihat bahwa definisi peta yang saya berikan di atas hanya membutuhkan tipe IO dan U untuk membuat instance generik, karena semua tipe lain secara fungsional bergantung pada ini. Kita bisa melihat tipe ini langsung disediakan oleh argumen.

Terima kasih @kean.

Ini akan berfungsi dengan baik untuk fungsi bawaan/yang telah ditentukan sebelumnya. Apakah Anda mengatakan konsep yang sama akan diterapkan untuk fungsi yang ditentukan pengguna atau lib userland?

"Jenis Keluarga" itu akan dibawa untuk runtime, dalam kasus beberapa konteks kesalahan?

Bagaimana dengan antarmuka kosong, sakelar ketik, dan refleksi?

EDIT: Saya hanya ingin tahu, tidak mengeluh.

@giovanisouza92 yah tidak ada yang berkomitmen Pergi untuk memiliki obat generik jadi saya berharap skeptisisme. Pendekatan saya adalah jika Anda akan melakukan obat generik, Anda harus melakukannya dengan benar.

Dalam contoh saya, 'peta' ditentukan oleh pengguna. Tidak ada yang istimewa tentangnya, dan di dalam fungsi tersebut Anda cukup menggunakan metode antarmuka yang Anda perlukan pada tipe tersebut persis seperti yang Anda lakukan di Go sekarang. Satu-satunya perbedaan adalah bahwa kita dapat meminta suatu tipe untuk memenuhi beberapa antarmuka, antarmuka dapat memiliki beberapa parameter tipe (walaupun contoh peta tidak menggunakan ini) dan ada juga tipe terkait (dan batasan pada tipe seperti kesetaraan tipe '==' tapi ini seperti persamaan Prolog dan menyatukan jenis). Inilah sebabnya mengapa ada sintaks yang berbeda untuk menentukan antarmuka yang diperlukan oleh suatu fungsi. Perhatikan ada perbedaan penting lainnya:

f(x I, y I) requires ForwardIterator<I>

Vs

f(x ForwardIterator, y ForwardIterator)

Perhatikan ada perbedaan di 'x' dan 'y' yang terakhir dapat menjadi tipe berbeda yang memenuhi antarmuka ForwardIterator, sedangkan di sintaks sebelumnya 'x' dan 'y' keduanya harus tipe yang sama (yang memenuhi iterator maju). Ini penting agar fungsi tidak terlalu dibatasi, dan memungkinkan jenis beton disebarkan lebih jauh selama kompilasi.

Saya tidak berpikir ada perubahan mengenai sakelar tipe dan refleksi, karena kami hanya memperluas konsep antarmuka. Karena go memiliki informasi tipe runtime, Anda tidak mengalami masalah yang sama seperti Haskell dan memerlukan tipe eksistensial.

Memikirkan tentang Go, polimorfisme runtime, dan keluarga tipe, kita mungkin ingin membatasi tipe-keluarga itu sendiri ke antarmuka untuk menghindari keharusan memperlakukan setiap tipe terkait sebagai antarmuka kosong saat runtime yang akan lambat.

Jadi mengingat pemikiran itu, saya akan memodifikasi proposal saya di atas sehingga ketika mendeklarasikan antarmuka Anda akan mendeklarasikan antarmuka/tipe untuk setiap tipe terkait bahwa semua implementasi antarmuka itu harus menyediakan tipe terkait yang memenuhi antarmuka itu. Dengan cara itu kita dapat mengetahui bahwa aman untuk memanggil metode apa pun dari antarmuka itu pada tipe terkait saat runtime tanpa harus mengetik-switch dari antarmuka kosong.

@keean
Demi memajukan perdebatan, izinkan saya menghapus kesalahpahaman yang saya rasakan mirip dengan sindrom yang tidak ditemukan di sini.

Iterator dua arah (dalam sintaks T func (*T) *[2]*T ) memiliki tipe func (*) *[2]* dalam sintaks go-li. Dengan kata lain, dibutuhkan pointer ke beberapa tipe dan mengembalikan pointer ke dua pointer ke elemen berikutnya dan sebelumnya dari tipe yang sama. Ini adalah tipe dasar beton dasar yang digunakan oleh daftar tertaut ganda .

Sekarang Anda dapat menulis apa yang Anda sebut peta, yang saya sebut fungsi generik foreach. Jangan salah ini berfungsi tidak hanya pada daftar tertaut tetapi juga pada apa pun yang memperlihatkan iterator dua arah!

func Foreach(link func(*) *[2]*, list **, direction byte, f func(*)) {

    if nil == *list {
        return
    }

    var end *
    end = *list

    var e *
    e = (*link(*list))[direction]
    f(end)

    for (e != end) && ((*link(e))[direction] != nil) {
        var newe = (*link(e))[direction]
        f(e)
        e = newe
    }
    return
}

Foreach dapat digunakan dalam dua cara, Anda menggunakannya dengan lambda dalam iterasi for-loop-like di atas elemen daftar atau koleksi.

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

Atau Anda dapat menggunakannya untuk memetakan fungsi secara fungsional ke setiap elemen koleksi.

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

Iterator dua arah tentu saja dapat juga dimodelkan menggunakan antarmuka di go 1.
interface Iterator { Iter() [2]Iterator } Anda perlu memodelkannya menggunakan antarmuka untuk membungkus ("kotak") jenis yang mendasarinya. Pengguna Iterator kemudian mengetik menegaskan tipe yang diketahui setelah ia menemukan dan ingin mengunjungi elemen koleksi tertentu. Ini berpotensi mengkompilasi waktu tidak aman.

Apa yang Anda gambarkan selanjutnya adalah perbedaan antara pendekatan warisan dan pendekatan berbasis generik.

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

pendekatan ini mengkompilasi tipe waktu memeriksa bahwa kedua koleksi memiliki tipe dasar yang sama, dengan kata lain apakah iterator benar-benar mengembalikan tipe konkret yang sama

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

Sama seperti di atas tetapi menggunakan T yang familier berarti ketik sintaks placeholder

func legacy(x Iterator, y Iterator){}

Dalam hal ini pengguna dapat meneruskan misalnya daftar tertaut integer sebagai x dan daftar tertaut mengambang sebagai y. Ini dapat menyebabkan potensi kesalahan run-time, kepanikan, atau dekoherensi internal lainnya, tetapi itu semua tergantung pada apa yang akan dilakukan warisan dengan dua iterator.

Sekarang kesalahpahaman. Anda mengklaim bahwa melakukan iterator dan melakukan pengurutan generik untuk mengurutkan iterator tersebut akan menjadi cara yang harus dilakukan. Itu akan menjadi hal yang sangat buruk untuk dilakukan, inilah alasannya

Iterator dan daftar tertaut adalah dua sisi dari mata uang yang sama. Bukti: koleksi apa pun yang mengekspos iterator hanya mengiklankan dirinya sebagai daftar tertaut. Katakanlah Anda perlu mengurutkannya. Apa yang harus dilakukan?

Jelas Anda menghapus daftar tertaut dari basis kode Anda dan menggantinya dengan pohon biner. Atau jika Anda ingin lebih suka menggunakan pohon pencarian seimbang seperti avl, merah-hitam, seperti yang diusulkan saya tidak tahu berapa tahun yang lalu oleh Ian dkk. Masih ini belum dilakukan secara umum di golang. Sekarang itu akan menjadi cara untuk pergi.

Solusi lain adalah dengan cepat dalam loop waktu O(N) di atas iterator, mengumpulkan pointer ke elemen ke dalam sepotong pointer generik, dilambangkan []*T dan mengurutkan pointer generik tersebut menggunakan pengurutan irisan yang buruk

Tolong beri ide orang lain kesempatan

@go-li Jika kita ingin menghindari sindrom yang tidak ditemukan di sini, kita harus melihat ke Alex Stepanov untuk definisi, karena ia cukup banyak menemukan pemrograman generik. Inilah cara saya mendefinisikannya, diambil dari "Elements of Programming" Stepanov halaman 111:

Bidirectional iterator<T> =
    ForwardIterator<T>
/\ predecessor : T -> T
/\ predecessor takes constant time
/\ (forall i in T) successor(i) is defined =>
        predecessor(successor(i)) is defined and equals i
/\ (forall i in T) predecessor(i) is defined =>
        successor(predecessor(i)) is defined and equals i

Ini tergantung pada definisi ForwardIterator:

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

Jadi pada dasarnya kami memiliki antarmuka yang mendeklarasikan fungsi successor dan fungsi predecessor , bersama dengan beberapa aksioma yang harus dipatuhi agar valid.

Mengenai legacy bukan berarti warisan akan salah, itu jelas tidak salah di Go saat ini, tetapi kompiler kehilangan peluang pengoptimalan, dan sistem tipe kehilangan kesempatan untuk menyebarkan tipe konkret lebih lanjut. Ini juga membatasi pemrogram untuk menentukan niat mereka secara tepat. Contohnya adalah fungsi identitas, yang saya maksudkan untuk mengembalikan dengan tepat jenis yang dilewatinya:

id(x T) T

Mungkin juga perlu disebutkan perbedaan antara tipe parametrik dan tipe yang dikuantifikasi secara universal. Tipe parametrik akan menjadi id<T>(x T) T sedangkan yang terkuantifikasi universal adalah id(x T) T (kita biasanya menghilangkan quantifier universal terluar dalam hal ini forall T ). Dengan tipe parametrik, sistem tipe harus memiliki tipe untuk T yang disediakan di callsite untuk id , dengan kuantifikasi universal yang tidak diperlukan selama T disatukan dengan tipe konkret sebelum kompilasi selesai. Cara lain untuk memahami bahwa fungsi parametrik bukanlah tipe tetapi templat untuk suatu tipe, dan itu hanya tipe yang valid setelah T diganti untuk tipe konkret. Dengan fungsi yang diukur secara universal id sebenarnya memiliki tipe forall T . T -> T yang dapat diteruskan oleh kompiler seperti Int .

@go-li

Jelas Anda menghapus daftar tertaut dari basis kode Anda dan menggantinya dengan pohon biner. Atau jika Anda ingin lebih suka menggunakan pohon pencarian seimbang seperti avl, merah-hitam, seperti yang diusulkan saya tidak tahu berapa tahun yang lalu oleh Ian dkk. Masih ini belum dilakukan secara umum di golang. Sekarang itu akan menjadi cara untuk pergi.

Memiliki struktur data yang terurut tidak berarti Anda tidak perlu mengurutkan data.

Jika kita ingin menghindari sindrom tidak-ditemukan-di sini kita harus melihat ke Alex Stepanov untuk definisi, karena ia cukup banyak menemukan pemrograman generik.

Saya akan menentang klaim apa pun bahwa pemrograman generik ditemukan oleh C++. Baca Liskov dkk. Kertas CACM 1977 jika Anda ingin melihat model awal pemrograman generik yang benar-benar berfungsi (type-safe, modular, no code bloat): https://dl.acm.org/citation.cfm?id=359789 (lihat Bagian 4 )

Saya pikir kita harus menghentikan diskusi ini dan menunggu tim golang (russ) datang dengan beberapa posting blog dan kemudian menerapkan solusi 👍 (lihat vgo) Mereka akan melakukannya

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

Saya harap cerita ini menjadi peringatan bagi orang lain: jika Anda tertarik untuk memberikan kontribusi substansial pada proyek Go, tidak ada uji tuntas independen yang dapat mengimbangi desain yang tidak berasal dari tim inti.

Utas ini menunjukkan bagaimana tim inti tidak tertarik untuk berpartisipasi aktif dalam mencari solusi bersama komunitas.

Tapi pada akhirnya, jika mereka bisa membuat solusi sendiri lagi, tidak masalah bagi saya, selesaikan saja 👍

@andrewcmyers Yah mungkin "diciptakan" agak sulit, yang mungkin lebih seperti David Musser pada tahun 1971, yang kemudian bekerja dengan Stepanov pada beberapa perpustakaan umum untuk Ada.

Elemen Pemrograman bukan buku tentang C++, contohnya mungkin dalam C++ tetapi itu adalah hal yang sangat berbeda. Saya pikir buku ini adalah bacaan penting bagi siapa saja yang ingin menerapkan obat generik dalam bahasa apa pun. Sebelum mengabaikan Stepanov, Anda harus benar-benar membaca buku itu untuk melihat apa sebenarnya isinya.

Masalah ini sudah tegang di bawah batas skalabilitas GitHub. Harap tetap diskusi di sini terfokus pada isu-isu konkret untuk proposal Go.

Akan sangat disayangkan jika Go mengikuti rute C++.

@andrewcmyers Ya, saya dengan sepenuh hati setuju, tolong jangan gunakan C++ untuk saran sintaks atau sebagai patokan untuk melakukan sesuatu dengan benar. Sebagai gantinya, silakan lihat D untuk inspirasi .

@nomad-software

Saya suka D, sangat, tetapi apakah go membutuhkan fitur pemrograman meta waktu kompilasi yang kuat yang ditawarkan D?

Saya tidak suka sintaks template, juga di C++, yang berasal dari zaman batu.

Tapi bagaimana dengan ParametricType yang normalstandar yang ditemukan di Java atau C#, jika diperlukan juga dapat membebani ini dengan ParametricType

Dan lebih jauh lagi, saya tidak suka sintaks panggilan template di D dengan simbol bang, simbol bang lebih banyak digunakan saat ini untuk menunjukkan akses yang dapat diubah atau tidak dapat diubah untuk parameter suatu fungsi.

@nomad-software Saya tidak menyarankan bahwa sintaks C++ atau mekanisme templat adalah cara yang tepat untuk melakukan obat generik. Lebih dari itu "konsep" seperti yang didefinisikan oleh Stepanov memperlakukan tipe sebagai aljabar, yang merupakan cara yang sangat tepat untuk melakukan generik. Lihat kelas tipe Haskell untuk melihat bagaimana tampilannya. Kelas tipe Haskell sangat dekat dengan templat dan konsep c++ ​​secara semantik, jika Anda memahami apa yang sedang terjadi.

Jadi +1 untuk tidak mengikuti sintaks c++ dan +1 untuk tidak menerapkan sistem templat tipe-tidak aman :-)

@keean Alasan sintaks D adalah untuk menghindari <,> sama sekali dan mematuhi tata bahasa bebas konteks. Ini adalah bagian dari poin saya untuk menggunakan D sebagai inspirasi. <,> adalah pilihan yang sangat buruk untuk sintaks parameter generik.

@nomad-software Seperti yang saya tunjukkan di atas (dalam komentar yang sekarang tersembunyi) Anda perlu menentukan parameter tipe untuk tipe parametrik, tetapi tidak untuk tipe yang diukur secara universal (karenanya perbedaan antara Rust dan Haskell, cara penanganan tipe sebenarnya berbeda dalam sistem tipe). Juga konsep C++ == Haskell type-classes == Go interface, setidaknya pada tingkat konseptual.

Apakah sintaks D benar-benar lebih disukai:

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

Mengapa ini lebih baik daripada gaya C++/Java/Rust:

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

Atau gaya Scala:

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

Saya telah melakukan beberapa pemikiran tentang sintaks untuk parameter tipe. Saya tidak pernah menjadi penggemar "kurung sudut" di C++ dan Java karena mereka membuat parsing cukup rumit dan dengan demikian menghambat pengembangan alat. Tanda kurung siku sebenarnya adalah pilihan klasik (dari CLU, Sistem F, dan bahasa awal lainnya dengan polimorfisme parametrik).

Namun, sintaks Go cukup sensitif, mungkin karena sudah sangat singkat. Kemungkinan sintaks berdasarkan tanda kurung siku atau kurung membuat ambiguitas tata bahasa bahkan lebih buruk daripada yang diperkenalkan oleh tanda kurung sudut. Jadi, terlepas dari kecenderungan saya, kurung sudut tampaknya menjadi pilihan terbaik untuk Go. (Tentu saja, ada juga kurung sudut nyata yang tidak akan membuat ambiguitas — — tetapi mereka akan memerlukan penggunaan karakter Unicode).

Tentu saja, sintaks yang tepat yang digunakan untuk parameter tipe kurang penting daripada mendapatkan semantik yang benar. Pada titik itu, bahasa C++ adalah model yang buruk. Pekerjaan kelompok penelitian saya tentang obat generik di Genus (PLDI 2015) dan Familia (OOPSLA 2017) menawarkan pendekatan lain yang memperluas kelas tipe dan menyatukannya dengan antarmuka.

@andrewcmyers Saya pikir kedua makalah itu menarik, tetapi saya akan mengatakan itu bukan arah yang baik untuk Go, karena Genus berorientasi objek, dan Go tidak, dan Familia menyatukan polimorfisme subtipe dan parametrik, dan Go tidak memiliki keduanya. Saya pikir Go harus mengadopsi polimorfisme parametrik atau kuantifikasi universal, itu tidak perlu subtipe, dan menurut saya adalah bahasa yang lebih baik untuk tidak memilikinya.

Saya pikir Go harus mencari obat generik yang tidak memerlukan orientasi objek dan tidak memerlukan subtipe. Go sudah memiliki antarmuka, yang menurut saya merupakan mekanisme yang bagus untuk obat generik. Jika Anda dapat melihat bahwa antarmuka Go == konsep c++ ​​== kelas tipe Haskell, bagi saya tampaknya cara untuk menambahkan obat generik sambil mempertahankan cita rasa 'Go' adalah dengan memperluas antarmuka untuk mengambil beberapa parameter tipe (saya akan seperti tipe terkait pada antarmuka juga, tetapi itu bisa menjadi ekstensi terpisah untuk membantu mendapatkan beberapa parameter tipe diterima). Itu akan menjadi perubahan utama, tetapi untuk mengaktifkan ini perlu ada sintaks 'alternatif' untuk antarmuka di tanda tangan fungsi, sehingga Anda bisa mendapatkan beberapa parameter tipe ke antarmuka, di situlah sintaks braket sudut keseluruhan masuk .

Antarmuka Go bukanlah kelas tipe — mereka hanyalah tipe — tetapi menyatukan antarmuka dengan kelas tipe adalah cara yang ditunjukkan Familia. Mekanisme Genus dan Familia tidak terikat pada bahasa yang sepenuhnya berorientasi objek. Antarmuka Go sudah membuat Go "berorientasi objek" dengan cara yang penting, jadi saya pikir idenya dapat diadaptasi dalam bentuk yang sedikit disederhanakan.

@andrewcmyers

Antarmuka Go bukan kelas tipe — mereka hanya tipe

Mereka tidak berperilaku seperti tipe bagi saya, karena mereka mengizinkan polimorfisme. Objek dalam array polimorfik seperti Addable[] masih memiliki tipe sebenarnya (terlihat oleh refleksi runtime), sehingga mereka berperilaku persis seperti kelas tipe parameter tunggal. Fakta bahwa mereka ditempatkan di tempat tipe di tanda tangan tipe hanyalah notasi singkatan yang menghilangkan variabel tipe. Jangan bingung notasi dengan semantik.

f(x : Addable) == f<T>(x : T) requires Addable<T>

Identitas ini tentu saja hanya berlaku untuk antarmuka parameter tunggal.

Satu-satunya perbedaan yang signifikan antara antarmuka dan kelas tipe parameter tunggal adalah bahwa antarmuka didefinisikan secara lokal, tetapi ini berguna karena menghindari masalah koherensi global yang dimiliki Haskell dengan kelas tipenya. Saya pikir ini adalah poin yang menarik dalam desain ruang. Antarmuka multi-parameter akan memberi Anda semua kekuatan kelas tipe multi-parameter dengan manfaat menjadi lokal. Tidak perlu menambahkan pewarisan atau subtipe apa pun ke bahasa Go (yang menurut saya merupakan dua fitur utama yang mendefinisikan OO).

MENURUT OPINI SAYA:

Masih memiliki tipe default akan lebih disukai daripada DSL yang didedikasikan untuk mengekspresikan batasan tipe. Seperti memiliki fungsi f(s T fmt.Stringer) yang merupakan fungsi umum yang menerima semua jenis yang juga/memuaskan antarmuka fmt.Stringer .

Dengan cara ini dimungkinkan untuk memiliki fungsi generik seperti:

func add(a, b T int) T int {
    return a + b
}

Sekarang fungsi add() bekerja dengan semua jenis T yang seperti int s mendukung operator + .

@dc0d Saya setuju bahwa tampaknya menarik melihat sintaks Go saat ini. Namun itu tidak 'lengkap' karena tidak dapat mewakili semua kendala yang diperlukan untuk obat generik, dan masih akan ada dorongan untuk memperluas ini lebih jauh. Ini akan menghasilkan proliferasi sintaks yang berbeda yang saya lihat bertentangan dengan tujuan kesederhanaan. Pandangan saya adalah bahwa kesederhanaan tidak sederhana, itu harus yang paling sederhana tetapi tetap menawarkan kekuatan ekspresif yang diperlukan. Saat ini saya melihat batasan utama Go dalam kekuatan ekspresif generik adalah kurangnya antarmuka multi-parameter. Misalnya antarmuka Koleksi dapat didefinisikan seperti:

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Jadi ini masuk akal bukan? Kami ingin menulis antarmuka di atas hal-hal seperti koleksi. Jadi pertanyaannya adalah bagaimana Anda menggunakan antarmuka ini dalam suatu fungsi. Saran saya akan seperti:

func[T, U] f(c T, e U) (Bool, T) requires Collection[T, U] {
   a := member(c, e)
   d := insert(c, e)
   return a, d
}

Sintaksnya hanya saran, tetapi saya tidak terlalu keberatan dengan sintaksisnya, selama Anda dapat mengekspresikan konsep-konsep ini dalam bahasa.

@keean Tidak akan akurat jika saya mengatakan saya tidak keberatan dengan sintaks sama sekali. Tetapi intinya adalah untuk menekankan memiliki tipe default untuk setiap parameter generik. Dalam hal itu contoh yang diberikan untuk antarmuka akan menjadi:

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Sekarang bagian (T interface{}, U interface{}) membantu mendefinisikan batasan. Misalnya jika anggota dimaksudkan untuk memenuhi fmt.Stringer , maka definisinya adalah:

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@dc0d Ini sekali lagi akan membatasi dalam arti bahwa Anda ingin membatasi lebih dari satu jenis parameter, pertimbangkan:

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

Saya pikir saya melihat dari mana Anda berasal dengan penempatan parameter, Anda dapat memiliki:

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

Seperti yang saya katakan, saya tidak terlalu sibuk dengan sintaks, karena saya bisa terbiasa dengan sebagian besar sintaks. Dari atas saya anggap Anda lebih suka tanda kurung '()' untuk antarmuka multi-parameter.

@keean Mari kita pertimbangkan antarmuka heap.Interface . Definisi saat ini di perpustakaan standar adalah:

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

Sekarang mari kita tulis ulang sebagai antarmuka generik, menggunakan tipe default:

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

Ini tidak merusak seri kode Go 1.x di luar sana. Salah satu implementasinya adalah proposal saya untuk Type Alias ​​Rebinding. Tapi saya yakin bisa ada implementasi yang lebih baik.

Memiliki tipe default memungkinkan kita menulis kode generik yang dapat digunakan dengan kode gaya Go 1.x. Dan perpustakaan standar dapat menjadi perpustakaan umum, tanpa merusak apa pun. Itu kemenangan besar IMO.

@dc0d jadi Anda menyarankan peningkatan bertahap? Apa yang Anda sarankan terlihat baik bagi saya sebagai peningkatan bertahap, namun masih memiliki kekuatan ekspresif generik yang terbatas. Bagaimana Anda menerapkan antarmuka "Koleksi" dan "OrderedCollection"?

Pertimbangkan bahwa beberapa ekstensi bahasa parsial dapat menghasilkan produk akhir yang lebih kompleks (dengan beberapa sintaks alternatif) daripada mengimplementasikan solusi lengkap dengan cara paling sederhana yang Anda bisa.

@keean Saya tidak mengerti bagian requires Collection[T, U], Ord[U] . Bagaimana mereka membatasi parameter tipe T dan U ?

@dc0d Mereka bekerja dengan cara yang sama seperti dalam suatu fungsi, tetapi berlaku untuk semuanya. Jadi untuk setiap Pair dari tipe TU yang merupakan OrderedCollection kami mensyaratkan bahwa TU juga merupakan turunan dari Collection dan U adalah Ord. Jadi di mana pun kita menggunakan OrderedCollection, kita dapat menggunakan metode dari Collection dan Ord yang sesuai.

Jika kita sedang minimalis, ini tidak diperlukan, karena kita dapat menyertakan antarmuka tambahan dalam tipe fungsi yang kita butuhkan, misalnya:

type OrderedCollection interface(T, U)
{
   first(c T) U
}

func[T] first(c T[]) T requires Collection(T[], T), Ord T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T), Collection(T[], T), Ord(T)
{...}

Tapi ini mungkin lebih mudah dibaca:

type OrderedCollection interface(T, U) 
   requires Collection(T, U), Ord(U)
{
   first(c T) U
}

func[T] first(c T[]) T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T)
{...}

@keean (IMO) Selama ada nilai default wajib untuk parameter tipe, saya merasa senang. Dengan cara itu dimungkinkan untuk mempertahankan kompatibilitas mundur dengan seri kode Go 1.x. Itulah poin utama yang saya coba sampaikan.

@keean

Antarmuka Go bukan kelas tipe — mereka hanya tipe

Mereka tidak berperilaku seperti tipe bagi saya, karena mereka mengizinkan polimorfisme.

Ya, mereka mengizinkan polimorfisme subtipe . Go memiliki subtipe melalui tipe antarmuka. Itu tidak secara eksplisit mendeklarasikan hierarki subtipe, tetapi itu sebagian besar ortogonal. Apa yang membuat Go tidak sepenuhnya berorientasi objek adalah kurangnya pewarisan.

Atau, Anda dapat melihat antarmuka sebagai aplikasi kelas tipe yang dikuantifikasi secara eksistensial. Saya percaya itulah yang ada dalam pikiran Anda. Itulah yang kami lakukan di Genus dan Familia.

@andrewcmyers

Ya, mereka mengizinkan polimorfisme subtipe.

Sejauh yang saya tahu adalah invarian, tidak ada kovarians atau kontravarians, ini berbicara dengan kuat bahwa ini bukan subtipe. Sistem tipe polimorfik bersifat invarian, jadi bagi saya tampaknya Go lebih dekat dengan model ini, dan memperlakukan antarmuka sebagai kelas tipe parameter tunggal tampaknya lebih sejalan dengan kesederhanaan Go. Kurangnya kovarians dan kontravarian adalah manfaat besar bagi obat generik, lihat saja kebingungan yang dibuat oleh hal-hal seperti itu dalam bahasa seperti C#:

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

Saya pikir Go harus benar-benar menghindari kerumitan semacam ini. Bagi saya ini berarti bahwa kami tidak ingin obat generik dan subtipe dalam sistem tipe yang sama.

Atau, Anda dapat melihat antarmuka sebagai aplikasi kelas tipe yang dikuantifikasi secara eksistensial. Saya percaya itulah yang ada dalam pikiran Anda. Itulah yang kami lakukan di Genus dan Familia.

Karena Go memiliki informasi tipe saat runtime, tidak diperlukan kuantifikasi eksistensial. Di Haskell, tipe tidak memiliki kotak (seperti tipe 'C' asli) dan ini berarti setelah kita memasukkan sesuatu ke dalam koleksi eksistensial, kita tidak dapat (dengan mudah) memulihkan tipe konten, yang dapat kita lakukan hanyalah menggunakan antarmuka yang disediakan (kelas tipe ). Ini diimplementasikan dengan menyimpan pointer ke antarmuka di samping data mentah. Di Go, tipe data disimpan sebagai gantinya, datanya adalah 'Kotak' (seperti pada data C# boxed dan unboxed). Dengan demikian Go tidak terbatas hanya pada antarmuka yang disimpan dengan data karena dimungkinkan (dengan menggunakan tipe-case) untuk memulihkan tipe data dalam koleksi, yang hanya mungkin di Haskell dengan menerapkan 'Refleksi' typeclass (walaupun canggung untuk mengeluarkan data, dimungkinkan untuk membuat serial tipe dan data, untuk mengatakan string, dan kemudian deserialise di luar kotak eksistensial). Jadi kesimpulan yang saya miliki adalah bahwa antarmuka Go berperilaku persis seperti kelas tipe, jika Haskell menyediakan kelas tipe 'Refleksi' sebagai bawaan. Dengan demikian tidak ada kotak eksistensial, dan kita masih bisa mengetikkan huruf besar-kecil pada konten koleksi, namun antarmuka berperilaku persis seperti kelas tipe. Perbedaan antara Haskell dan Go adalah dalam semantik data kotak vs data tidak kotak, dan antarmuka adalah kelas tipe parameter tunggal. Akibatnya ketika 'Go' memperlakukan antarmuka sebagai tipe, apa yang sebenarnya dilakukannya adalah:

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

Mungkin perlu dicatat bahwa ini adalah cara kerja "Objek Sifat" yang sama di Rust.

Go benar-benar dapat menghindari eksistensial (terlihat oleh programmer), kovarians dan kontravarians yang merupakan hal yang baik, dan itu akan membuat obat generik lebih sederhana dan lebih kuat menurut saya.

Sejauh yang saya tahu adalah invarian, tidak ada kovarians atau kontravarians, ini berbicara dengan kuat bahwa ini bukan subtipe.

Sistem tipe polimorfik bersifat invarian, jadi bagi saya tampaknya lebih dekat dengan model ini, dan memperlakukan antarmuka sebagai kelas tipe parameter tunggal tampaknya lebih sejalan dengan kesederhanaan Go.

Bolehkah saya menyarankan bahwa Anda berdua benar? Dalam antarmuka itu setara dengan kelas tipe, tetapi kelas tipe adalah bentuk subtipe. Definisi subtipe yang saya temukan sejauh ini semuanya sangat kabur dan tidak tepat dan bermuara pada "A adalah subtipe B, jika yang satu dapat diganti dengan yang lain". Yang, IMO, dapat dengan mudah diperdebatkan untuk dipenuhi oleh tipe class .

Perhatikan, bahwa argumen varians itu sendiri tidak benar-benar berfungsi IMO. Varians adalah properti dari konstruktor tipe, bukan bahasa. Dan cukup normal bahwa tidak semua konstruktor tipe dalam suatu bahasa adalah varian (misalnya, banyak bahasa dengan subtipe memiliki larik yang dapat diubah, yang harus invarian agar aman untuk tipe). Jadi saya tidak mengerti mengapa Anda tidak dapat membuat subtipe tanpa konstruktor tipe varian.

Juga, saya percaya diskusi ini agak terlalu luas untuk masalah di repositori Go. Ini seharusnya bukan tentang membahas seluk-beluk teori tipe, tetapi tentang jika dan bagaimana menambahkan obat generik ke Go.

@Merovius Variance adalah properti yang terkait dengan subtipe. Dalam bahasa tanpa subtipe, tidak ada perbedaan. Agar ada varians di tempat pertama Anda harus memiliki subtipe, yang memperkenalkan masalah kovarians/kontravarians untuk mengetik konstruktor. Namun Anda benar bahwa dalam bahasa dengan subtipe, dimungkinkan untuk memiliki semua tipe-konstruktor invarian.

Kelas tipe sangat jelas bukan subtipe, karena kelas tipe bukan tipe. Namun kita dapat melihat 'tipe antarmuka' di Go sebagai apa yang disebut Rust sebagai 'objek sifat' yang secara efektif merupakan tipe yang diturunkan dari kelas tipe.

Semantik Go tampaknya cocok dengan salah satu model saat ini, karena tidak memiliki varians, dan memiliki 'objek sifat' implisit. Jadi mungkin Go berada pada titik kritis, generik dan sistem tipe dapat dikembangkan di sepanjang garis subtipe, memperkenalkan varians dan berakhir dengan sesuatu seperti generik di C#. Atau Go dapat memperkenalkan antarmuka multi-parameter, memungkinkan antarmuka untuk Koleksi, dan ini akan memutuskan hubungan langsung antara antarmuka dan 'tipe antarmuka'. Misalnya jika Anda memiliki:

type (T, U) Collection interface {
    member : (c T, e U) Bool
    insert: (c T, e U) T
}

member(c int32[], e int32) Bool {...}
insert(c int32[], e int32) int32[] {...}

member(c float32[], e float32) Bool {...}
insert(c float32[], e float32) float32[] {...}

Tidak ada lagi hubungan subtipe yang jelas antara tipe T, U dan Koleksi antarmuka. Jadi Anda hanya dapat melihat hubungan antara tipe instans dan tipe antarmuka sebagai subtipe untuk kasus khusus antarmuka parameter tunggal, dan kami tidak dapat mengekspresikan abstraksi hal-hal seperti koleksi dengan antarmuka parameter tunggal.

Saya pikir untuk obat generik Anda jelas harus dapat memodelkan hal-hal seperti koleksi, jadi antarmuka multi-parameter harus dimiliki bagi saya. Namun saya pikir interaksi antara kovarians dan kontravarians dalam obat generik menciptakan sistem tipe yang terlalu kompleks, jadi saya ingin menghindari subtipe.

@keean Karena antarmuka dapat digunakan sebagai tipe, dan kelas tipe bukan tipe, penjelasan paling alami dari semantik Go adalah bahwa antarmuka bukan kelas tipe. Saya mengerti bahwa Anda berdebat untuk menggeneralisasi antarmuka sebagai kelas tipe; Saya pikir itu adalah arah yang masuk akal untuk mengambil bahasa, dan sebenarnya kami telah mengeksplorasi pendekatan itu secara ekstensif dalam karya kami yang diterbitkan.

Mengenai apakah Go memiliki subtipe, harap pertimbangkan kode berikut:

package main

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = x

func main() {
    print("ok\n")
}

Penetapan dari x ke y menunjukkan bahwa tipe y dapat digunakan di mana tipe x diharapkan. Ini adalah hubungan subtipe, yaitu: CloneableZ <: Cloneable , dan juga S <: CloneableZ . Bahkan jika Anda menjelaskan antarmuka dalam hal kelas tipe, masih akan ada hubungan subtipe yang berperan di sini, seperti S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] .

Perhatikan bahwa akan sangat aman bagi Go untuk mengizinkan fungsi Clone untuk mengembalikan S , tetapi Go kebetulan memberlakukan aturan pembatasan yang tidak perlu untuk kesesuaian dengan antarmuka: pada kenyataannya, aturan yang sama dengan Java awalnya diberlakukan. Subtipe tidak memerlukan konstruktor tipe non-invarian, seperti yang diamati @Merovius .

@andrewcmyers Apa yang terjadi dengan antarmuka multi-parameter, seperti yang diperlukan untuk koleksi abstrak?

Selanjutnya penugasan dari x ke y dapat dilihat sebagai mendemonstrasikan pewarisan antarmuka tanpa subtipe sama sekali. Di Haskell (yang jelas tidak memiliki subtipe) Anda akan menulis:

class Cloneable t => CloneableZ t where...

Di mana kita memiliki x adalah tipe yang mengimplementasikan CloneableZ yang menurut definisi juga mengimplementasikan Cloneable , jadi jelas dapat ditugaskan ke y .

Untuk mencoba dan meringkas, Anda dapat melihat antarmuka sebagai tipe dan Go memiliki subtipe terbatas tanpa konstruktor tipe kovarian atau kontravarian, atau Anda dapat melihatnya sebagai "objek sifat", atau mungkin di Go kami menyebutnya " objek antarmuka", yang secara efektif merupakan wadah polimorfik yang dibatasi oleh "kelas tipe" antarmuka. Dalam model kelas tipe tidak ada subtipe, dan karena itu tidak ada alasan untuk memikirkan kovarians dan kontravarians.

Jika kita tetap menggunakan model subtipe, kita tidak dapat memiliki tipe koleksi, inilah mengapa C++ harus memperkenalkan template, karena subtipe berorientasi objek tidak cukup untuk mendefinisikan konsep secara umum seperti wadah. Kami berakhir dengan dua mekanisme untuk abstraksi, objek dan subtipe, dan templat/sifat dan generik, dan interaksi antara keduanya menjadi kompleks, lihat C++, C#, dan Scala sebagai contoh. Akan ada panggilan lanjutan untuk memperkenalkan konstruktor kovarian dan kontravarian untuk meningkatkan kekuatan generik, sejalan dengan bahasa lain tersebut.

Jika kita menginginkan koleksi generik tanpa memperkenalkan sistem generik yang terpisah, maka kita harus memikirkan antarmuka seperti kelas tipe. Antarmuka multi-parameter berarti tidak lagi memikirkan subtipe, dan sebaliknya memikirkan pewarisan antarmuka. Jika kami ingin meningkatkan obat generik di Go, dan mengizinkan abstraksi hal-hal seperti koleksi, dan kami tidak ingin kerumitan sistem tipe bahasa seperti C++, C#, Scala dll, maka antarmuka multi-parameter, dan pewarisan antarmuka adalah caranya untuk pergi.

@keean

Apa yang terjadi dengan antarmuka multi-parameter, seperti yang diperlukan untuk koleksi abstrak?

Silakan lihat makalah kami tentang Genus dan Familia, yang mendukung batasan tipe multiparameter. Familia menyatukan kendala tersebut dengan antarmuka dan memungkinkan antarmuka untuk membatasi beberapa jenis.

Jika kita tetap menggunakan model subtipe, kita tidak dapat memiliki tipe koleksi

Saya tidak sepenuhnya yakin apa yang Anda maksud dengan "model subtipe", tetapi cukup jelas bahwa Java dan C# memiliki tipe koleksi, jadi klaim ini tidak masuk akal bagi saya.

Di mana kita memiliki x adalah tipe yang mengimplementasikan CloneableZ yang menurut definisi juga mengimplementasikan Cloneable, jadi jelas dapat ditugaskan ke y.

Tidak, dalam contoh saya, x adalah variabel dan y adalah variabel lain. Jika saya tahu bahwa y adalah beberapa tipe CloneableZ dan x adalah beberapa tipe Cloneable , itu tidak berarti bahwa saya dapat menetapkan dari y ke x. Itulah yang dilakukan oleh contoh saya.

Untuk memperjelas bahwa subtipe diperlukan untuk memodelkan Go, di bawah ini adalah versi yang dipertajam dari contoh yang padanan moralnya tidak mengetik-periksa di Haskell. Contoh menunjukkan bahwa subtyping memungkinkan pembuatan koleksi heterogen di mana elemen yang berbeda memiliki implementasi yang berbeda. Selanjutnya, rangkaian implementasi yang mungkin bersifat terbuka.

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

type T struct { x int }

func (t T) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = T{}
var a [2]Cloneable = [2]Cloneable{x, y}

@andrewcmyers

Saya tidak sepenuhnya yakin apa yang Anda maksud dengan "model subtipe", tetapi cukup jelas bahwa Java dan C# memiliki tipe koleksi, jadi klaim ini tidak masuk akal bagi saya.

Lihat mengapa C++ mengembangkan templat, model subtipe OO tidak mampu mengekspresikan konsep umum yang diperlukan untuk menggeneralisasi hal-hal seperti koleksi. C# dan Java juga harus memperkenalkan sistem generik lengkap yang terpisah dari objek, subtipe dan pewarisan, dan kemudian harus membersihkan kekacauan interaksi kompleks kedua sistem dengan hal-hal seperti konstruktor tipe kovarian dan kontravarian. Dengan melihat ke belakang, kita dapat menghindari subtipe OO, dan sebagai gantinya melihat apa yang terjadi jika kita menambahkan antarmuka (kelas tipe) ke bahasa yang diketik sederhana. Inilah yang telah dilakukan Rust sehingga layak untuk dilihat, tetapi tentu saja ini rumit oleh hal seumur hidup. Go memiliki GC sehingga tidak akan memiliki kompleksitas itu. Saran saya adalah bahwa Go dapat diperluas untuk memungkinkan antarmuka multi-parameter, dan menghindari kerumitan ini.

Mengenai klaim Anda bahwa Anda tidak dapat melakukan contoh ini di Haskell, berikut adalah kodenya:

{-# LANGUAGE ExistentialQuantification #-}

class ICloneable t where
    clone :: t -> t

class ICloneable t => ICloneableZ t where
    zero :: t

data S = S deriving Show

instance ICloneable S where
    clone x = x

data T = T Int deriving Show

instance ICloneable T where
    clone x = x

instance ICloneableZ T where
    zero = T 0

data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a

instance Show Cloneable where
    show (ToCloneable x) = show x

main = do
    x <- return S
    y <- return (T 27)
    a <- return [ToCloneable x, ToCloneable y]
    putStrLn (show a)

Beberapa perbedaan menarik, Go secara otomatis menurunkan tipe ini data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a karena ini adalah cara Anda mengubah antarmuka (yang tidak memiliki penyimpanan) menjadi tipe (yang memiliki penyimpanan), Rust juga menurunkan tipe ini dan menyebutnya "objek sifat" . Dalam bahasa lain seperti Java, C# dan Scala, kami menemukan Anda tidak dapat membuat instance antarmuka, yang sebenarnya "benar", antarmuka bukan tipe, mereka tidak memiliki penyimpanan, Go menurunkan tipe wadah eksistensial secara otomatis untuk Anda sehingga Anda dapat memperlakukan antarmuka seperti tipe, dan Go menyembunyikannya dari Anda dengan memberi wadah eksistensial nama yang sama dengan antarmuka asalnya. Hal lain yang perlu diperhatikan adalah bahwa [2]Cloneable{x, y} ini memaksa semua anggota untuk Cloneable , sedangkan Haskell tidak memiliki paksaan implisit seperti itu, dan kita harus secara eksplisit memaksa anggota dengan ToCloneable .

Juga telah ditunjukkan kepada saya bahwa kita tidak boleh mempertimbangkan subtipe S dan T dari Cloneable karena S dan T tidak kompatibel secara struktural. Kami benar-benar dapat mendeklarasikan jenis apa pun sebagai turunan dari Cloneable (hanya dengan mendeklarasikan definisi yang relevan dari fungsi clone di Go) dan jenis tersebut tidak perlu memiliki hubungan satu sama lain sama sekali.

Sebagian besar proposal untuk Generik tampaknya menyertakan token tambahan yang menurut saya mengganggu keterbacaan dan perasaan Go yang sederhana. Saya ingin mengusulkan sintaks yang berbeda yang saya pikir mungkin bisa bekerja dengan baik tata bahasa Go yang ada (bahkan terjadi pada sintaks highlight cukup baik di Github Markdown).

Poin-poin utama dari proposal:

• Tata bahasa Go tampaknya selalu memiliki cara mudah untuk menentukan kapan deklarasi tipe telah berakhir karena ada beberapa token atau kata kunci tertentu yang kami cari. Jika ini benar dalam semua kasus, argumen tipe dapat dengan mudah ditambahkan mengikuti nama tipe itu sendiri.
• Seperti kebanyakan proposal, pengidentifikasi yang sama berarti tipe yang sama dalam deklarasi fungsi apa pun. Pengidentifikasi ini tidak pernah lepas dari deklarasi.
• Di sebagian besar proposal, Anda harus mendeklarasikan argumen tipe generik, tetapi dalam proposal ini tersirat. Beberapa orang akan mengklaim ini menyakitkan keterbacaan atau kejelasan (implisitnya buruk), atau membatasi kemampuan untuk menyebutkan jenis, sanggahan berikut:
  
  
  
  • Ketika datang untuk menyakiti keterbacaan, saya pikir Anda bisa memperdebatkannya dengan cara apa pun, ekstraatau [T] merusak keterbacaan sama banyaknya dengan membuat banyak gangguan sintaksis.
  
  
  • Implisititas bila digunakan dengan benar dapat membantu bahasa menjadi kurang bertele-tele. Kami menghindari deklarasi tipe dengan := sepanjang waktu karena informasi yang disembunyikan oleh itu tidak cukup penting untuk dijabarkan setiap saat.
  
  
  • Memberi nama tipe konkret (non-generik) a atau t mungkin merupakan praktik yang buruk, jadi proposal ini menganggap aman untuk mencadangkan pengidentifikasi ini untuk bertindak sebagai argumen tipe generik. Meskipun ini mungkin memerlukan migrasi perbaikan?
  
  

package main

import "fmt"

type LinkedList a struct {
  Head *Node a
  Tail *Node a
}

type Node a {
  Next *Node a
  Prev *Node a

  Value a
}

func main() {
  // Not sure about how recursive we could get with the inference
  ll := LinkedList string {
    // The string bit could be inferred
    Head: Node string { Value: "hello world" },
  }
}

func (l *LinkedList a) Append(value a) {
  newNode := &Node{Value: value}

  if l.Tail == nil {
    l.Head = newNode
    l.Tail = l.Head
    return
  }

  l.Tail.Next = newNode
  l.Tail = l.Tail.Next
}

Ini diambil dari Intisari yang memiliki sedikit lebih banyak detail serta jenis jumlah yang diusulkan di sini: https://Gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

Ini bukan proposal Generik yang sepenuhnya dihapus dan tidak dimaksudkan demikian, ada banyak masalah yang harus diselesaikan untuk dapat menambahkan obat generik ke Go. Yang ini hanya menangani sintaks, dan saya berharap kita dapat berdiskusi tentang apakah yang diusulkan layak/diinginkan atau tidak.

@aarondl
Terlihat bagus bagi saya, menggunakan sintaks ini kita akan memiliki:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

@keean Tolong jelaskan jenis Collection sedikit. Saya gagal memahaminya:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@dc0d Collection adalah antarmuka yang mengabstraksi _all_ collections, jadi pohon, daftar, irisan dll, sehingga kita dapat memiliki operasi umum seperti member dan insert yang akan bekerja pada koleksi apa pun yang berisi tipe data apa pun. Pada contoh di atas saya berikan contoh pendefinisian 'insert' untuk tipe LinkedList pada contoh sebelumnya:

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

Kita juga bisa mendefinisikannya untuk sebuah slice

func insert(c []a, e a) []a {
   return append(c, e)
}

Namun kami bahkan tidak memerlukan jenis fungsi parametrik dengan variabel tipe seperti yang diilustrasikan oleh @aarondl dengan tipe polimorfik a agar ini berfungsi, karena Anda dapat menentukan untuk tipe konkret:

func insert(c *LinkedList int, e int) *LinkedList int {
   c.Append(e)
   return c
}

func insert(c *LinkedList float, e float) *LinkedList float {
   c.Append(e)
   return c
}

func insert(c int[], e int) int[] {
   return append(c, e)
}

func insert(c float[], e float) float[] {
   return append(c, e)
}

Jadi Collection adalah antarmuka untuk menggeneralisasi kedua jenis wadah dan jenis isinya, memungkinkan fungsi generik ditulis yang beroperasi pada semua kombinasi wadah dan konten.

Tidak ada alasan Anda juga tidak dapat memiliki sepotong koleksi []Collection di mana semua isinya akan menjadi tipe koleksi yang berbeda dengan tipe nilai yang berbeda, memberikan member dan insert ditentukan untuk setiap kombinasi .

@aarondl Mengingat bahwa type LinkedList a sudah merupakan deklarasi tipe yang valid, saya hanya dapat melihat dua cara untuk membuat ini dapat diuraikan dengan jelas: Membuat konteks tata bahasa menjadi sensitif (masuk ke masalah penguraian C, ugh) atau menggunakan lookahead tak terbatas ( yang cenderung dihindari oleh tata bahasa go, karena pesan kesalahan yang buruk dalam kasus kegagalan). Saya mungkin salah memahami sesuatu, tetapi IMO yang menentang pendekatan tanpa token.

@keean Antarmuka di Go menggunakan metode, bukan fungsi. Dalam sintaks spesifik yang Anda sarankan, tidak ada yang melampirkan insert ke *LinkedList untuk kompiler (dalam Haskell yang dilakukan melalui deklarasi instance ). Itu juga normal untuk metode untuk mengubah nilai yang mereka operasikan. Tak satu pun dari ini adalah Show-Stopper, hanya menunjukkan bahwa sintaks yang Anda sarankan tidak bekerja dengan baik dengan Go. Mungkin lebih seperti

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

Yang juga menunjukkan beberapa pertanyaan lagi sehubungan dengan bagaimana parameter tipe dicakup dan bagaimana ini harus diuraikan.

@aarondl ada juga lebih banyak pertanyaan yang saya miliki tentang proposal Anda. Misalnya, itu tidak mengizinkan batasan, jadi Anda hanya mendapatkan polimorfisme tanpa batasan. Yang, secara umum, tidak terlalu berguna, karena Anda tidak diizinkan untuk melakukan apa pun dengan nilai yang Anda peroleh (misalnya, Anda tidak dapat mengimplementasikan Koleksi dengan peta, karena tidak semua jenis adalah kunci peta yang valid). Apa yang harus terjadi ketika seseorang mencoba melakukan hal seperti itu? Jika ini adalah kesalahan waktu kompilasi, apakah itu mengeluh tentang instantiasi (pesan kesalahan C++ di depan) atau pada definisi (pada dasarnya Anda tidak dapat melakukan apa pun, karena tidak ada yang berfungsi dengan semua jenis)?

@keean Masih saya gagal memahami bagaimana a dibatasi untuk menjadi daftar (atau irisan atau koleksi lainnya). Apakah ini tata bahasa khusus yang bergantung pada konteks untuk koleksi? Jika demikian apa nilainya? Tidak mungkin mendeklarasikan tipe yang ditentukan pengguna dengan cara ini.

@Merovius Apakah itu berarti Go tidak dapat melakukan pengiriman ganda, dan membuat argumen pertama dari 'fungsi' menjadi spesial? Ini menunjukkan bahwa tipe terkait akan lebih cocok daripada antarmuka multi-parameter. Sesuatu seperti ini:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt(c Collection, e Collection.Element) {...}

Namun ini masih memiliki masalah karena tidak ada yang membatasi kedua koleksi untuk menjadi tipe yang sama ... Anda akhirnya membutuhkan sesuatu seperti:

func[A] useIt(c A, e A.Element) requires A:Collection

Untuk mencoba menjelaskan perbedaannya, antarmuka multi-parameter memiliki tipe _input_ tambahan yang mengambil bagian dalam pemilihan instance (karenanya koneksi dengan beberapa pengiriman), sedangkan tipe terkait adalah tipe _output_, hanya tipe penerima yang mengambil bagian dalam pemilihan instance, dan kemudian jenis terkait tergantung pada jenis penerima.

@dc0d a dan b adalah parameter tipe antarmuka, sama seperti di kelas tipe Haskell. Agar sesuatu dapat dianggap sebagai Collection ia harus mendefinisikan metode yang cocok dengan tipe di antarmuka di mana a dan b dapat berupa tipe apa pun. Namun seperti yang telah ditunjukkan oleh @Merovius , antarmuka Go berbasis metode, dan tidak mendukung banyak pengiriman sehingga antarmuka multi-parameter mungkin tidak cocok. Dengan model metode pengiriman tunggal Go, kemudian memiliki tipe terkait di antarmuka, alih-alih beberapa parameter tampaknya lebih cocok. Namun kurangnya pengiriman ganda membuat fungsi implementasi seperti unify(x, y) sulit, dan Anda harus menggunakan pola pengiriman ganda yang tidak terlalu bagus.

Untuk menjelaskan hal multi-parameter sedikit lebih jauh:

type Cloneable[A] interface {
   clone(x A) A
}

Di sini a singkatan dari semua jenis, kami tidak peduli apa itu, selama fungsi yang benar didefinisikan, kami menganggapnya Cloneable . Kami akan mempertimbangkan antarmuka sebagai batasan pada tipe daripada tipe itu sendiri.

func clone(x int) int {...}

jadi dalam kasus 'clone' kita mengganti a untuk int dalam definisi antarmuka, dan kita dapat memanggil clone jika substitusi berhasil. Ini sangat cocok dengan notasi ini:

func[A] test(x A) A requires Cloneable[A] {...}

Ini setara dengan:

type Cloneable interface {
   clone() Cloneable
}

tetapi mendeklarasikan fungsi bukan metode, dan dapat diperluas dengan beberapa parameter. Jika Anda memiliki bahasa dengan banyak pengiriman, tidak ada yang istimewa tentang argumen pertama dari suatu fungsi/metode, jadi mengapa menulisnya di tempat yang berbeda.

Karena Go tidak memiliki banyak pengiriman, ini semua mulai terasa seperti terlalu banyak untuk diubah sekaligus. Sepertinya tipe terkait akan lebih cocok, meskipun lebih terbatas. Ini akan memungkinkan koleksi abstrak, tetapi bukan solusi elegan untuk hal-hal seperti penyatuan.

@Merovius Terima kasih telah melihat proposal. Biarkan saya mencoba untuk mengatasi kekhawatiran Anda. Saya sedih Anda tidak menyukai proposal sebelum kita membahasnya lebih lanjut, saya harap saya dapat mengubah pikiran Anda - atau mungkin Anda dapat mengubah saya :)

Pandangan ke depan tanpa batas:
Jadi seperti yang saya sebutkan dalam proposal, saat ini sepertinya tata bahasa Go memiliki cara yang baik untuk mendeteksi "akhir" dari hampir semua hal secara sintaksis. Dan kami masih melakukannya karena argumen generik implisit. Huruf kecil tunggal menjadi konstruksi sintaksis yang menciptakan argumen generik itu - atau apa pun yang kami putuskan untuk membuat token sebaris itu, mungkin kami bahkan mundur ke hal yang di-token seperti @a dalam proposal jika kami cukup menyukai sintaksnya tetapi tidak mungkin diberikan kesulitan kompiler tanpa token, meskipun proposal kehilangan banyak pesona segera setelah Anda melakukannya.

Terlepas dari masalah type LinkedList a di bawah proposal ini tidak terlalu sulit karena kita tahu bahwa a adalah argumen tipe generik dan jadi ini akan gagal dengan kesalahan kompiler yang sama seperti type LinkedList gagal hari ini dengan: prog.go:3:16: expected type, found newline (and 1 more errors) . Posting asli tidak benar-benar keluar dan mengatakannya tetapi Anda tidak diizinkan untuk menyebutkan tipe konkret [a-z]{1} lagi yang saya -pikir- memecahkan masalah ini dan merupakan pengorbanan saya pikir kita semua akan baik-baik saja pembuatan (Saya hanya dapat melihat kerugian dalam membuat tipe nyata dengan nama huruf tunggal dalam kode Go hari ini).

Itu hanya polimorfisme tanpa batas
Alasan saya menghilangkan segala jenis ciri atau batasan argumen generik adalah karena saya merasa itulah peran antarmuka di Go, jika Anda ingin melakukan sesuatu dengan nilai maka nilai itu harus berupa tipe antarmuka dan bukan tipe generik sepenuhnya. Saya pikir proposal ini juga cocok dengan antarmuka.

Di bawah proposal ini, kami masih memiliki masalah yang sama seperti yang kami lakukan sekarang dengan operator seperti + sehingga Anda tidak dapat membuat fungsi add generik untuk semua tipe numerik, tetapi Anda dapat menerima fungsi add generik sebagai argumen. Pertimbangkan hal berikut:

func Sort(slice []a, compare func (a, a) bool) { ... }

Pertanyaan tentang pelingkupan

Anda memberi contoh di sini:

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

Cakupan pengidentifikasi ini sebagai aturan terikat pada deklarasi/definisi tertentu tempat mereka berada. Mereka tidak dibagikan di mana pun dan saya tidak melihat alasan untuk itu.

@keean Itu sangat menarik meskipun seperti yang telah ditunjukkan orang lain, Anda harus mengubah apa yang telah Anda tunjukkan di sana untuk benar-benar dapat mengimplementasikan antarmuka (saat ini dalam contoh Anda tidak ada metode dengan penerima, hanya fungsi). Mencoba lebih memikirkan bagaimana hal ini memengaruhi proposal awal saya.

Huruf kecil satu huruf menjadi konstruksi sintaksis yang menciptakan argumen generik itu

Saya tidak merasa baik tentang itu; itu membutuhkan produksi terpisah untuk apa pengidentifikasi tergantung pada konteks dan juga berarti secara sewenang-wenang melarang pengidentifikasi tertentu untuk jenis. Tapi ini bukan waktu yang tepat untuk membicarakan detail ini.

Di bawah proposal ini kami masih memiliki masalah yang sama seperti yang kami lakukan sekarang dengan operator seperti +

Saya tidak mengerti kalimat ini. Saat ini, operator + tidak memiliki masalah tersebut, karena jenis operandnya diketahui secara lokal dan pesan kesalahannya jelas dan tidak ambigu serta menunjukkan sumber masalahnya. Apakah saya benar dalam mengasumsikan bahwa Anda mengatakan bahwa Anda ingin melarang penggunaan nilai generik apa pun yang tidak diizinkan untuk semua jenis yang mungkin (saya tidak dapat memikirkan banyak operasi seperti itu)? Dan buat kesalahan kompiler untuk ekspresi yang menyinggung dalam fungsi generik? IMO yang akan membatasi nilai obat generik terlalu banyak.

jika Anda ingin melakukan sesuatu dengan nilai maka nilai itu harus berupa tipe antarmuka dan bukan tipe generik sepenuhnya.

Dua alasan utama orang menginginkan obat generik, adalah kinerja (menghindari pembungkusan antarmuka) dan keamanan jenis (memastikan bahwa jenis yang sama digunakan di tempat yang berbeda, sementara tidak peduli yang mana itu). Hal ini tampaknya mengabaikan alasan tersebut.

anda bisa menerima fungsi add generik sebagai argumen.

Benar. Tapi cukup tidak ergonomis. Pertimbangkan berapa banyak keluhan di sana tentang sort API. Untuk banyak wadah generik, jumlah fungsi yang harus diterapkan dan diteruskan oleh pemanggil tampaknya menjadi penghalang. Pertimbangkan, bagaimana implementasi container/heap di bawah proposal ini dan bagaimana itu akan lebih baik daripada implementasi saat ini, dalam hal ergonomi? Tampaknya, kemenangannya dapat diabaikan di sini, paling banter. Anda harus menerapkan lebih banyak fungsi sepele (dan duplikat ke/referensi di setiap situs penggunaan), tidak lebih sedikit.

@Merovius

memikirkan hal ini dari @aarondl

anda bisa menerima fungsi add generik sebagai argumen.

Akan lebih baik untuk memiliki antarmuka Addable untuk memungkinkan penambahan yang berlebihan, mengingat beberapa sintaks untuk mendefinisikan operator infix:

type Addable interface {
   + (x Addable, y Addable) Addable
}

Sayangnya ini tidak berhasil, karena tidak menyatakan bahwa kami mengharapkan semua tipenya sama. Untuk mendefinisikan addable, kita memerlukan sesuatu seperti antarmuka multi-parameter:

type Addable[A] interface {
   + (x A, y A) A
}

Maka Anda juga perlu Go untuk melakukan pengiriman ganda yang berarti semua argumen dalam suatu fungsi diperlakukan seperti penerima untuk pencocokan antarmuka. Jadi dalam contoh di atas, jenis apa pun adalah Addable jika ada fungsi + yang didefinisikan di dalamnya yang memenuhi definisi fungsi dalam definisi antarmuka.

Tetapi mengingat perubahan itu, Anda sekarang dapat menulis:

type S struct {
   value: int
}

func (+) (x S, y S) S {
   return S {
      value: x.value + y.value
   }
}

func main() {
    println(S {value: 27} + S {value: 5})
}

Tentu saja fungsi overloading dan multiple-dispatch mungkin sesuatu yang orang tidak pernah inginkan di Go, tetapi kemudian hal-hal seperti mendefinisikan aritmatika dasar pada tipe yang ditentukan pengguna seperti vektor, matriks, bilangan kompleks dll, akan selalu mustahil. Seperti yang saya katakan di atas 'tipe terkait' pada antarmuka akan memungkinkan beberapa peningkatan kemampuan pemrograman generik, tetapi tidak secara umum penuh. Apakah pengiriman ganda (dan mungkin fungsi kelebihan beban) sesuatu yang bisa terjadi di Go?

hal-hal seperti mendefinisikan aritmatika dasar pada tipe yang ditentukan pengguna seperti vektor, matriks, bilangan kompleks dll, akan selalu mustahil.

Beberapa orang mungkin menganggap itu fitur :) AFAIR ada beberapa proposal atau utas yang beredar di suatu tempat membahas apakah itu harus. FWIW, saya pikir ini - lagi - mengembara di luar topik. Kelebihan operator (atau ide umum "cara membuat Go lebih Haskell") bukanlah inti dari masalah ini :)

Apakah pengiriman ganda (dan mungkin fungsi kelebihan beban) sesuatu yang bisa terjadi di Go?

Tidak pernah berkata tidak. Saya tidak mengharapkannya, secara pribadi.

@Merovius

Beberapa mungkin menganggap itu sebagai fitur :)

Tentu, dan jika Go tidak melakukannya, ada bahasa lain yang akan :-) Go tidak harus menjadi segalanya bagi semua orang. Saya hanya mencoba membuat beberapa ruang lingkup untuk obat generik di Go. Fokus saya adalah membuat bahasa yang sepenuhnya generik, karena saya tidak suka mengulangi diri saya sendiri dan boilerplate (dan saya tidak suka makro). Jika saya punya satu sen untuk setiap kali saya harus menulis daftar tertaut atau pohon di 'C' untuk beberapa tipe data tertentu. Ini sebenarnya membuat beberapa proyek tidak mungkin untuk tim kecil karena volume kode yang perlu disimpan di kepala Anda untuk memahaminya, dan kemudian dipertahankan melalui perubahan. Terkadang saya berpikir bahwa orang yang tidak membutuhkan obat generik hanya belum menulis program yang cukup besar. Tentu saja Anda dapat memiliki tim besar pengembang yang mengerjakan sesuatu dan hanya masing-masing pengembang yang bertanggung jawab atas sebagian kecil dari total kode, tetapi saya tertarik untuk membuat satu pengembang (atau tim kecil) seefektif mungkin.

Mengingat bahwa fungsi overloading dan multiple-dispatch berada di luar cakupan, dan juga mengingat masalah parsing dengan saran @aarondl , tampaknya menambahkan tipe terkait ke antarmuka, dan parameter tipe ke fungsi akan sejauh yang Anda inginkan. pergi dengan obat generik di Go.

Sesuatu seperti ini tampaknya menjadi hal yang benar:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt<T>(c T, e T.Element) requires T:Collection {...}

Kemudian akan ada keputusan dalam implementasi apakah akan menggunakan tipe parametrik atau tipe yang dikuantifikasi secara universal. Dengan tipe parametrik (seperti Java) maka fungsi 'generik' sebenarnya bukan fungsi tetapi semacam templat fungsi yang aman untuk tipe, dan karena itu tidak dapat diteruskan sebagai argumen kecuali jika parameter tipenya disediakan:

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

Dengan tipe yang dikuantifikasi secara universal, Anda dapat meneruskan useIt sebagai argumen, dan kemudian dapat diberikan dengan parameter tipe di dalam f . Alasan untuk mendukung tipe parametrik adalah karena Anda dapat membuat monomorfisme polimorfisme pada waktu kompilasi yang berarti tidak ada elaborasi fungsi polimorfik saat runtime. Saya tidak yakin ini masalah dengan Go, karena Go sudah melakukan pengiriman runtime pada antarmuka, jadi selama parameter type untuk useIt mengimplementasikan Koleksi, Anda dapat mengirim ke penerima yang benar saat runtime, jadi universal kuantifikasi mungkin cara yang tepat untuk Go.

Saya ingin tahu, SFINAE hanya disebutkan oleh @bcmils. Bahkan tidak disebutkan dalam proposal (meskipun Urutkan ada sebagai contoh).
Bagaimana tampilan Sort untuk slice dan linkedlist?

@keean
Saya tidak tahu bagaimana mendefinisikan koleksi 'Irisan' generik dengan saran Anda. Anda tampaknya mendefinisikan 'IntSlice' yang mungkin mengimplementasikan 'Collection' (meskipun Insert mengembalikan tipe yang berbeda dari yang diinginkan oleh antarmuka), tetapi itu bukan 'slice' generik, karena tampaknya hanya untuk int , dan implementasi metode hanya untuk int. Apakah kita perlu mendefinisikan implementasi spesifik per jenis?

Terkadang saya berpikir bahwa orang yang tidak membutuhkan obat generik hanya belum menulis program yang cukup besar.

Saya dapat meyakinkan Anda bahwa kesan itu salah. Dan FWIW, ISTM bahwa "sisi lain" menempatkan "tidak melihat kebutuhan" ke dalam ember yang sama dengan "tidak melihat kegunaan". Saya melihat kegunaannya dan tidak membantahnya. Saya tidak benar-benar melihat kebutuhannya . Saya baik-baik saja tanpa, bahkan dalam basis kode besar.

Dan jangan salah mengartikan "menginginkan mereka dilakukan dengan benar dan menunjukkan di mana proposal yang ada tidak" dengan "secara fundamental menentang gagasan itu".

juga diberikan masalah penguraian dengan saran @aarondl .

Seperti yang saya katakan, saya tidak berpikir berbicara tentang masalah parsing benar-benar produktif sekarang. Masalah parsing dapat diselesaikan. Lach polimorfisme dibatasi jauh lebih serius, semantik. IMO, menambahkan obat generik tanpa itu tidak benar-benar sepadan dengan usaha.

@urandom

Saya tidak tahu bagaimana mendefinisikan koleksi 'Irisan' generik dengan saran Anda.

Seperti yang diberikan di atas, Anda masih perlu mendefinisikan implementasi terpisah untuk setiap jenis irisan, namun Anda masih akan memperoleh keuntungan dari kemampuan menulis algoritme dalam istilah antarmuka generik. Jika Anda ingin mengizinkan implementasi umum untuk semua irisan, Anda harus mengizinkan jenis dan metode terkait parametrik. Catatan Saya memindahkan parameter tipe ke setelah kata kunci sehingga muncul sebelum tipe penerima.

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

Namun sekarang Anda juga harus berurusan dengan spesialisasi, karena seseorang dapat menentukan jenis dan metode terkait untuk []int yang lebih khusus dan Anda harus berurusan dengan yang mana yang akan digunakan. Biasanya Anda akan menggunakan contoh yang lebih spesifik, tetapi itu menambah lapisan kerumitan lainnya.

Saya tidak yakin seberapa banyak ini benar-benar menguntungkan Anda. Dengan contoh asli saya di atas, Anda dapat menulis algoritme generik untuk bertindak pada koleksi umum menggunakan antarmuka, dan Anda hanya perlu menyediakan metode dan tipe terkait untuk tipe yang sebenarnya Anda gunakan. Kemenangan utama bagi saya adalah mampu mendefinisikan algoritma seperti mengurutkan pada koleksi arbitrer dan menempatkan algoritma tersebut di perpustakaan. Jika saya kemudian memiliki daftar "bentuk", saya hanya perlu mendefinisikan metode antarmuka koleksi untuk daftar bentuk saya, dan saya kemudian dapat menggunakan algoritma apa pun di perpustakaan pada mereka. Mampu mendefinisikan metode antarmuka untuk semua jenis irisan kurang menarik bagi saya, dan mungkin terlalu rumit untuk Go?

@Merovius

Saya tidak benar-benar melihat kebutuhannya. Saya baik-baik saja tanpa, bahkan dalam basis kode besar.

Jika Anda dapat mengatasi 100.000 baris program, maka Anda akan dapat melakukan lebih banyak dengan 100.000 baris generik daripada 100.000 baris non-generik (karena pengulangan). Jadi Anda mungkin pengembang super-bintang yang mampu mengatasi basis kode yang sangat besar, tetapi Anda masih akan mencapai lebih banyak dengan basis kode generik yang sangat besar karena Anda akan menghilangkan redundansi. Program generik itu akan berkembang menjadi program non-generik yang lebih besar. Sepertinya bagi saya Anda belum mencapai batas kompleksitas Anda.

Namun saya pikir Anda benar 'kebutuhan' terlalu kuat, saya dengan senang hati menulis kode go, dengan hanya sesekali frustrasi tentang kurangnya obat generik, dan saya dapat mengatasi ini hanya dengan menulis lebih banyak kode, dan di Go kode itu sangat langsung dan literal.

Kurangnya polimorfisme dibatasi jauh lebih serius, semantik. IMO, menambahkan obat generik tanpa itu tidak benar-benar sepadan dengan usaha.

Saya setuju dengan ini.

Anda akan dapat melakukan lebih banyak dengan 100.000 baris generik daripada dengan 100.000 baris non-generik (karena pengulangan)

Saya ingin tahu, dari contoh hipotetis Anda, berapa % dari garis-garis itu yang akan menjadi fungsi umum?
Dalam pengalaman saya ini kurang dari 2% (dari basis kode dengan 115k LOC), jadi saya rasa ini bukan argumen yang bagus kecuali Anda menulis perpustakaan untuk "koleksi"

Saya berharap kita akhirnya mendapatkan obat generik tho

@keean

Mengenai klaim Anda bahwa Anda tidak dapat melakukan contoh ini di Haskell, berikut adalah kodenya:

Kode ini secara moral tidak setara dengan kode yang saya tulis. Ini memperkenalkan jenis pembungkus Cloneable baru selain antarmuka ICloneable. Kode Go tidak memerlukan pembungkus; begitu pula bahasa lain yang mendukung subtipe.

@andrewcmyers

Kode ini secara moral tidak setara dengan kode yang saya tulis. Ini memperkenalkan jenis pembungkus Cloneable baru selain antarmuka ICloneable.

Bukankah ini yang dilakukan kode ini:

type Cloneable interface {...}

Ini menginduksi tipe data 'Cloneable' yang berasal dari antarmuka. Anda tidak melihat 'ICloneable' karena Anda tidak memiliki deklarasi instance untuk antarmuka, Anda cukup mendeklarasikan metodenya.

Bisakah Anda menganggapnya sebagai subtipe ketika tipe yang mengimplementasikan antarmuka tidak harus kompatibel secara struktural?

@keean Saya akan menganggap Cloneable hanya sebagai tipe, bukan "tipe data". Dalam bahasa seperti Java, pada dasarnya tidak ada biaya tambahan untuk abstraksi Cloneable , karena tidak akan ada pembungkus, tidak seperti dalam kode Anda.

Sepertinya saya membatasi dan tidak diinginkan untuk memerlukan kesamaan struktural antara tipe yang mengimplementasikan antarmuka, jadi saya bingung tentang apa yang Anda pikirkan di sini.

@andrewcmyers
Saya menggunakan tipe dan tipe data secara bergantian. Setiap tipe yang dapat berisi data adalah tipe data.

karena tidak akan ada pembungkus, tidak seperti dalam kode Anda.

Selalu ada pembungkus karena tipe Go selalu berbentuk kotak, jadi pembungkus ada di sekitar semuanya. Haskell membutuhkan pembungkusnya secara eksplisit karena memiliki tipe yang tidak dikotak-kotakkan.

kesamaan struktural antara tipe yang mengimplementasikan antarmuka, jadi saya bingung tentang apa yang Anda pikirkan di sini.

Subtipe struktural membutuhkan tipe yang 'kompatibel secara struktural'. Karena tidak ada hierarki tipe eksplisit seperti dalam bahasa OO dengan pewarisan, subtipe tidak boleh nominal, jadi harus struktural, jika ada sama sekali.

Saya mengerti maksud Anda, yang akan saya gambarkan sebagai mempertimbangkan antarmuka sebagai kelas dasar abstrak, bukan antarmuka, dengan semacam hubungan subtipe nominal implisit dengan tipe apa pun yang mengimplementasikan metode yang diperlukan.

Saya benar-benar berpikir Go cocok dengan kedua model sekarang, dan itu bisa berjalan baik dari sini, tetapi saya menyarankan bahwa menyebutnya sebagai antarmuka bukan kelas menyarankan cara berpikir non-subtipe.

@keean Saya tidak mengerti komentar Anda. Pertama, Anda memberi tahu saya bahwa Anda tidak setuju dan bahwa saya "belum memenuhi batas kerumitan saya" dan kemudian Anda memberi tahu saya bahwa Anda setuju (dalam kata "kebutuhan" itu terlalu kuat). Saya juga berpikir argumen Anda keliru (Anda menganggap LOC adalah ukuran utama kompleksitas dan bahwa setiap baris kode sama). Tapi yang terpenting, saya tidak berpikir "siapa yang menulis program yang lebih rumit" benar-benar diskusi yang produktif. Saya hanya mencoba mengklarifikasi, bahwa argumen "jika Anda tidak setuju dengan saya, itu berarti Anda tidak mengerjakan masalah yang sulit atau menarik" tidak meyakinkan dan tidak menunjukkan itikad baik. Saya harap Anda dapat mempercayai bahwa orang-orang dapat tidak setuju dengan Anda tentang pentingnya fitur ini sambil sama-sama kompeten dan melakukan hal-hal yang sama menariknya.

@merovius
Saya mengatakan Anda mungkin seorang programmer yang lebih mampu daripada saya, dan dengan demikian dapat bekerja dengan lebih banyak kompleksitas. Saya tentu tidak berpikir Anda sedang mengerjakan masalah yang kurang menarik atau kurang kompleks, dan saya minta maaf karena menemukan cara itu. Saya menghabiskan kemarin mencoba membuat pemindai berfungsi, yang merupakan masalah yang sangat tidak menarik.

Saya dapat berpikir bahwa obat generik membantu saya menulis program yang lebih kompleks dengan kemampuan otak saya yang terbatas, dan juga mengakui bahwa saya tidak "membutuhkan" obat generik. Ini masalah derajat. Saya masih dapat memprogram tanpa obat generik, tetapi saya belum tentu dapat menulis perangkat lunak dengan kompleksitas yang sama.

Saya harap meyakinkan Anda bahwa saya bertindak dengan itikad baik, saya tidak memiliki agenda tersembunyi di sini, dan jika Go tidak mengadopsi obat generik, saya akan tetap menggunakannya. Saya memiliki pendapat tentang cara terbaik untuk melakukan obat generik, tetapi itu bukan satu-satunya pendapat, saya hanya dapat berbicara dari pengalaman saya sendiri. Jika saya tidak membantu, ada banyak hal lain yang dapat saya gunakan untuk menghabiskan waktu saya, jadi katakan saja, dan saya akan memfokuskan kembali di tempat lain.

@Merovius Terima kasih atas dialog lanjutannya.

| Dua alasan utama orang menginginkan obat generik, adalah kinerja (menghindari pembungkusan antarmuka) dan keamanan jenis (memastikan bahwa jenis yang sama digunakan di tempat yang berbeda, sementara tidak peduli yang mana itu). Hal ini tampaknya mengabaikan alasan tersebut.

Mungkin kita melihat apa yang saya usulkan dengan sangat berbeda, karena dari sudut pandang saya ia melakukan kedua hal ini sejauh yang saya tahu? Dalam contoh daftar tertaut tidak ada pembungkus dengan antarmuka dan oleh karena itu harus berkinerja baik seolah-olah ditulis tangan untuk jenis tertentu. Di sisi tipe-keamanan itu sama. Apakah ada contoh tandingan yang dapat Anda berikan di sini untuk membantu saya memahami dari mana Anda berasal?

| Benar. Tapi cukup tidak ergonomis. Pertimbangkan berapa banyak keluhan di sana tentang jenis API. Untuk banyak wadah generik, jumlah fungsi yang harus diterapkan dan diteruskan oleh pemanggil tampaknya menjadi penghalang. Pertimbangkan, bagaimana tampilan implementasi container/heap di bawah proposal ini dan bagaimana itu akan lebih baik daripada implementasi saat ini, dalam hal ergonomi? Tampaknya, kemenangannya dapat diabaikan di sini, paling banter. Anda harus menerapkan lebih banyak fungsi sepele (dan duplikat ke/referensi di setiap situs penggunaan), tidak lebih sedikit.

Saya sebenarnya tidak mempermasalahkan ini sama sekali. Saya tidak percaya bahwa jumlah fungsi akan menjadi penghalang tetapi saya pasti terbuka untuk melihat beberapa contoh tandingan. Ingatlah bahwa API yang dikeluhkan orang bukanlah API yang harus Anda sediakan fungsinya tetapi yang asli di sini: https://golang.org/pkg/sort/#Interface tempat Anda perlu membuat tipe baru yang sederhana slice + ketik Anda, dan kemudian terapkan 3 metode di atasnya. Mengingat keluhan dan rasa sakit yang terkait dengan antarmuka ini, berikut ini dibuat: https://golang.org/pkg/sort/#Slice , saya tidak memiliki masalah dengan API ini dan kami akan memulihkan penalti kinerja ini di bawah proposal yang sedang kita diskusikan hanya dengan mengubah definisi menjadi func Slice(slice []a, less func(a, a) bool) .

Dalam hal struktur data container/heap apa pun proposal Generik yang Anda terima yang memerlukan penulisan ulang keseluruhan. container/heap seperti paket sort hanya menyediakan algoritme di atas struktur data Anda sendiri, tetapi tidak ada paket yang pernah memiliki struktur data karena jika tidak, kita akan memiliki []interface{} dan biaya yang terkait dengan itu. Agaknya kami akan mengubahnya karena Anda akan dapat memiliki Heap yang memiliki irisan dengan tipe konkret berkat obat generik, dan ini berlaku di bawah salah satu proposal yang pernah saya lihat di sini (termasuk milik saya) .

Saya mencoba untuk memisahkan perbedaan dalam perspektif kami tentang apa yang saya usulkan. Dan saya pikir akar dari ketidaksepakatan (melewati preferensi pribadi secara sintaksis) adalah bahwa tidak ada batasan pada tipe Generik. Tapi saya masih mencoba untuk mencari tahu apa yang menguntungkan kita. Jika jawabannya adalah tidak ada yang menyangkut kinerja yang diizinkan untuk menggunakan antarmuka maka tidak banyak yang bisa saya katakan di sini.

Perhatikan definisi tabel hash berikut:

// Hasher turns a key into a hash
type Hasher interface {
  func Hash() []byte
}

type HashTable v struct {
   Keys   []Hasher
   Values []v
}

// Note that the generic arguments must be repeated here and immediately
// understood without reading another line of code, which to me
// is a readability win over the sudden appearance of the K and V which are
// defined elsewhere in the code in the example below. This is of course because
// the tokenized type declarations with constraints are fairly painful in general
// and repeating them everywhere is simply too much.
func (h (*HashTable v)) Insert(key Hasher, value v) { ... }

Apakah kita mengatakan bahwa []Hasher adalah non-starter karena masalah kinerja/penyimpanan dan bahwa untuk memiliki implementasi Generik yang sukses di Go, kita harus memiliki sesuatu seperti berikut ini?

// Without selecting another proposal I have no idea how the constraint might be defined or implemented so let's just pretend
type [K: Hasher, V] HashTable a struct {
   Keys   []K
   Values []V
}

func (h *HashTable) Insert(key K, value V) { ... }

Semoga Anda melihat dari mana saya berasal. Tapi mungkin saja saya tidak mengerti batasan yang ingin Anda terapkan pada kode tertentu. Mungkin ada kasus penggunaan yang belum saya pertimbangkan, terlepas dari itu, saya berharap untuk mendapatkan pemahaman yang lebih lengkap tentang apa persyaratannya dan bagaimana proposal itu gagal.

Mungkin kita melihat apa yang saya usulkan dengan sangat berbeda, karena dari sudut pandang saya ia melakukan kedua hal ini sejauh yang saya tahu?

"Ini" di bagian yang Anda kutip mengacu pada penggunaan antarmuka. Masalahnya bukan, proposal Anda juga tidak berfungsi, proposal Anda tidak mengizinkan polimorfisme terbatas, yang mengecualikan sebagian besar penggunaan untuk polimorfisme tersebut. Dan alternatif yang Anda sarankan untuk di mana antarmuka, yang juga tidak benar-benar membahas kasus penggunaan inti untuk obat generik (karena dua hal yang saya sebutkan).

Misalnya, proposal Anda (seperti yang ditulis sebelumnya) sebenarnya tidak mengizinkan penulisan peta generik dalam bentuk apa pun, karena itu akan membutuhkan setidaknya untuk dapat membandingkan kunci menggunakan == (yang merupakan kendala, jadi menerapkan a peta membutuhkan polimorfisme terbatas).

Mengingat keluhan dan rasa sakit yang terkait dengan antarmuka ini, berikut ini dibuat: https://golang.org/pkg/sort/#Slice

Perhatikan, bahwa antarmuka ini masih tidak mungkin dalam proposal generik Anda, karena bergantung pada refleksi untuk panjang dan pertukaran (jadi, sekali lagi, Anda memiliki kendala pada operasi irisan). Meskipun kami menerima API tersebut sebagai batas bawah dari apa yang harus dapat dicapai oleh obat generik (banyak orang tidak akan melakukannya. Masih banyak keluhan tentang kurangnya keamanan jenis di API itu), proposal Anda tidak akan lolos bar itu.

Tetapi juga, sekali lagi, Anda mengutip respons ke poin tertentu yang Anda buat, yaitu bahwa Anda bisa mendapatkan polimorfisme terbatas dengan meneruskan literal fungsi di API. Dan cara spesifik yang Anda sarankan untuk mengatasi kurangnya polimorfisme yang dibatasi akan membutuhkan penerapan API lama yang kurang lebih. yaitu Anda mengutip tanggapan saya untuk argumen ini, yang kemudian Anda ulangi:

kami akan memulihkan penalti kinerja ini di bawah proposal yang sedang kami diskusikan hanya dengan mengubah definisi menjadi func Slice(slice []a, less func(a, a) bool).

Itu adalah API lama. Anda mengatakan "proposal saya tidak mengizinkan polimorfisme terbatas, tetapi itu tidak masalah, karena kami tidak dapat menggunakan obat generik dan sebagai gantinya menggunakan solusi yang ada (refleksi/antarmuka) sebagai gantinya". Nah, menanggapi "proposal Anda tidak mengizinkan kasus penggunaan paling dasar yang orang inginkan untuk obat generik" dengan "kita bisa melakukan hal-hal yang sudah dilakukan orang tanpa obat generik untuk kasus penggunaan paling dasar" sepertinya tidak membuat kita mengerti dimana saja, tbh. Proposal generik yang tidak membantu Anda menulis bahkan tipe wadah dasar, sortir, maks... sepertinya tidak sepadan.

ini benar di bawah salah satu proposal yang pernah saya lihat di sini (termasuk milik saya).

Sebagian besar proposal generik menyertakan beberapa cara untuk membatasi parameter tipe. yaitu untuk menyatakan "parameter tipe harus memiliki metode Less", atau "parameter tipe harus sebanding". Milik Anda - AFAICT - tidak.

Perhatikan definisi tabel hash berikut:

Definisi Anda tidak lengkap. a) Jenis kunci juga membutuhkan kesetaraan dan b) Anda tidak mencegah penggunaan jenis kunci yang berbeda. yaitu ini akan menjadi hukum:

type hasherA uint64

func (a hasherA) Hash() []byte {
    b := make([]byte, 8)
    binary.BigEndian.PutUint64(b, uint64(a))
    return b
}

type hasherB string

func (b hasherB) Hash() []byte {
    return []byte(b)
}

h := new(HashTable int)
h.Insert(hasherA(42), 1)
h.Insert(hasherB("Hello world"), 2)

Seharusnya tidak legal, karena Anda menggunakan jenis kunci yang berbeda. yaitu wadah tidak dicentang jenisnya ke tingkat yang diinginkan orang. Anda perlu membuat parameter hashtable pada tipe kunci dan nilai

type HashTable k v struct {
    Keys []k
    Values []v
}

func (h *(HashTable k v)) Insert(key k, value v) {
    // You can't actually do anything with k, as it's unconstrained. i.e. you can't hash it, compare it…
    // Implementing this is impossible in your proposal.
}

// If it weren't impossible, you'd get this:
h := new(HashTable hasherA int)
h[hasherA(42)] = 1
h[hasherB("Hello world")] = 2 // compile error - can't use hasherB as hasherA

Atau, jika membantu, bayangkan Anda mencoba mengimplementasikan hash-set. Anda akan mendapatkan masalah yang sama tetapi sekarang wadah yang dihasilkan tidak memiliki pemeriksaan jenis tambahan apa pun atas interface{} .

Inilah sebabnya mengapa proposal Anda tidak membahas kasus penggunaan yang paling mendasar: Ini bergantung pada antarmuka untuk membatasi polimorfisme, tetapi kemudian tidak benar-benar menyediakan cara apa pun untuk memeriksa konsistensi antarmuka tersebut. Anda dapat memiliki pemeriksaan tipe yang konsisten atau memiliki polimorfisme yang dibatasi, tetapi tidak keduanya. Tapi Anda membutuhkan keduanya.

bahwa untuk memiliki implementasi Generics yang sukses di Go, kita harus memiliki sesuatu seperti berikut ini?

Setidaknya itulah yang saya rasakan tentang itu, ya, cukup banyak. Jika sebuah proposal tidak mengizinkan penulisan wadah atau penyortiran yang aman untuk tipe atau… itu tidak benar-benar menambahkan apa pun ke bahasa yang ada yang cukup signifikan untuk membenarkan biaya.

@Merovius Oke. Saya pikir saya punya pemahaman tentang apa yang Anda inginkan. Perlu diingat bahwa kasus penggunaan Anda sangat jauh dari yang saya inginkan. Saya tidak benar-benar gatal untuk jenis wadah yang aman meskipun saya curiga - seperti yang Anda nyatakan - itu mungkin pendapat minoritas. Beberapa hal terbesar yang ingin saya lihat adalah jenis hasil alih-alih kesalahan dan manipulasi irisan yang mudah tanpa duplikasi atau refleksi di mana pun yang proposal saya melakukan pekerjaan yang wajar untuk mengatasi. Namun, saya dapat melihat bagaimana dari sudut pandang Anda "tidak membahas kasus penggunaan paling dasar" jika kasus penggunaan dasar Anda menulis wadah generik tanpa menggunakan antarmuka,

Perhatikan, bahwa antarmuka ini masih tidak mungkin dalam proposal obat generik Anda, karena bergantung pada refleksi untuk panjang dan pertukaran (jadi, sekali lagi, Anda memiliki kendala pada operasi irisan). Meskipun kami menerima API tersebut sebagai batas bawah dari apa yang harus dapat dicapai oleh obat generik (banyak orang tidak akan melakukannya. Masih banyak keluhan tentang kurangnya keamanan jenis di API itu), proposal Anda tidak akan lolos bar itu.

Membaca ini, jelas Anda telah benar-benar salah memahami cara irisan generik akan/seharusnya bekerja di bawah proposal ini. Melalui kesalahpahaman inilah Anda sampai pada kesimpulan yang salah bahwa "antarmuka ini masih tidak memungkinkan dalam proposal Anda". Di bawah proposal apa pun, irisan generik harus dimungkinkan, inilah yang saya pikirkan. Dan len() di dunia seperti yang saya lihat akan didefinisikan sebagai: func len(slice []a) , yang merupakan argumen irisan umum yang berarti bahwa ia dapat menghitung panjang dengan cara non-refleksi untuk irisan apa pun. Ini adalah inti dari proposal ini seperti yang saya katakan di atas (manipulasi irisan mudah) dan saya minta maaf saya tidak dapat menyampaikannya dengan baik melalui contoh yang saya berikan dan intisari yang saya buat. Slice generik harus dapat digunakan semudah []int hari ini, saya akan mengatakan lagi bahwa setiap proposal yang tidak membahas ini (slice/array swap, penugasan, len, cap, dll. ) gagal menurut saya.

Semua yang dikatakan, sekarang kami benar-benar jelas tentang apa tujuan masing-masing. Ketika saya mengusulkan apa yang saya lakukan, saya sangat mengatakan bahwa itu hanyalah proposal sintaksis dan detailnya sangat kabur. Tapi kami tetap masuk ke detailnya dan salah satu detail itu akhirnya menjadi kurangnya batasan, ketika saya menulisnya, saya tidak memikirkannya karena itu tidak penting untuk apa yang ingin saya lakukan , bukan berarti kami tidak dapat menambahkannya atau tidak diinginkan. Masalah utama dengan melanjutkan sintaks yang diusulkan dan mencoba untuk mengatasi kendala adalah bahwa definisi argumen generik saat ini berulang (sengaja) sehingga tidak ada referensi ke kode di tempat lain untuk menentukan kendala dll. Jika kita memperkenalkan kendala, saya tidak melihat bagaimana kita bisa menjaga ini.

Contoh tandingan terbaik adalah fungsi sortir yang telah kita diskusikan sebelumnya.

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

Seperti yang Anda lihat, tidak ada cara yang bagus untuk mewujudkannya, dan pendekatan token-spam ke Generics mulai terdengar lebih baik lagi. Untuk mendefinisikan batasan pada ini, kita perlu mengubah dua hal dari proposal asli:

• Perlu ada cara untuk menunjuk pada argumen tipe dan memberinya batasan.
• Batasan harus bertahan lebih lama dari satu definisi, mungkin ruang lingkup itu adalah tipe, mungkin ruang lingkup itu adalah file (file sebenarnya terdengar cukup masuk akal).

Penafian: Berikut ini bukan amandemen aktual untuk proposal karena saya hanya membuang simbol acak di luar sana, saya hanya menggunakan sintaks ini sebagai contoh untuk menggambarkan apa yang dapat kami lakukan untuk mengubah proposal seperti aslinya

// Decorator style, follows the definition of the type thorugh all
// of it's methods.
<strong i="14">@a</strong>: Lesser, Hasher, Equaler
func Sort(slice []a) { ... }
<strong i="15">@k</strong>: Equaler, Hasher
type HashTable k v struct

// Inline, follows the definition of the type through
// all of it's methods.
func [a: Hasher, Equaler] Sort(slice []a) { ... }
type [k: Hasher, Equaler] HashTable k v struct

// File-scope global style, if k appears as a generic argument
// it's constrained by this that appears at the top of the file underneath
// the imports but before any other code.
<strong i="16">@k</strong>: Equaler, Hasher

Sekali lagi perhatikan bahwa tidak satu pun di atas yang benar-benar ingin saya tambahkan ke proposal. Saya hanya menunjukkan konstruksi seperti apa yang bisa kita gunakan untuk memecahkan masalah, dan bagaimana tampilannya agak tidak relevan saat ini.

Pertanyaan yang kemudian perlu kita jawab adalah: Apakah kita masih mendapatkan nilai dari argumen generik yang tersirat? Poin utama dari proposal ini adalah untuk menjaga nuansa bahasa Go-like yang bersih, untuk menjaga hal-hal sederhana, untuk menjaga hal-hal cukup rendah kebisingan dengan menghilangkan token yang berlebihan. Dalam banyak kasus di mana tidak ada kendala yang diperlukan, misalnya fungsi peta atau definisi tipe Hasil, apakah terlihat bagus, apakah terasa seperti Go, apakah itu berguna? Dengan asumsi bahwa kendala juga tersedia dalam beberapa bentuk atau lainnya.

func map(slice []a, mapper func(a) b) {
  for i := range slice {
    slice[i] = mapper(slice[i])
  }
}

type Result a b struct {
  Ok  a
  Err b
}

@aarondl Saya akan mencoba menjelaskan. Alasan Anda memerlukan batasan tipe adalah karena itulah satu-satunya cara Anda dapat memanggil fungsi atau metode pada suatu tipe. pertimbangkan tipe yang tidak dibatasi a tipe apa ini, baik itu bisa berupa string atau Int atau apa pun. Jadi kami tidak dapat memanggil fungsi atau metode apa pun di dalamnya karena kami tidak tahu jenisnya. Kita bisa menggunakan tipe-switch dan refleksi runtime untuk mendapatkan tipenya, dan kemudian memanggil beberapa fungsi atau metode di atasnya, tetapi ini adalah sesuatu yang ingin kita hindari dengan obat generik. Ketika Anda membatasi tipe misalnya a adalah Hewan, kami kemudian dapat memanggil metode apa pun yang ditentukan untuk hewan pada a .

Dalam contoh Anda, ya, Anda dapat memasukkan fungsi mapper, tetapi ini akan mengakibatkan fungsi mengambil banyak argumen, dan pada dasarnya seperti bahasa tanpa antarmuka, hanya fungsi kelas satu. Untuk melewati setiap fungsi yang akan Anda gunakan pada tipe a akan mendapatkan daftar fungsi yang sangat panjang dalam program nyata apa pun, terutama jika Anda menulis terutama kode generik untuk injeksi ketergantungan, yang ingin Anda lakukan untuk meminimalkan kopling.

Misalnya bagaimana jika fungsi yang memanggil peta juga generik? Bagaimana jika fungsi yang memanggil itu generik dll. Bagaimana kita mendefinisikan mapper jika kita belum mengetahui jenis a ?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

Fungsi apa yang dapat kita panggil x ketika mencoba mendefinisikan mapper ?

@keean Saya mengerti tujuan dan fungsi dari kendala. Saya hanya tidak menghargai mereka setinggi hal-hal sederhana seperti struct wadah generik (bukan wadah generik untuk berbicara) dan irisan generik dan karena itu bahkan tidak memasukkannya ke dalam proposal asli.

Saya sebagian besar masih percaya bahwa antarmuka adalah jawaban yang tepat untuk masalah seperti yang Anda bicarakan di mana Anda melakukan injeksi ketergantungan, yang sepertinya bukan tempat yang tepat untuk obat generik tetapi siapa yang harus saya katakan. Tumpang tindih antara tanggung jawab mereka cukup besar di mata saya, oleh karena itu mengapa @Merovius dan saya harus berdiskusi apakah kami bisa hidup tanpa mereka atau tidak, dan dia cukup membuat saya yakin mereka akan berguna dalam beberapa kasus penggunaan maka saya menjelajahi sedikit tentang apa yang mungkin dapat kami lakukan untuk menambahkan fitur ke proposal yang saya buat.

Adapun contoh Anda, Anda tidak dapat memanggil fungsi di x. Tetapi Anda masih dapat mengoperasikan irisan tersebut seperti halnya irisan lain yang sangat berguna dengan sendirinya. Juga tidak yakin apa fungsi di dalam fungsi itu... mungkin Anda bermaksud menetapkan ke var?

@aarondl
Terima kasih, saya memperbaiki sintaksnya, namun saya pikir artinya masih jelas.

Contoh yang saya berikan di atas menggunakan polimorfisme parametrik dan antarmuka untuk mencapai beberapa tingkat pemrograman generik, namun kurangnya pengiriman ganda selalu akan menempatkan batas pada tingkat umum yang dapat dicapai. Karena itu tampaknya Go tidak akan menyediakan fitur yang saya cari dalam suatu bahasa, itu tidak berarti saya tidak dapat menggunakan Go untuk beberapa tugas, dan ternyata saya sudah melakukannya dan berfungsi dengan baik, bahkan jika saya sudah memilikinya untuk memotong-dan-tempel kode yang benar-benar hanya membutuhkan satu definisi. Saya hanya berharap di masa depan jika kode itu perlu diubah, pengembang dapat menemukan semua contoh yang ditempelkan.

Saya kemudian dalam dua pikiran, apakah genaralitas terbatas mungkin tanpa perubahan besar pada bahasa adalah ide yang bagus, mengingat kerumitan yang akan ditambahkannya. Mungkin Go lebih baik tetap sederhana, dan orang dapat menambahkan makro seperti pra-pemrosesan, atau bahasa lain yang dikompilasi ke Go, untuk menyediakan fitur ini? Di sisi lain, menambahkan polimorfisme parametrik akan menjadi langkah pertama yang baik. Mengizinkan parameter tipe tersebut dibatasi akan menjadi langkah selanjutnya yang baik. Kemudian Anda dapat menambahkan parameter tipe terkait ke antarmuka, dan Anda akan memiliki sesuatu yang cukup umum, tetapi itu mungkin sejauh yang Anda bisa dapatkan tanpa pengiriman ganda. Dengan memisahkan menjadi fitur-fitur kecil yang terpisah, saya kira Anda akan meningkatkan peluang agar mereka diterima?

@keean
Apakah multi-pengiriman yang diperlukan? Sangat sedikit bahasa yang mendukungnya. Bahkan C++ tidak mendukungnya. C# agak mendukungnya melalui dynamic tetapi saya tidak pernah menggunakannya dalam praktik dan kata kunci secara umum sangat jarang dalam kode nyata. Contoh yang saya ingat berurusan dengan sesuatu seperti parsing JSON, bukan menulis obat generik.

Apakah multi-pengiriman yang diperlukan?

IMHO, saya pikir @keean berbicara tentang pengiriman ganda statis yang disediakan oleh kelas tipe/antarmuka.
Ini bahkan disediakan dalam C++ dengan metode overloading (saya tidak tahu untuk C#)

Yang Anda maksud adalah pengiriman ganda dinamis yang cukup rumit dalam bahasa statis tanpa tipe serikat pekerja. Bahasa dinamis menghindari masalah ini dengan menghilangkan pemeriksaan tipe statis (inferensi tipe parsial untuk bahasa dinamis, sama untuk Tipe "Dinamis" C#).

Bisakah suatu tipe disediakan sebagai "hanya" parameter?

func Append(t, t2 type, arr []t, value t2) []t {
    v := t(value) // conversion
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

@Inuart menulis:

Bisakah suatu tipe disediakan sebagai "hanya" parameter?

Dipertanyakan sejauh mana hal ini mungkin atau diinginkan dalam go

Apa yang Anda inginkan dapat dicapai sebagai gantinya jika batasan umum didukung:

func Append(arr []t, value s) []t  requires Convertible<s,t>{
    v := t(value) // conversion
    return append(arr, v)
}

var arr []int64
v := 0.5

arr = Append(arr, v)

Ini juga harus dimungkinkan dengan batasan:

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

Untuk apa nilainya, bahasa Genus kami mendukung banyak pengiriman. Model untuk batasan dapat menyediakan beberapa implementasi yang dikirim ke.

Saya mengerti bahwa notasi Convertible<s,t> diperlukan untuk keamanan waktu kompilasi, tetapi mungkin dapat diturunkan menjadi pemeriksaan runtime

func Append(t, t2 type, arr []t, value t2) []t {
    v, ok := t(value) // conversion
    if !ok {
        panic(...) // or return an err
    }
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

Tapi ini lebih mirip gula sintaks untuk reflect .

@Inuart intinya adalah kompiler dapat memeriksa tipe yang mengimplementasikan kelas tipe pada waktu kompilasi, sehingga pemeriksaan runtime tidak diperlukan. Manfaatnya adalah kinerja yang lebih baik (disebut abstraksi biaya nol). Jika ini adalah pemeriksaan runtime, Anda juga dapat menggunakan reflect .

@creker

Apakah multi-pengiriman yang diperlukan?

Saya terlalu memikirkan hal ini. Di satu sisi pengiriman ganda (dengan kelas tipe mutli-parameter) tidak berfungsi dengan baik dengan eksistensial, apa yang 'Go' sebut 'nilai antarmuka'.

type Equals<T> interface {eq(right T) bool}
(left I) eq(right I) bool {return left == right}
(left I) eq(right F) bool {return false}
(left F) eq(right I) bool {return false}
(left F) eq(right F) bool {return left == right}

func main() {
    x := []Equals<?>{I{2}, F{4.0}, I{2}, F{4.0}}
}

Kami tidak dapat mendefinisikan irisan Equals karena kami tidak memiliki cara untuk menunjukkan bahwa parameter sebelah kanan berasal dari koleksi yang sama. Kami bahkan tidak dapat melakukan ini di Haskell:

data Equals = forall a . IEquals a a => Equals a

Ini tidak baik karena hanya memungkinkan suatu tipe dibandingkan dengan dirinya sendiri

data Equals = forall a b . IEquals a b => Equals a

Ini tidak baik karena kita tidak memiliki cara untuk membatasi b menjadi eksistensial lain dalam koleksi yang sama dengan a (jika a bahkan ada dalam koleksi).

Namun itu membuatnya sangat mudah untuk diperluas dengan tipe baru:

(left K) eq(right I) bool {return false}
(left K) eq(right F) bool {return false}
(left I) eq(right K) bool {return false}
(left F) eq(right K) bool {return false}
(left K) eq(right K) bool {return left == right}

Dan ini akan lebih ringkas dengan instance atau spesialisasi default.

Di sisi lain kita dapat menulis ulang ini di 'Go' yang berfungsi sekarang:

package main

type I struct {v int}
type F struct {v float32}

type EqualsInt interface {eqInt(left I) bool}
func (right I) eqInt (left I) bool {return left == right}
func (right F) eqInt (left I) bool {return false}

type EqualsFloat interface {eqFloat(left F) bool}
func (right I) eqFloat (left F) bool {return false}
func (right F) eqFloat (left F) bool {return left == right}

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

type EqualsLeft interface {eq(right EqualsRight) bool}
func (left I) eq (right EqualsRight) bool {return right.eqInt(left)}
func (left F) eq (right EqualsRight) bool {return right.eqFloat(left)}

type Equals interface {
    EqualsLeft
    EqualsRight
}

func main() {
    x := []Equals{I{2}, F{4.0}, I{2}, F{4.0}}
    println(x[0].eq(x[1]))
    println(x[1].eq(x[0]))
    println(x[0].eq(x[2]))
    println(x[1].eq(x[3]))
}

Ini bekerja dengan baik dengan eksistensial (nilai antarmuka), namun jauh lebih kompleks, lebih sulit untuk melihat apa yang terjadi dan bagaimana cara kerjanya, dan memiliki batasan besar bahwa kita memerlukan satu antarmuka per jenis dan kita perlu membuat kode keras yang dapat diterima jenis sisi kanan seperti ini:

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

Yang berarti kita harus memodifikasi sumber pustaka untuk menambahkan tipe baru karena antarmuka EqualsRight tidak dapat diperluas.

Jadi tanpa antarmuka multi-parameter, kami tidak dapat mendefinisikan operator generik yang dapat diperluas seperti kesetaraan. Dengan antarmuka multi-parameter, eksistensial (nilai antarmuka) menjadi bermasalah.

Masalah utama saya dengan banyak sintaks yang diusulkan (sintaks?) Blah[E] adalah bahwa tipe dasarnya tidak menunjukkan informasi apa pun tentang berisi obat generik.

Misalnya:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

Ini berarti kita mendeklarasikan tipe baru yang menambahkan lebih banyak informasi ke tipe yang mendasarinya. Bukankah maksud dari deklarasi type untuk mendefinisikan nama berdasarkan tipe lain?

Saya akan mengusulkan sintaks lebih di sepanjang baris

type Comparer interface[C] {
    Compare(other C) bool
}

Ini berarti bahwa sebenarnya Comparer hanyalah tipe berdasarkan interface[C] { ... } , dan interface[C] { ... } tentu saja adalah tipe yang terpisah dari interface { ... } . Ini memungkinkan Anda untuk menggunakan antarmuka generik tanpa menamainya, jika Anda mau (yang diizinkan dengan antarmuka normal). Saya pikir solusi ini sedikit lebih intuitif dan bekerja dengan baik dengan sistem tipe Go, meskipun tolong perbaiki saya jika saya salah.

Catatan: Mendeklarasikan tipe generik hanya diperbolehkan pada antarmuka, struct, dan fungsi dengan sintaks berikut:
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

Kemudian "menerapkan" obat generik akan memiliki sintaks berikut:
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

Dan dengan beberapa contoh untuk membuatnya sedikit lebih jelas:

Antarmuka

package add

type Adder interface[E] {
    // Adds the element and returns the size
    Add(elem E) int
}

// Adds the integer 5 to any implementation of Adder[int].
func AddFiveTo(a Adder[int]) int {
    return a.Add(5)
}

Struktur

package heap

type List struct[T] {
    slice []T
}

func (l *List) Add(elem T) { // T is a type defined by the receiver
    l.slice = append(l.slice, elem)
}

Fungsi

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

Ini sebagai tanggapan terhadap draf kontrak Go2 dan saya akan menggunakan sintaksnya, tetapi saya mempostingnya di sini karena ini berlaku untuk proposal apa pun untuk polimorfisme parametrik.

Penyematan parameter tipe tidak boleh diizinkan.

Mempertimbangkan

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

untuk beberapa jenis arbitrer R dan beberapa kontrak arbitrer C yang tidak mengandung Foo() .

T akan memiliki semua pemilih yang diperlukan oleh C tetapi instantiasi tertentu T mungkin juga memiliki pemilih lain yang sewenang-wenang, termasuk Foo .

Katakanlah Bar adalah struct, dapat diterima di bawah C , yang memiliki bidang bernama Foo .

X(Bar) bisa menjadi instantiasi ilegal. Tanpa cara untuk menentukan kontrak bahwa suatu tipe tidak memiliki pemilih, ini harus menjadi properti yang disimpulkan.

Metode X(Bar) dapat terus menyelesaikan referensi ke Foo sebagai X(Bar).R.Foo . Hal ini memungkinkan penulisan tipe generik tetapi dapat membingungkan pembaca yang tidak terbiasa dengan nitpickery aturan resolusi. Di luar metode X , pemilih akan tetap ambigu, sementara interface { Foo() } tidak bergantung pada parameter X , beberapa contoh dari X akan tidak memuaskannya.

Melarang penyematan parameter tipe lebih sederhana.

(Namun, jika ini diizinkan, nama bidang akan menjadi T untuk alasan yang sama dengan nama bidang dari S tertanam yang didefinisikan sebagai type S = io.Reader adalah S dan bukan Reader tetapi juga karena tipe yang membuat instance T tidak perlu memiliki nama sama sekali.)

@jimmyfrasche Saya pikir bidang yang disematkan dengan tipe generik cukup berguna sehingga akan baik untuk mengizinkannya, bahkan jika mungkin ada sedikit kecanggungan di beberapa tempat. Saran saya adalah mengasumsikan dalam semua kode generik bahwa tipe yang disematkan telah mendefinisikan semua bidang dan metode yang mungkin di setiap tingkat yang memungkinkan, sehingga dalam kode generik semua metode yang disematkan dan bidang tipe non-generik dihapus.

Jadi diberikan:

type R struct(type T) {
    io.Reader
    T
}

metode pada R tidak akan dapat memanggil Read on R tanpa mengarahkan melalui Reader. Sebagai contoh:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

Satu-satunya sisi buruk yang dapat saya lihat dari ini adalah bahwa tipe dinamis mungkin berisi lebih banyak anggota daripada tipe statis. Sebagai contoh:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

Satu-satunya sisi buruk yang dapat saya lihat dari ini adalah bahwa tipe dinamis mungkin berisi lebih banyak anggota daripada tipe statis.

Ini adalah kasus dengan parameter tipe secara langsung, jadi saya pikir itu juga harus baik-baik saja dengan tipe parametrik. Saya pikir solusi untuk masalah yang disajikan @jimmyfrasche mungkin adalah dengan meletakkan set metode yang diinginkan dari tipe parameter dalam kontrak.

contract C(t T) {
  interface { Foo() } (X(T){})
  // ...
}

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

Ini akan memungkinkan Foo dipanggil pada X secara langsung. Tentu saja, ini akan bertentangan dengan aturan "tidak ada nama lokal dalam kontrak"...

@stevenblenkinsop Hmm, itu mungkin, jika canggung, untuk melakukannya tanpa mengacu pada X

contract C(t T) {
  struct{ R; T }{}.Foo
}

C masih terikat pada implementasi X meskipun sedikit lebih longgar.

Jika Anda tidak melakukan itu, dan Anda menulis

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

apakah itu mengkompilasi? Itu tidak akan di bawah aturan @rogpeppe yang sepertinya perlu diadopsi juga ketika Anda tidak membuat jaminan dalam kontrak. Tetapi apakah itu hanya berlaku ketika Anda menyematkan argumen tipe tanpa kontrak yang memadai atau untuk semua penyematan?

Akan lebih mudah untuk melarangnya.

Saya mulai mengerjakan proposal ini sebelum draft Go2 diumumkan.

Saya siap untuk menghapus milik saya dengan senang hati ketika saya melihat pengumumannya, tetapi saya masih tidak nyaman dengan kerumitan drafnya, jadi saya menyelesaikan milik saya. Ini kurang kuat tetapi lebih sederhana. Jika tidak ada yang lain, mungkin ada beberapa bagian yang layak untuk dicuri.

Ini memperluas sintaks proposal @ianlancetaylor sebelumnya, karena itulah yang tersedia ketika saya mulai. Itu tidak mendasar. Itu bisa diganti dengan sintaks (type T dll atau sesuatu yang setara. Saya hanya membutuhkan beberapa sintaks sebagai notasi untuk semantik.

Itu terletak di sini: https://Gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

Aturannya adalah bahwa metode apa pun yang dipromosikan dari kedalaman yang lebih besar daripada parameter tipe yang disematkan tidak dapat dipanggil kecuali (1) identitas argumen tipe diketahui atau (2) metode tersebut dinyatakan dapat dipanggil di luar ketik dengan kontrak yang membatasi parameter tipe. Kompiler juga dapat menentukan batas atas dan bawah pada kedalaman yang harus dimiliki metode yang dipromosikan dalam tipe luar O , dan menggunakannya untuk menentukan apakah metode tersebut dapat dipanggil pada tipe yang menyematkan O , yaitu apakah ada potensi konflik dengan metode lain yang dipromosikan atau tidak. Hal serupa juga akan berlaku untuk parameter tipe apa pun yang dinyatakan memiliki metode yang dapat dipanggil, di mana rentang kedalaman metode dalam parameter tipe adalah [0, inf).

Menyematkan parameter jenis sepertinya terlalu berguna untuk melarangnya sepenuhnya. Untuk satu hal, ini memungkinkan komposisi transparan, yang tidak diizinkan oleh pola antarmuka penyematan.

Saya juga menemukan potensi penggunaan dalam mendefinisikan kontrak. Jika Anda ingin dapat menerima nilai tipe T (yang bisa berupa tipe pointer) yang mungkin memiliki metode yang ditentukan pada *T , dan Anda ingin dapat memasukkan nilai itu sebuah antarmuka, Anda tidak perlu memasukkan T di antarmuka, karena metodenya mungkin ada di *T , dan Anda tidak dapat serta-merta memasukkan *T di antarmuka karena T mungkin sendiri merupakan tipe pointer (dan dengan demikian *T mungkin memiliki kumpulan metode kosong). Namun, jika Anda memiliki pembungkus seperti

type Wrapper(type T) { T }

Anda dapat menempatkan *Wrapper(T) di antarmuka dalam semua kasus jika kontrak Anda mengatakan itu memenuhi antarmuka.

Tidak bisakah kamu melakukannya?

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

Saya mencoba menangani kasus di mana seseorang menelepon

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

Ini tidak akan berhasil karena S tidak dapat dikonversi ke Interface , hanya *S yang dapat.

Jelas, jawabannya mungkin "jangan lakukan itu". Namun, proposal kontrak menjelaskan kontrak seperti:

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S akan memenuhi kontrak ini karena pengalamatan otomatis, seperti halnya *S . Apa yang saya coba atasi adalah kesenjangan kemampuan antara pemanggilan metode dan konversi antarmuka dalam kontrak.

Bagaimanapun, ini sedikit bersinggungan, menunjukkan satu potensi penggunaan untuk menyematkan parameter tipe.

Penyematan ulang, saya pikir "dapat menyematkan dalam struct" adalah batasan lain yang harus ditangkap oleh kontrak jika diizinkan.

Mempertimbangkan:

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

@bcmills menyematkan tipe dengan penyeleksi yang ambigu diperbolehkan jadi saya tidak yakin bagaimana kontrak itu seharusnya ditafsirkan.

Bagaimanapun, jika Anda hanya menyematkan jenis yang diketahui, tidak apa-apa. Jika Anda hanya menyematkan parameter tipe, tidak apa-apa. Satu-satunya kasus yang menjadi aneh adalah ketika Anda menyematkan satu atau lebih tipe yang diketahui DAN satu atau lebih parameter tipe dan kemudian hanya ketika penyeleksi dari tipe yang diketahui dan argumen tipe tidak terputus

@bcmills menyematkan tipe dengan penyeleksi yang ambigu diperbolehkan jadi saya tidak yakin bagaimana kontrak itu seharusnya ditafsirkan.

Hmm, poin yang bagus. Saya kehilangan satu kendala lagi untuk memicu kesalahan.

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

https://play.golang.org/p/3wSg5aRjcQc

Itu membutuhkan salah satu dari X atau Y tetapi tidak keduanya menjadi io.Reader . Sangat menarik bahwa sistem kontrak cukup ekspresif untuk memungkinkan itu. Saya senang saya tidak perlu mencari tahu aturan inferensi tipe untuk binatang seperti itu.

Tapi bukan itu masalahnya.

Saat itulah Anda melakukannya

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

Itu seharusnya gagal dikompilasi karena T dapat memiliki pemilih Read kecuali C memiliki

struct{ io.Reader; T }.Read

Tapi lalu apa aturannya ketika C tidak memastikan set pemilih terputus-putus dan S tidak mereferensikan pemilih? Apakah mungkin untuk setiap instantiasi S untuk memenuhi antarmuka kecuali untuk tipe yang membuat pemilih ambigu?

Apakah mungkin untuk setiap instantiasi S untuk memenuhi antarmuka kecuali untuk tipe yang membuat pemilih ambigu?

Ya, sepertinya memang begitu. Saya ingin tahu apakah itu menyiratkan sesuatu yang lebih dalam ...

Saya belum dapat membangun sesuatu yang sangat buruk, tetapi asimetrinya cukup tidak menyenangkan dan membuat saya merasa tidak nyaman:

type I interface { /* ... */ }
a := G(A) // ok, A satisfies contract
var _ I = a // ok, no selector overlap
b := G(B) // ok, B satisfies contract
var _ = b // error, selector overlap

Saya khawatir tentang pesan kesalahan ketika G0(B) menggunakan G1(B) menggunakan . . . menggunakan Gn(B) dan Gn adalah salah satu yang menyebabkan kesalahan. . . .

FTR, Anda tidak perlu melalui masalah pemilih ambigu untuk memicu kesalahan tipe dengan penyematan.

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

Anda berasumsi bahwa nama bidang yang disematkan didasarkan pada tipe argumen, sedangkan kemungkinan besar itu adalah nama dari parameter tipe yang disematkan. Ini seperti saat Anda menyematkan alias tipe dan nama bidangnya adalah alias, bukan nama alias tipenya.

Ini sebenarnya ditentukan dalam desain draf di bagian tentang tipe berparameter :

Ketika tipe berparameter adalah struct, dan parameter tipe disematkan sebagai bidang dalam struct, nama bidang adalah nama parameter tipe, bukan nama argumen tipe.

type Lockable(type T) struct {
    T
    mu sync.Mutex
}

func (l *Lockable(T)) Get() T {
    l.mu.Lock()
    defer l.mu.Unlock()
    return l.T
}

(Catatan: ini bekerja dengan buruk jika Anda menulis Lockable(X) dalam deklarasi metode: haruskah metode mengembalikan lT atau lX? Mungkin kita sebaiknya melarang penyematan parameter tipe dalam sebuah struct.)

Saya hanya duduk kembali di sini di sela-sela dan mengamati. Tapi juga menjadi sedikit khawatir.

Satu hal yang saya tidak malu untuk mengatakan adalah bahwa 90% dari diskusi ini di atas kepala saya.

Tampaknya 20 tahun mencari nafkah dari menulis perangkat lunak tanpa mengetahui apa itu generik, atau polimorfisme parametrik, tidak menghentikan saya untuk menyelesaikan pekerjaan.

Sayangnya saya hanya meluangkan waktu sekitar setahun yang lalu untuk belajar Go. Saya membuat asumsi yang salah bahwa itu adalah kurva belajar yang curam, dan akan memakan waktu terlalu lama untuk menjadi produktif.

Saya tidak mungkin lebih salah.

Saya cukup belajar Go untuk membangun layanan mikro yang benar-benar menghancurkan layanan node.js yang mengalami masalah kinerja dalam waktu kurang dari seminggu.

Ironisnya, saya hanya bermain-main. Saya tidak terlalu serius untuk menaklukkan dunia dengan Go.

Namun, dalam beberapa jam, saya mendapati diri saya duduk dari postur saya yang bungkuk, seperti berada di tepi kursi saya menonton film thriller aksi. API yang saya bangun muncul begitu cepat. Saya menyadari bahwa ini memang bahasa yang layak untuk menginvestasikan waktu berharga saya, karena itu jelas sangat pragmatis dalam desainnya.

Dan itulah hal yang saya sukai dari Go. Ini sangat cepat..... Untuk belajar. Kita semua di sini tahu kemampuan kinerjanya. Tetapi kecepatan mempelajarinya tidak tertandingi oleh 8 bahasa lain yang telah saya pelajari selama bertahun-tahun.

Sejak itu saya menyanyikan pujian Go, dan membuat 4 Dev lagi jatuh cinta padanya. Saya hanya duduk bersama mereka selama beberapa jam dan membangun sesuatu. Hasil berbicara sendiri.

Kesederhanaan, dan kecepatan untuk belajar. Ini adalah fitur pembunuh sebenarnya dari bahasa tersebut.

Bahasa pemrograman yang membutuhkan pembelajaran keras selama berbulan-bulan sering kali tidak mempertahankan pengembang yang ingin mereka tarik. Kami memiliki pekerjaan yang harus dilakukan, dan majikan yang ingin melihat kemajuan setiap hari (terima kasih tangkas, hargai itu)

Jadi, ada dua hal yang saya harap dapat dipertimbangkan oleh tim Go:

1) Masalah sehari-hari apa yang ingin kita pecahkan?

Sepertinya saya tidak dapat menemukan contoh dunia nyata, dengan penghenti acara yang akan diselesaikan oleh obat generik, atau apa pun namanya.

Contoh gaya buku masak dari tugas sehari-hari yang bermasalah, dengan contoh bagaimana tugas tersebut dapat ditingkatkan dengan proposal perubahan bahasa ini.

2) Tetap sederhana, seperti semua fitur hebat lainnya dari Go

Ada beberapa komentar yang sangat cerdas di sini. Tetapi saya yakin bahwa sebagian besar pengembang yang menggunakan Go sehari-hari untuk pemrograman umum seperti saya, sangat senang dan produktif dengan hal-hal sebagaimana adanya.

Mungkin argumen kompiler untuk mengaktifkan fitur-fitur canggih seperti itu? '--keras'

Saya akan sangat sedih jika kami berdampak negatif pada kinerja kompiler. Katakan saja

Dan itulah hal yang saya sukai dari Go. Ini sangat cepat..... Untuk belajar. Kita semua di sini tahu kemampuan kinerjanya. Tetapi kecepatan mempelajarinya tidak tertandingi oleh 8 bahasa lain yang telah saya pelajari selama bertahun-tahun.

Saya sangat setuju. Kombinasi kekuatan dengan kesederhanaan dalam bahasa yang dikompilasi sepenuhnya adalah sesuatu yang benar-benar unik. Saya jelas tidak ingin Go kehilangan itu, dan sebanyak saya menginginkan obat generik, saya pikir mereka tidak layak dengan biaya itu. Saya tidak berpikir itu perlu untuk kehilangan itu, meskipun.

Sepertinya saya tidak dapat menemukan contoh dunia nyata, dengan penghenti acara yang akan diselesaikan oleh obat generik, atau apa pun namanya.

Saya memiliki dua kasus penggunaan utama untuk obat generik: Penghapusan boilerplate tipe-safe dari struktur data yang kompleks, seperti pohon biner, set, dan sync.Map , dan kemampuan untuk menulis _compile-time_ type-safe fungsi yang beroperasi berdasarkan murni pada fungsionalitas argumen mereka, daripada tata letak mereka dalam memori. Ada beberapa hal yang lebih menarik yang saya tidak keberatan bisa melakukannya, tapi saya tidak keberatan _not_ bisa melakukannya jika tidak mungkin menambahkan dukungan untuk mereka tanpa sepenuhnya melanggar kesederhanaan bahasa.

Sejujurnya, sudah ada fitur dalam bahasa yang cukup kasar. Alasan utama mengapa mereka _tidak_ sering disalahgunakan, menurut saya, adalah budaya Go menulis kode 'idiomatik', dikombinasikan dengan perpustakaan standar yang menyediakan contoh kode yang bersih dan mudah ditemukan, untuk sebagian besar. Mendapatkan penggunaan obat generik yang baik ke dalam pustaka standar harus menjadi prioritas saat diterapkan.

@camstuart

Sepertinya saya tidak dapat menemukan contoh dunia nyata, dengan penghenti acara yang akan diselesaikan oleh obat generik, atau apa pun namanya.

Generik sehingga Anda tidak perlu menulis kode sendiri. Jadi Anda tidak perlu lagi mengimplementasikan daftar tertaut, pohon biner, deque, atau antrian prioritas lagi. Anda tidak perlu mengimplementasikan algoritme pengurutan, algoritme partisi, atau algoritme rotasi, dll. Struktur data menjadi penyusun koleksi standar (Peta Daftar misalnya), dan pemrosesan menjadi algoritme standar penyusunan (saya perlu mengurutkan data, partisi, dan memutar). Jika Anda dapat menggunakan kembali komponen-komponen ini, tingkat kesalahan akan turun, karena setiap kali Anda mengimplementasikan kembali Antrian Prioritas, atau algoritme partisi, ada kemungkinan Anda salah dan menimbulkan bug.

Generik berarti Anda menulis lebih sedikit kode, dan menggunakan kembali lebih banyak. Artinya, fungsi perpustakaan standar yang terpelihara dengan baik dan tipe data abstrak dapat digunakan dalam lebih banyak situasi, jadi Anda tidak perlu menulis sendiri.

Lebih baik lagi, semua itu secara teknis dapat dilakukan di Go sekarang, tetapi hanya dengan kehilangan hampir total waktu kompilasi-keamanan tipe _and_ dengan beberapa, berpotensi besar, overhead runtime. Obat generik memungkinkan Anda melakukannya tanpa salah satu dari kerugian tersebut.

Implementasi fungsi umum:

/*

* "generic" is a KIND of types, just like "struct", "map", "interface", etc...
* "T" is a generic type (a type of kind generic).
* var t = T{int} is a value of type T, values of generic types looks like a "normal" type

*/

type T generic {
    int
    float64
    string
}

func Sum(a, b T{}) T{} {
    return a + b
}

Pemanggil fungsi:

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

Implementasi struktur umum:

type ItemT generic {
    interface{}
}

type List struct {
    l []ItemT{}
}

func NewList(t ItemT) *List {
    l := make([]t)
    return &List{l}
}

func (p *List) Push(item ItemT{}) {
    p.l = append(p.l, item)
}

Penelepon:

list := NewList(ItemT{int})
list.Push(42)

Sebagai seseorang yang baru belajar Swift dan tidak menyukainya, tetapi dengan banyak pengalaman dalam bahasa lain seperti Go, C, Java, dll; Saya benar-benar percaya bahwa obat generik (atau templating, atau apa pun yang Anda ingin menyebutnya) bukanlah hal yang baik untuk ditambahkan ke bahasa Go.

Mungkin saya hanya lebih berpengalaman dengan versi Go saat ini, tetapi bagi saya ini terasa seperti regresi ke C++ karena lebih sulit untuk memahami kode yang ditulis orang lain. Placeholder T klasik untuk tipe membuatnya sangat sulit untuk memahami apa yang coba dilakukan oleh suatu fungsi.

Saya tahu ini adalah permintaan fitur yang populer sehingga saya dapat menanganinya jika itu mendarat, tetapi saya ingin menambahkan 2 sen saya (pendapat).

@jlubawy
Apakah Anda tahu cara lain agar saya tidak perlu mengimplementasikan daftar tertaut atau algoritme quicksort? Seperti yang ditunjukkan Alexander Stepanov, sebagian besar pemrogram tidak dapat dengan benar mendefinisikan fungsi "min" dan "maks" jadi apa harapan kita untuk mengimplementasikan algoritma yang lebih kompleks dengan benar tanpa banyak waktu debugging. Saya lebih suka menarik versi standar dari algoritma ini dari perpustakaan dan hanya berlaku untuk tipe yang saya miliki. Apa alternatif yang ada?

@jlubawy

atau templating, atau apa pun yang Anda ingin menyebutnya

Semuanya tergantung pada implementasinya. jika kita berbicara tentang template C++ maka ya, mereka sulit untuk dipahami secara umum. Bahkan menulisnya pun sulit. Di sisi lain, jika kita menggunakan obat generik C# maka itu sama sekali berbeda. Konsepnya sendiri tidak menjadi masalah di sini.

Jika Anda belum tahu, Tim Go telah mengumumkan draf Go 2.0:
https://golang.org/s/go2designs

Ada draf untuk desain Generik di Go 2.0 (kontrak). Anda mungkin ingin melihat dan memberikan umpan balik tentang Wiki mereka.

Ini bagian yang relevan:

Obat generik

• Ringkasan
• Desain draf
• Halaman umpan balik Wiki

Setelah membaca draft, saya bertanya:

Mengapa

T: Dapat ditambahkan

berarti "tipe T yang mengimplementasikan kontrak Addable"? Mengapa menambahkan yang baru?
konsep ketika kita sudah memiliki INTERFACES untuk itu? Tugas antarmuka adalah
memeriksa waktu pembuatan, jadi kami sudah memiliki sarana untuk tidak membutuhkannya
konsep tambahan di sini. Kita dapat menggunakan istilah ini untuk mengatakan sesuatu seperti: Any
ketik T mengimplementasikan antarmuka Addable. Selain itu, T:_ atau T:Any
(menjadi kata kunci khusus apa pun atau alias antarmuka bawaan{}) akan melakukannya
Trik-nya.

Hanya saja saya tidak tahu mengapa menerapkan kembali sebagian besar hal-hal seperti itu. Tidak ada
akal dan AKAN menjadi berlebihan (karena berlebihan adalah penanganan baru kesalahan wrt
penanganan panik).

14-09-2018 6:15 GMT-05:00 Koala Yeung [email protected] :

Jika Anda belum tahu, Tim Go telah mengumumkan draf Go 2.0:
https://golang.org/s/go2designs

Ada draf untuk desain Generik di Go 2.0 (kontrak). Anda mungkin ingin
untuk melihat dan memberikan umpan balik
https://github.com/golang/go/wiki/Go2GenericsFeedback di Wiki mereka
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Ini bagian yang relevan:

Obat generik

• Ringkasan
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Desain draf] (https://go.googlesource.com/proposal/+/master/design/
  go2draft-contracts.md)
• Halaman umpan balik Wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Ini adalah tes untuk tanda tangan email yang akan digunakan di TripleMint

Sunting: "[...] akan melakukan trik JIKA ANDA TIDAK MEMBUTUHKAN PERSYARATAN TERTENTU
JENIS ARGUMEN".

17-09-2018 11:10 GMT-05:00 Luis Masuelli [email protected] :

Setelah membaca draft, saya bertanya:

Mengapa

T: Dapat ditambahkan

berarti "tipe T yang mengimplementasikan kontrak Addable"? Mengapa menambahkan yang baru?
konsep ketika kita sudah memiliki INTERFACES untuk itu? Tugas antarmuka adalah
memeriksa waktu pembuatan, jadi kami sudah memiliki sarana untuk tidak membutuhkannya
konsep tambahan di sini. Kita dapat menggunakan istilah ini untuk mengatakan sesuatu seperti: Any
ketik T mengimplementasikan antarmuka Addable. Selain itu, T:_ atau T:Any
(menjadi kata kunci khusus apa pun atau alias antarmuka bawaan{}) akan melakukannya
Trik-nya.

Hanya saja saya tidak tahu mengapa menerapkan kembali sebagian besar hal-hal seperti itu. Tidak ada
akal dan AKAN menjadi berlebihan (karena berlebihan adalah penanganan baru kesalahan wrt
penanganan panik).

14-09-2018 6:15 GMT-05:00 Koala Yeung [email protected] :

Jika Anda belum tahu, Tim Go telah mengumumkan draf Go 2.0:
https://golang.org/s/go2designs

Ada draf untuk desain Generik di Go 2.0 (kontrak). Kamu boleh
mau lihat dan kasih feedback
https://github.com/golang/go/wiki/Go2GenericsFeedback di Wiki mereka
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Ini bagian yang relevan:

Obat generik

• Ringkasan
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Desain draf] (https://go.googlesource.com/p
  roposal/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• Halaman umpan balik Wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Ini adalah tes untuk tanda tangan email yang akan digunakan di TripleMint

--
Ini adalah tes untuk tanda tangan email yang akan digunakan di TripleMint

@luismasuelli-jobsity Jika saya membaca sejarah implementasi generik di Go dengan benar, maka sepertinya alasan untuk memperkenalkan Kontrak adalah karena mereka tidak ingin operator kelebihan beban di Antarmuka.

Proposal sebelumnya yang akhirnya ditolak menggunakan antarmuka untuk membatasi polimorfisme parametrik, tetapi tampaknya telah ditolak karena Anda tidak dapat menggunakan operator umum seperti '+' dalam fungsi tersebut karena tidak dapat ditentukan dalam antarmuka. Kontrak memungkinkan Anda untuk menulis t == t atau t + t sehingga Anda dapat menunjukkan jenis harus mendukung kesetaraan atau penambahan dll.

Sunting: Juga Go tidak mendukung beberapa antarmuka parameter tipe, jadi Go telah memisahkan kelas tipe menjadi dua hal yang terpisah, Kontrak yang menghubungkan parameter tipe fungsi satu sama lain, dan antarmuka yang menyediakan metode. Apa yang hilang adalah kemampuan untuk memilih implementasi kelas tipe berdasarkan beberapa tipe. Bisa dibilang lebih sederhana jika Anda hanya perlu menggunakan antarmuka atau kontrak, tetapi lebih rumit jika Anda perlu menggunakan keduanya secara bersamaan.

Mengapa T:Addable berarti "tipe T yang mengimplementasikan kontrak Dapat Ditambahkan"?

Sebenarnya bukan itu artinya; itu hanya terlihat seperti itu untuk satu jenis argumen. Di bagian lain dalam draf itu membuat komentar bahwa Anda hanya dapat memiliki satu kontrak per fungsi, dan di sinilah perbedaan utama masuk. Kontrak sebenarnya adalah pernyataan tentang jenis fungsi, bukan hanya jenis secara independen. Misalnya, jika Anda memiliki

func Example(type K, V someContract)(k K, v V) V

Anda dapat melakukan sesuatu seperti

contract someContract(k K, v V) {
  k.someMethod(v)
}

Ini sangat menyederhanakan koordinasi beberapa jenis tanpa harus secara berlebihan menentukan jenis dalam tanda tangan fungsi. Ingat, mereka mencoba menghindari 'pola umum yang berulang secara aneh'. Misalnya, fungsi yang sama dengan antarmuka berparameter yang digunakan untuk membatasi tipe akan menjadi seperti

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

Ini agak canggung. Sintaks kontrak memungkinkan Anda untuk tetap melakukan ini jika perlu, karena 'argumen' kontrak diisi secara otomatis oleh kompiler jika kontrak memiliki jumlah yang sama dengan fungsi yang mengetik parameter. Anda dapat menentukannya secara manual jika Anda mau, artinya Anda _bisa_ melakukan func Example(type K, V someContract(K, V))(k K, v V) V jika Anda benar-benar menginginkannya, meskipun itu tidak terlalu berguna dalam situasi ini.

Salah satu cara untuk memperjelas bahwa kontrak adalah tentang seluruh fungsi, bukan argumen individual, adalah dengan hanya mengaitkannya berdasarkan nama. Sebagai contoh,

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

akan sama seperti di atas. Kelemahannya, bagaimanapun, adalah bahwa kontrak tidak akan dapat digunakan kembali dan Anda kehilangan kemampuan untuk menentukan argumen kontrak secara manual.

Sunting: Untuk menunjukkan lebih lanjut mengapa mereka ingin menyelesaikan pola berulang yang aneh, pertimbangkan masalah jalur terpendek yang terus mereka rujuk. Dengan antarmuka berparameter, definisi akan terlihat seperti

type E(Node) interface {
  Nodes() []Node
}

type N(Edge) interface {
  Edges() (from, to Edge)
}

type Graph(type Node: N(Edge), Edge: E(Node)) struct { ... }
func New(type Node: N(Edge), Edge: E(Node))(nodes []Node) *Graph(Node, Edge) { ... }
func (*Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

Secara pribadi, saya lebih suka cara kontrak ditentukan untuk fungsi. Saya tidak _terlalu_ tertarik untuk hanya memiliki badan fungsi 'normal' sebagai spesifikasi kontrak yang sebenarnya, tetapi saya pikir banyak masalah potensial dapat diselesaikan dengan memperkenalkan semacam penyederhanaan seperti gofmt yang secara otomatis menyederhanakan kontrak untuk Anda, menghapus bagian asing. Kemudian Anda _bisa_ menyalin badan fungsi ke dalamnya, menyederhanakannya, dan memodifikasinya dari sana. Sayangnya, saya tidak yakin seberapa mungkin ini akan diterapkan.

Beberapa hal masih akan sedikit canggung untuk ditentukan, dan tumpang tindih yang tampak antara kontrak dan antarmuka masih tampak agak aneh.

Saya menemukan versi "CRTP" jauh lebih jelas, lebih eksplisit, dan lebih mudah untuk digunakan (tidak perlu membuat kontrak yang hanya ada untuk mendefinisikan hubungan antara kontrak yang sudah ada sebelumnya melalui serangkaian variabel). Diakui, itu bisa menjadi pengalaman bertahun-tahun dengan gagasan itu.

Klarifikasi. Dengan rancangan rancangan , kontrak dapat diterapkan baik fungsi maupun jenisnya .

"""
Bisa dibilang lebih sederhana jika Anda hanya perlu menggunakan antarmuka atau kontrak, tetapi lebih rumit jika Anda perlu menggunakan keduanya secara bersamaan.
"""

Selama mereka mengizinkan Anda, di dalam kontrak, mereferensikan satu atau lebih antarmuka (bukan hanya operator dan fungsi, sehingga memungkinkan KERING), masalah ini (dan klaim saya) akan terpecahkan. Ada kemungkinan saya salah membaca atau tidak sepenuhnya membaca hal-hal kontrak, dan juga kemungkinan fitur tersebut didukung dan saya tidak menyadarinya. Jika tidak, seharusnya begitu.

Tidak bisakah Anda melakukan hal berikut?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

Anda tidak dapat menggunakan antarmuka yang dideklarasikan di tempat lain karena batasan bahwa Anda tidak dapat mereferensikan pengidentifikasi dari paket yang sama dengan kontrak yang dideklarasikan, tetapi Anda dapat melakukan ini. Atau mereka bisa saja menghapus batasan itu; tampaknya agak sewenang-wenang.

@DeedleFake Tidak, karena semua jenis antarmuka dapat ditegaskan dengan tipe (dan kemudian berpotensi panik saat runtime, tetapi kontrak tidak dieksekusi). Tapi Anda bisa menggunakan tugas sebagai gantinya.