Rust: Hapus operator ternary

Saya setuju. Saya bertanya-tanya mengapa kami memiliki operator ternary juga.

Sepakat. Seandainya saya menjadikan JS sebagai bahasa ekspresi. Perpecahan pernyataan/ekspresi yang hebat memotivasi ?: tetapi Rust bebas dari itu, dan if-else sudah cukup.

/menjadi

Sebagai pengguna yang sangat berat dari ?: operator di C/C++, saya lebih suka sintaks yang ringkas. Saya juga berpikir formatnya lebih baik ketika ekspresi terlalu panjang untuk muat pada satu baris:

let x = some_very_long_condational
     ? if_true
     : if_false

let x = if some_very_long_condational 
     { if_true}
     else { if_false}

Sintaksnya bisa menjadi lebih buruk, dalam pandangan saya, jika if_true dan if_false tidak muat dalam satu baris. Misalnya, di mana harus memasang kawat gigi.

Hanya dua sen saya.

Saya suka:

let x = if some_very_long_condational { 
                 if_true
           } else { 
                 if_false
           }

Itu menambahkan beberapa baris tambahan ("baris lain" dan braket terakhir), tetapi tetap bersih dan Anda dapat menambahkan kode sebanyak yang Anda inginkan.

Saya sering menggunakan operator ternary di C++, tapi menurut saya sintaksnya buruk. Anda ingin melihat ? dan : di tengah lautan token lain untuk melihat bahwa itu bahkan bersyarat. Dengan ekspresi-jika Anda memiliki token utama yang menunjukkan kepada pembaca "ini dia bersyarat".

Yah saya masih lebih suka sintaks dari operator ?: . Saya menemukan pilihan pemformatan Anda terlalu bertele-tele, terutama untuk kasus-kasus sederhana ketika if_true dan if_false adalah ekspresi tunggal (berlawanan dengan beberapa pernyataan yang diakhiri dengan ekspresi).

Namun demikian, saya tidak akan keberatan jika operator ?: dihapus.

Saya juga menggunakan ?: semua tempat, tapi saya masih berpikir menghapusnya adalah ide yang bagus -- ini membebaskan dua (!) tanda ASCII dalam sintaks ekspresi kita. Pikirkan semua hal luar biasa samar lainnya yang bisa kita lakukan dengan mereka.

Penggunaan non-samar akan memungkinkan mereka sebagai bagian dari nama predikat.
Misalnya "kosong?()" bukannya "is_empty()".

@marijnh ++ :)

Secara pribadi saya tidak peduli. Igor berdebat untuk ternary kembali di https://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.html

Ini dilakukan di pull req #1705.

    return parent.index_of(child_a) < offset_b ? -1 : 1

terlihat jauh lebih baik daripada

    return if parent.index_of(child_a) < offset_b {
        -1 
    } else {
        1
    }

Jika kita harus piton tentang ini,

return -1 if parent.index_of(child_a) < offset_b else 1

akan jauh lebih baik.

Saya setuju, saya tidak mengerti mengapa itu harus dihapus... Tolong jangan paksa pengguna Rust untuk menulis kode berat/verbose yang tidak perlu, ketika praktik umum seperti itu (operator ternary) ada di sebagian besar jika tidak semua bahasa.

Bagaimanapun, itu sudah selesai, tetapi saya hanya ingin menambahkan suara saya ke mereka yang mendukung gaya kode yang lebih bersih.

Saya juga merindukan sintaks ini

Saya pikir ada tiga efek konspirasi yang bekerja di sini, yaitu

1) "Pernyataan/ekspresi yang terbelah" (@BrendanEich);
2) Pemaksaan non-Boolean dalam konteks Boolean;
3) Bahkan bahasa 'dinamis' biasanya tidak mendapatkan 'sintaks dinamis' (makro nyata) dan 'semantik dinamis' (ala Python from __future__ import division ) akhir-akhir ini.

