Memperbaiki loop `for` di Go 1.22

• Rilis Go 1.22 yang akan datang berencana memperbaiki kesalahan umum pada cakupan loop for yang telah menyebabkan masalah produksi di banyak perusahaan.
• Masalah ini terjadi ketika referensi ke variabel loop tetap dipertahankan setelah iterasi berakhir, sehingga variabel tersebut tanpa sengaja memiliki nilai baru.
• Masalah ini umum terjadi baik pada kode Go yang konkuren maupun yang tidak konkuren, dan sulit diidentifikasi serta diperbaiki karena rumitnya analisis apakah referensi ke variabel melampaui iterasi.
• Alat yang ada untuk mengidentifikasi kesalahan semacam ini sering menghasilkan false negative atau false positive, yang menyebabkan perubahan kode yang tidak perlu atau masalah yang terlewat.
• Perbaikan yang diusulkan di Go 1.22 akan mengubah loop for agar memiliki cakupan per-loop alih-alih cakupan per-iterasi, sehingga menghilangkan jenis kesalahan ini dan kebutuhan akan alat yang tidak akurat.
• Untuk menjaga kompatibilitas ke belakang, semantik baru ini hanya akan diterapkan pada paket yang termasuk dalam modul yang mendeklarasikan Go 1.22 atau lebih baru di file go.mod.
• Pengembang dapat mengontrol kapan semantik berubah untuk paket tertentu, dan kode yang ada akan terus berfungsi seperti sekarang.
• Go 1.21 menyertakan pratinjau perubahan cakupan yang dapat diaktifkan dengan menetapkan GOEXPERIMENT=loopvar di environment.
• Perubahan ini telah diuji secara luas di Google, dan tidak ada masalah yang dilaporkan pada kode produksi.
• Namun, beberapa pengujian yang gagal menguji hal yang semula ingin diuji karena masalah variabel loop memang perlu diperbaiki.
• Analyzer loopclosure di Go 1.21 telah ditingkatkan untuk membantu mengidentifikasi dan melaporkan jenis masalah ini, sehingga pengembang dapat bersiap menghadapi perubahan di Go 1.22.
• Informasi lebih lanjut tentang perubahan ini dapat ditemukan di dokumen desain dan FAQ.

[GN⁺]

Opini Hacker News

• Diskusi tentang masalah for loops di Go 1.22, dengan fokus pada penggunaan variabel loop yang keliru di dalam closure
• Masalah penggunaan variabel loop yang keliru di dalam closure bukanlah hal baru, dan dapat ditelusuri kembali hingga bahasa Lisp pada 1992
• Tim bahasa C# juga menghadapi masalah ini dan menerapkan perubahan besar di C# 5.0 untuk menyelesaikannya
• Go 1.21 tidak akan mengompilasi kode yang mendeklarasikan setelah Go 1.22, sehingga menjamin bahwa kode yang bergantung pada semantik baru tidak akan dikompilasi dengan semantik lama
• Ada kekhawatiran apakah perubahan ini akan merusak program yang bergantung pada perilaku saat ini
• Beberapa pengguna mempertanyakan bagaimana tepatnya ini akan bekerja jika sebuah package menetapkan 1.22 tetapi pengguna mengompilasinya dengan 1.18
• Ada juga pertanyaan tentang dampak perubahan ini terhadap alokasi memori dan performa loop
• Beberapa pengguna berbagi pengalaman mengalami masalah serupa di bahasa lain seperti Python
• Perubahan di Go 1.22 tampak seperti cara untuk menyelesaikan masalah sintaks bahasa, tetapi bagi sebagian pengguna terasa tidak intuitif karena perlu mengetahui versi yang dideklarasikan di satu file untuk memahami perilaku file lain