Satu penerokaan yang menarik dalam reka bentuk bahasa pengaturcaraan telah muncul, mencadangkan perubahan radikal daripada logik boolean tradisional dengan menggantikan nilai benar/salah dengan jenis optional. Konsep ini mencabar andaian asas tentang bagaimana bahasa pengaturcaraan mengendalikan logik bersyarat dan aliran kawalan.
Menggantikan Boolean dengan Options dan Results
Idea teras berpusat pada penghapusan jenis boolean sepenuhnya, sebaliknya menggunakan jenis Option<()>
atau Result<(), ()>
untuk mewakili apa yang secara tradisinya kita fikirkan sebagai benar dan salah. Dalam sistem ini, true
menjadi Ok(unit)
dan false
menjadi Err(unit)
. Pendekatan ini mengubah pernyataan bersyarat daripada penilaian boolean kepada operasi yang sama ada berjaya dengan nilai atau gagal dengan keadaan ralat.
Respons komuniti adalah bercampur-campur tetapi intelek yang ingin tahu. Ramai pembangun mengenali persamaan dengan konsep pengaturcaraan berfungsi sedia ada, terutamanya monad dalam Haskell. Seorang pengulas menyatakan persamaan dengan sistem truthy/falsy JavaScript, walaupun cadangan ini mengambil pendekatan yang lebih berstruktur melalui keselamatan jenis.
Kesetaraan Jenis dalam Sistem yang Dicadangkan:
bool
→Option<()>
true
→Ok(unit)
atauSome(())
false
→Err(unit)
atauNone
- jenis
test
→Result<(), ()>
(alias:??
)
Membayangkan Semula Operator Aliran Kawalan
Di bawah sistem ini, pernyataan if
tradisional menjadi operator binari yang mengembalikan nilai optional. Pernyataan if
tanpa klausa else
akan mengembalikan Option<T>
, manakala konstruk if-else
akan mengembalikan Option<T | U>
. Operator and
dan or
juga akan berfungsi pada jenis optional, mewujudkan sistem yang lebih seragam di mana semua logik bersyarat beroperasi pada struktur jenis asas yang sama.
Beberapa ahli komuniti menunjukkan hubungan dengan bahasa dan paradigma sedia ada. Pelaksanaan terarah matlamat Icon dan pelbagai dialek Lisp sudah melaksanakan konsep serupa, di mana nil
berfungsi sebagai satu-satunya nilai falsy dan segala yang lain dianggap truthy.
Tingkah Laku Operator dengan Jenis Pilihan:
None and X
→None
Some(x) and Y
→Some(y)
None or X
→X
Some(x) or Y
→Some(x)
not Err
→Ok
not Ok
→Err
Implikasi Praktikal dan Konteks Sejarah
Perbincangan mendedahkan bahawa konsep ini tidak sepenuhnya baru. Banyak bahasa pengaturcaraan lama, termasuk dialek BASIC awal dan C sebelum C99, tidak mempunyai jenis boolean khusus. Bahasa assembly biasanya menggunakan perbandingan integer dan daftar bendera berbanding nilai boolean eksplisit.
Segala yang lama adalah baru semula
Faedah praktikal termasuk menghapuskan keperluan untuk pembungkusan Some()
eksplisit dalam banyak kes dan mengurangkan pernyataan pulangan awal dalam fungsi. Walau bagaimanapun, pengkritik bimbang tentang kerumitan yang diperkenalkan, terutamanya apabila berurusan dengan format data luaran seperti JSON yang membezakan antara false
, null
, dan nilai yang hilang.
Bahasa Pengaturcaraan Bersejarah Tanpa Boolean Khusus:
- Kebanyakan dialek BASIC
- C sebelum C99 (menggunakan integer)
- Kebanyakan bahasa assembly
- FORTH (boolean ditakrifkan sebagai perkataan)
- Emacs Lisp (hanya
nil
yang falsy) - Ruby (hanya
false
dannil
yang falsy)
Keraguan Komuniti dan Cabaran Teknikal
Walaupun keanggunan teori menarik ramai pembangun, kebimbangan praktikal mendominasi perbincangan. Sistem masih memerlukan beberapa bentuk pembuatan keputusan binari di peringkat mesin, menyebabkan sesetengah pihak berhujah bahawa ini hanya mengaburkan boolean berbanding menghapuskannya. Pengaturcaraan shader GPU dan teknik pengaturcaraan tanpa cabang sudah menunjukkan pendekatan alternatif kepada logik bersyarat tanpa jenis boolean tradisional.
Cadangan menghadapi cabaran dalam senario dunia sebenar di mana nilai boolean eksplisit diperlukan, seperti respons API atau fail konfigurasi. Pengkritik mencadangkan bahawa pengguna tidak dapat dielakkan akan mencipta jenis pembungkus yang berkelakuan seperti boolean, berpotensi menjadikan sistem lebih kompleks berbanding lebih mudah.
Walaupun terdapat kebimbangan ini, penerokaan menawarkan wawasan berharga ke dalam prinsip reka bentuk bahasa dan mencabar pembangun untuk mempertimbangkan semula konsep pengaturcaraan asas. Sama ada praktikal atau tidak, eksperimen pemikiran sedemikian menolak sempadan bagaimana kita berfikir tentang sistem jenis dan aliran kawalan dalam bahasa pengaturcaraan.