(1) berarti bahwa if ... then ... else ... secara fundamental berbeda dari ... ? ... : ... , yang merupakan perbedaan yang sepenuhnya dapat diabaikan. Ada kasus tepi seperti return , tetapi secara keseluruhan perbedaan tidak diperlukan.

(2) berarti Anda dapat, dalam banyak bahasa, menggunakan ekspresi arbitrer sebagai tes; ini hanya terlihat nyaman selama Anda masih menggunakan bahasa pertama Anda dan akan mengganggu segera setelah Anda mulai dengan bahasa kedua Anda. Seperti yang ditunjukkan di atas pada diskusi reddit ini , tidak jelas mengapa daftar kosong harus menunjukkan false atau true —cukup tulis if ( d.length == 0 ) ... dan Anda mendapatkan _so_ banyak kejelasan!

(3) berarti Anda terjebak dengan apa pun yang diberikan komite bahasa kepada Anda, dan apa pun itu, bahasa tersebut kemungkinan akan terjebak dengannya sampai seseorang datang, memotong atau menulis ulang basis kode dan memberinya nama baru. Itu bisa berbeda; mungkin ada bahasa yang memungkinkan, katakanlah, use 'ternary conditions'; use 'empty lists are false'; . Ada preseden untuk itu. Tentu saja, banyak hal yang menentang fleksibilitas seperti itu karena Anda harus selalu mengingat "penanda penyimpangan" itu dan ingat untuk menyalinnya saat Anda menyalin dan menempelkan program. OTOH jika pengguna biasa dapat mengubah sintaks dan semantik bahasa dengan mudah dan mengemas praktik tersebut ke dalam modul yang dapat diinstal, itu dapat sangat membantu dalam evolusi bahasa.

@kevina Terkadang verbositas bukanlah hal yang buruk, tetapi saya setuju bahwa operator ternary membersihkan kode dengan sangat baik.

@caitp : sebenarnya apa yang salah?

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

atau salah satu favorit pribadi saya "hugging clauses"

return 
    if parent.index_of(child_a) < offset_b { -1 } 
    else                                   {  1 }

... atau gunakan korek api, terutama jika ada beberapa kondisi ...

return match parent.index_of(child_a) < offset_by {
  true  => -1,
  false => 1
}

... dan tentu saja jika kemungkinan akan digunakan kembali: pindahkan saja ke fungsi ...

return parent.is_child_before(offset_b)

Lihat itu... Anda punya pilihan... karena _semuanya_ adalah ekspresi.

Saya tidak pernah ingin menyimpan _enam karakter_ yang diperlukan untuk menulis if {} else {} alih-alih
() ? : , ditambah chaining conditional tambahan terlihat jauh lebih bagus dengan if-as-an-expression. (Operator ternary bersarang menjadi berantakan dengan sangat cepat.)

Menurut pendapat saya: saat menggunakan if-as-an-expression Saya tidak melihat perlunya menyuntikkan begitu banyak spasi yang tidak perlu. Saya juga menemukannya membaca lebih alami daripada operator ternary, dan verbositas tambahan membantu memisahkan dua klausa secara visual. Itu hanya $0.02

Saya pikir Anda mungkin salah membaca apa yang saya katakan (dan perhatikan bahwa ini beberapa waktu lalu)

Saya hanya menunjukkan bahwa saya tidak melihat bagaimana operator ternary dengan cara apa pun terlihat "jauh lebih baik."
Menurut pendapat saya, bentuk umum jauh lebih indah daripada bentuk kasus khusus.

Komentar mengatakan bahwa kadang-kadang, conditional-as-expression sangat berguna, sebagai lawan dari pernyataan conditional. Menjatuhkan kawat gigi pelukan hanya secara subjektif merupakan peningkatan

return parent.index_of(child_a) < offset_b ? -1 : 1

vs

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

@caitp adalah yang kedua di sini benar-benar jauh lebih buruk daripada yang pertama? Rust's if else masih merupakan ekspresi (bukan pernyataan).

Pikiran saya adalah:

• Yang kedua sepertinya akan lebih mudah dibaca oleh seseorang yang tidak memiliki riwayat bahasa lain dan
• Kami mungkin akan lebih baik menyimpan sintaks ? di lengan baju kami untuk gula masa depan (mungkin terkait dengan Opsi, dll)

@mitchmindtree benar-benar.

Sekali lagi, Anda salah memahami apa yang dikatakan komentar itu.

return if parent.index_of(child_a) < offset_b { -1 } else { 1 } masih mengevaluasi kondisional sebagai ekspresi (dan dengan demikian dapat menjadi operan untuk return ).

Kawat gigi itu jelek, tetapi poin utamanya adalah tentang ekspresi bersyarat, bukan tentang kawat gigi. Ini tentang kemampuan menulis return foo.bar.baz(<conditional operand>) versus if (<conditional operand>) { return foo.bar.baz(1); } else { return foo.bar.baz(2); }

Saya pikir apa yang benar-benar perlu kita sadari adalah bahwa masalah ini sudah berusia lebih dari tiga tahun. Mengingat orang-orang tidak terlalu merindukan ternaries dalam tiga tahun, saya pikir aman untuk mengatakan bahwa mereka akan tetap disingkirkan.

@caitp hmm saya masih tidak yakin saya mengikuti. Apakah Anda berbicara tentang karat pada khususnya? Atau hanya pernyataan vs ekspresi secara umum?

Dalam karat Anda masih bisa melakukannya

return foo.bar.baz(if cond { 42 } else { 0 })

? (Saya sadar Anda tidak berbicara tentang kawat gigi btw, maaf atas kebingungannya :smile_cat: )

Pada saat itu, di ToT, tidak ada cara untuk melakukan ini di Rust.

Saya tidak memiliki pendapat yang kuat, tetapi saya hanya ingin menambahkan bahwa jika ? dan : lebih baik digunakan untuk hal-hal lain, mengapa tidak menggunakan sesuatu seperti ?? dan ?: sebagai gantinya, misalnya cond ?? 43 ?: 0 ?

Mengapa mengubah cara pengembang telah digunakan selama puluhan tahun?

Le sam. 24 okt. 2015 02:46, Kevin Atkinson [email protected] a
écrit:

Saya tidak memiliki pendapat yang kuat, tetapi saya hanya ingin menambahkan bahwa ? dan dapat
lebih baik digunakan untuk ucapan terima kasih lainnya mengapa tidak menggunakan sesuatu seperti ?? dan ?:
sebagai gantinya. jadi mungkin cond?? 43 ?: 0.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/rust-lang/rust/issues/1698#issuecomment -150728625.

@RenaudParis Maaf, yang ingin saya katakan adalah: Saya tidak memiliki pendapat yang kuat, tetapi saya hanya ingin menambahkan bahwa jika ? dan : lebih baik digunakan untuk hal lain, mengapa tidak menggunakan sesuatu seperti ?? dan ?: sebagai gantinya, misalnya cond ?? 43 ?: 0 ?

Salah satu alasan operator ternary dihapus adalah agar "?" dapat digunakan untuk hal lain di masa depan. Saran saya adalah menggunakan operator lain. cond ?? 43 ?: 0 masih lebih pendek dari if cond {43} else {0} .

Saya pikir itu benar untuk dihapus Namun tidak akan terlalu buruk jika bracer tidak diperlukan untuk ekspresi tunggal. (Dan ya saya tahu betapa menyebalkannya ini di parser, itu sangat berharga - keterbacaan sangat penting)

misalnya

if i ==0 
     return i
else 
      1  

atau bahkan

if i == 0  return i
    else 1  

Format ini lebih baik dari

 if i == 0   ? return i
      : 1  

atau

if i == 0   
      ? return i 
      : 1  

ayat

if i ==0 {
      return i
}
else {
    1
}      

cukup jelek / sulit dibaca untuk sesuatu yang begitu umum .

Ini menjadi lebih buruk tetapi lebih mudah dibaca jika Anda memiliki kebijakan pengembang terhadap kawat gigi Mesir.

if i ==0
{
     return i
}
else
{
     1
 }