Mungkin a..b| atau a..b]

Saya pikir ini akan membuka jalan untuk jenis baru kesalahan tak terduga di masa depan karena kesalahan ketik sederhana (.. vs ...). Lebih baik jika .... (4 periode). Dengan cara ini kurang rawan kesalahan terhadap faktor manusia, imo.

Saya pikir https://github.com/rust-lang/rfcs/pull/1592 dan https://github.com/rust-lang/rfcs/pull/1582 digabungkan buat alasan untuk menggunakan ..= sintaks sebagai gantinya. Kecuali seseorang dapat memikirkan sintaks yang lebih baik daripada (head..., tail) untuk memperluas Tuple di depan Tuple yang lebih besar.

Saya menemukan masalah ini karena saya memiliki kesalahan _off-by-one- dot _ dalam kode saya ketika saya bermaksud menggunakan rentang eksklusif.

untuk sintaks ... . Saya pikir memiliki sintaks yang mudah salah ketik yang menyebabkan kesalahan satu per satu akan menjadi pijakan kaki.

Fungsionalitasnya berguna, jadi saya akan senang memilikinya dengan sintaks yang berbeda, misalnya ..=

Apakah sintaks untuk ini merupakan pertanyaan terbuka? Karena ... sudah ada dalam pernyataan kecocokan, saya berasumsi bahwa kapal telah berlayar.

Saya pribadi lebih suka kisaran inklusif ... , namun karena sudah ada versi eksklusif .. , saya melihat potensi masalah. Setelah melihat #23635 meskipun saya lebih suka mencela .. dan hanya mengizinkan ... sekalipun.

Saya sering menggunakan rentang inklusif untuk setara dengan C-like for loop for i in 0..foo.len() sangat cocok, jadi saya lebih suka yang itu tetap (saya membutuhkan ini, karena iterator Rust adalah "1-dimensi" dan sering terlalu canggung untuk digunakan dengan array 2D atau iterasi non-linear).

Masalah dengan overflow untuk rentang inklusif terlihat konyol, tetapi dalam praktiknya saya tidak pernah mengalami masalah ini, karena Rust mengganggu untuk digunakan dengan jenis apa pun selain usize . Jika saya tidak melakukan cast saat membuat rentang for i in 0..(len as usize) , maka saya tetap harus menggunakan i as usize setengah lusin kali di dalam loop.

Karena sintaks ini masih berpagar fitur, saya harap kapalnya belum berlayar.

Mempertimbangkan bahwa Swift menggunakan ... untuk inklusif dan ..< untuk rentang eksklusif, menggunakan ..= untuk inklusif tampaknya cukup masuk akal.

Saya tidak memiliki wawasan yang berguna, tetapi saya ingin rentang inklusif keluar dari status "eksperimental". Saat saya menelusuri Rust By Example, saya menemukan satu cuplikan yang dapat mengambil manfaat dari ini:

fn fizzbuzz_to(n: u32) {
    for n in 1..n + 1 {
        fizzbuzz(n);
    }
}

Ke atas ? 😄

Saya ingin menulis RFC untuk sintaks a ..= b dan rentang umum. Saya telah memulai utas diskusi untuk berbicara tentang bagaimana rentang seperti itu akan diwakili di perpustakaan standar.

IMHO ..= terlihat aneh. Pendekatan Swift dari ... dan ..< terlihat lebih baik bagi saya, karena saya lebih suka elipsis daripada dua titik - elipsis berarti penghilangan dan kami menghilangkan angka antara awal dan akhir rentang.

Saya masih berpikir ... dan .. sudah cukup baik. Anda memiliki perbedaan 1 karakter, jadi kesalahan lebih sulit dilakukan daripada +/- atau x/y atau apa pun.

Karena saya sendiri salah memahami ini sebelumnya (dan menghapus komentar saya):

Berdasarkan proses RFC Rust, proposal ini telah ditinjau, didiskusikan, dan disetujui dalam permintaan tarik RFC 1192 . Isu saat ini melacak implementasi dari apa yang sebelumnya diputuskan di sana. Diskusi mencakup banyak poin yang diangkat orang di sini: sintaks alternatif (termasuk tidak ada sintaks baru), kontras dengan operator serupa Ruby, dll.

Jika Anda merasa sangat yakin bahwa fitur tersebut harus berbeda, saya pikir Anda perlu membawanya melalui proses RFC yang sama, karena begitulah cara perubahan bahasa dibuat. Tapi masalah ini bukan tempat untuk itu.

@jimblandy mungkin kita harus meminta @nikomatsakis mengedit pengingat dan panduan sopan itu ke komentar pertama di Really Big Print. 😇

@shepmaster Itu mungkin hal yang baik untuk ditambahkan ke template yang digunakan untuk mengajukan _semua_ masalah pelacakan.

Pencalonan untuk diskusi/kemungkinan FCP

Kami membahas ini dalam pertemuan @rust-lang/lang. Ada perasaan tidak senang secara umum dengan fitur ini -- kami mempertimbangkan untuk berhenti menggunakannya, tetapi memutuskan untuk menundanya untuk saat ini. Ada dua keberatan utama terhadap ... sebagaimana adanya:

• kemudahan kebingungan antara .. dan ... ;
• @aturon telah berpikir bahwa akan lebih baik untuk memiliki sintaks rentang yang lebih "berkemampuan penuh" -- ini juga dapat digunakan dalam API seperti iterasi btree dan sebagainya.

Untuk itu, kami bertanya-tanya apakah seseorang akan bersedia mendorong RFC yang memungkinkan sintaks yang lebih umum seperti itu memungkinkan orang menentukan dengan tepat apakah batas bawah dan atas akan inklusif atau eksklusif. Saya pikir @aturon akan senang bekerja dengan seseorang di RFC seperti itu.

Saya tahu saya terhenti untuk sementara waktu, tetapi saya baru-baru ini membuka utas diskusi tentang bagaimana merepresentasikan rentang yang sepenuhnya berkemampuan di libstd (ditautkan di atas ), tetapi tidak ada yang berkomentar :(

Dengan beberapa masukan di atas, saya akan dengan senang hati membantu dengan RFC baru.

Saya baru-baru ini membuka utas diskusi tentang cara merepresentasikan rentang yang sepenuhnya berkemampuan di libstd (tertaut di atas), tetapi tidak ada yang berkomentar :(

Itu agak mencerminkan kegunaannya.
Meskipun memiliki rentang inklusif-eksklusif yang sewenang-wenang terdengar seperti ide yang bagus, saya cukup yakin semuanya kecuali untuk .. dan pada tingkat yang lebih rendah ... tidak akan pernah digunakan.

@durka

Saya tahu saya terhenti untuk sementara waktu, tetapi saya membuka utas diskusi tentang cara mewakili rentang yang sepenuhnya berkemampuan di libstd (ditautkan di atas), tetapi tidak ada yang berkomentar :(

Ini kira-kira pendekatan yang kami pikirkan, ya.

@petrochenkov

Meskipun memiliki rentang inklusif-eksklusif yang sewenang-wenang terdengar seperti ide yang bagus, saya cukup yakin semuanya kecuali untuk .. dan pada tingkat yang lebih kecil ... tidak akan pernah digunakan.

Sejujurnya, saya setuju, tetapi saya masih berpikir mungkin perlu mengejar sintaks yang lebih umum. Secara khusus, menurut saya ... kurang optimal, tetapi jika kita pindah ke ..= atau sesuatu yang lebih eksplisit, mungkin tidak ada salahnya untuk melakukan sesuatu yang lebih umum, meskipun jarang. digunakan. Artinya, jika kita membuatnya sistematis, tampaknya tidak terlalu sulit untuk dipelajari, dan tentu saja tidak akan ada kebingungan apakah .. atau ... berarti "lebih banyak angka ".

Ini kira-kira pendekatan yang kami pikirkan, ya.

Yang mana? Saya menyarankan beberapa alternatif di posting saya.

Saya sering ingin mengulangi rentang inklusif dan sangat suka mengetik 0...x daripada 0..(x + 1) . Saya mengerti bahwa ini mungkin menimbulkan kesalahan satu per satu, tetapi alternatif apa yang kita miliki?

Dengan asumsi sintaks Rust dapat diubah secara bebas tanpa efek samping, saya hanya melihat beberapa pola yang jelas:

Mengambilnya apa adanya

1..4 // 1, 2, 3
1...4 // 1, 2, 3, 4

yang merupakan solusi oke IMHO dan juga digunakan dalam pencocokan pola.

Pinjam dari matematika

[1, 4] // 1, 2, 3, 4
[1, 4[ // 1, 2, 3
]1, 4] // 2, 3, 4
]1, 4[ // 2, 3

yang merupakan sintaks paling lengkap, tetapi melanggar aturan kurung kurawal buka dan tutup yang sama dan secara visual lebih sulit untuk diuraikan.

Pinjam dari Python

1:1:=5 // 1, 2, 3, 4, 5
1:1:<5 // 1, 2, 3, 4

yang merupakan pola yang diketahui dan juga dapat menggabungkan ukuran langkah. Saya tidak tahu bagaimana proses RFC bekerja, tetapi saya pikir ukuran langkah juga harus dipertimbangkan ketika berbicara tentang rentang.

Ketika ukuran langkah bukan bagian dari diskusi ini (atau yang akan datang), ..= dan ..< tampaknya sangat masuk akal!

Pembaruan: Saya pikir ..= dan ..< akan menjadi solusi yang sangat bagus. Menjaga ukuran langkah sebagai adaptor jauh lebih masuk akal.

Haruskah diskusi ini memasukkan rentang menurun? Solusi saat ini untuk membalikkan rentang cukup membingungkan (tetapi mungkin tidak jika kami memiliki rentang inklusif).

misalnya Dapatkah Anda membaca dan memahami ini tanpa menyipitkan mata?

for i in (1..l.len()).rev() { ... }

EDIT: dan dengan font GitHub itu bahkan lebih membingungkan karena l terlihat seperti 1

Saya pikir ukuran langkah negatif sudah cukup.

Kita bisa menggunakan sintaks Matlab, a:b dan a:step:b .

Pada 4 Nov 2016 00:50, "Ott" [email protected] menulis:

Saya pikir ukuran langkah negatif sudah cukup.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment -258344460,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n3kwnGH6POQb4dGwCwJ8yOGqPSBQks5q6rmDgaJpZM4F4LbW
.

@durka Jadi apa yang setara dengan .. , di mana tidak ada a atau b ? Hanya : ?

Sesuatu yang saya tidak melihat dicatat di RFC: Apakah nama yang berbeda dipertimbangkan untuk bidang?

Jika ada jenis yang berbeda, mungkin bermanfaat untuk memiliki nama bidang yang berbeda ketika mereka memiliki arti yang berbeda. Misalnya "range.start" adalah "batas inklusif bawah" pada semua jenis. Tapi "range.end" terkadang inklusif dan terkadang eksklusif. Perbedaan antara "akhir" dan (manusia jerami) "terakhir" membuatnya lebih jelas.

(Ini, tentu saja, tidak relevan jika tipe yang berbeda ditinggalkan demi Range>...)

Saya pikir rentang inklusif masih harus menerapkan std::collections::range::RangeArgument.

pub trait RangeArgument<T> {
    fn start(&self) -> Option<&T> { ... }
    fn end(&self) -> Option<&T> { ... }
}

Kemudian

impl RangeArgument<T> for RangeToInclusive<T> {
   fn end(&self) {
     Some(self.end+1)
   }
}

Sehingga fn foo<T, R: RangeArgument<T>>(arg: R) dapat mengambil rentang inklusif atau setengah terbuka.

@durka Masalah dengan sintaks a:b adalah ambigu dengan jenis ascription. Apakah Anda meminta variabel b , atau tipe b ? Jelas sebagai pemrogram Rust yang baik, kami memanfaatkan tipe kami, tetapi kompiler tidak dapat menyimpulkannya.

.. operator dengan definisi matematika (berdasarkan komentar @duesee ):

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

Menggunakan (berdasarkan @0tt contoh):

fn fizzbuzz_to(n: u32) {
    for n in [1..n + 1] {
        fizzbuzz(n);
    }
}

Dalam hal ini kita menggunakan .. hanya sebagai petunjuk, tetapi batasannya diberikan oleh [ dan ]

@adelarsq : Di Rust kami tidak membutuhkan rentang yang tidak menyertakan awal. Tetapi sintaks braket hanya masuk akal jika diizinkan. Plus, sintaks braket sudah digunakan.

Saya pikir ..= adalah pilihan paling masuk akal untuk rentang inklusif.
Mudah dibedakan secara visual dari .. , yang bukan ... . Peluang mengetik ... ketika berarti .. atau sebaliknya dan tidak memperhatikan lebih tinggi daripada dengan ..= .
(Ini sebanding dengan mengetik if(a = b) tidak sengaja alih-alih if(a == b) di C, baik dalam visibilitas visual dan potensi bug).
Dan ..= mudah dihafal karena simbolis untuk artinya ( i ..= j berarti kisaran i .. j dan di mana i = j ).

Tampaknya keluhan utama adalah ... terlalu mirip dengan .. . Saya perhatikan bahwa ketika saran lain dibuat yang melibatkan lebih banyak karakter, tidak ada yang mengeluh tentang jumlah karakter, hanya hal-hal seperti pencocokan braket dan penggunaan di tempat-tempat tertentu.
Jadi, bagaimana dengan .... untuk rentang inklusif? Seharusnya masih terlihat seperti rentang, dan seperti yang saya katakan, sepertinya tidak ada yang keberatan dengan solusi yang membutuhkan karakter tambahan. Masih bisa diperdebatkan apakah itu lebih atau kurang miring dari ..= .
for i in 0....10 { println!("just a thought"); }

Jika perilaku default termasuk ..! operator akan digunakan (hampir sebagai negasi).

Masalah dengan .... adalah akan membingungkan jika ... benar-benar ada.

Saya juga tidak suka ... , karena persis kebalikan dari Ruby .

Pilihan terbaik sejauh ini adalah ..= saya pikir.

@adelarsq , .... akan menggantikan operator ... , jadi jika Anda mencoba melakukan .. dan menambahkan tambahan . , itu akan menjadi kompilasi kesalahan waktu, jika Anda mencoba melakukan .... dan lupa sebuah titik, itu akan menjadi kesalahan juga.

Karena dalam pencocokan pola, ... digunakan untuk mencocokkan rentang inklusif, jadi masuk akal juga untuk menggunakan ... untuk ekspresi rentang inklusif.
Untuk rentang dengan langkah, saya lebih suka sintaks Haskell, misalnya 1,3..9 => [1,3,5,7]

Untuk rentang dengan langkah/mundur, dll. Saya lebih suka fungsi kuno yang baik (semacam konstruktor Range ) daripada literal yang kompleks.

Saya akan baik-baik saja dengan quad-dot .... (walaupun ..= juga IMHO baik-baik saja). Itu dapat diizinkan dalam pencocokan pola juga untuk konsistensi (dan akhirnya ... dalam pola dapat ditinggalkan).

Bagi saya ..= sebagai penanda visual yang tidak dimiliki .... .

Saya baru saja memperhatikan sesuatu:

Dalam matematika Anda dapat menulis ∀ i: 0 ≤ i < 10 yang akan diterjemahkan menjadi

for i in 0 ..< 10 { }

Ini konsisten.

Namun, pernyataan ∀ i: 0 ≤ i ≤ 10 akan diterjemahkan menjadi

for i in 0 ..= 10 { }

Di sini, diterjemahkan menjadi =, yang terasa tidak konsisten.

Ini mungkin bikeshedding, tapi

for x in 0 ..<= 10 { }

terasa lebih benar. Ini mungkin karena latar belakang C saya di mana

for (unsigned int i = 0; i <= 10; ++i) { }

diterjemahkan menjadi "selama i lebih kecil atau sama dengan 10 lakukan sesuatu". Dalam CI memilih untuk tidak menggunakan == dalam kondisi loop, karena kemungkinan untuk melompati nilai dan berakhir di infinite loop. Ini tidak dapat terjadi di Rust, tetapi menerjemahkan for i in 1 ..= 10 ke C mungkin menyarankan hal itu.

Mengambil lebih jauh,

for i in 0 <..<= 10 { }

akan cukup jelas.

Sunting: ini adalah contoh terbalik yang buruk yang dimaksudkan untuk menunjukkan bagaimana hanya menggunakan = mungkin membingungkan. Dihapus, karena lebih membingungkan daripada membangun.

@duesee Bagaimana >=..> jelas? Bukankah seharusnya <=..> (<= 10 dan > 0) ?
IMO itu tidak cukup jelas, itu samar dan terlalu lama sebagai operator.
(Tidak ada operator yang lebih panjang dari 3 karakter IMO).
Btw, kita sudah punya cara untuk menyatakan arah iterasi terbalik: .rev()
Kami hanya membutuhkan operator untuk rentang inklusif dan mungkin .step_by() .
Untuk langkah sintaksnya bisa a .. b | s (dan untuk rentang inklusif: a ..= b | s ).

@norru : Contoh Anda for i in (1..l.len()).rev() { ... } sangat tidak realistis, karena sebagian besar waktu Anda akan menggunakan irisan ( for x in arr[1..].rev() { ... } ), tetapi bahkan jika Anda terpaksa menggunakan gaya indeks iterasi (pada dasarnya hanya ketika Anda memodifikasi elemen array yang tidak pada i ), saya tidak merasa sulit untuk membaca sama sekali. (Tapi saya biasanya meninggalkan spasi di sekitar .. ketika argumennya bukan angka literal: (1 .. arr.len()).rev() )

>=..> lebih banyak spesies ikan di operator Rust!

Tapi saya sangat suka ..<= (edit: uhh, kecuali di match yang terlihat seperti <= 0 => :()

• Ini sangat berbeda dari biasa .. ,
• itu tidak memiliki konotasi += dari ..= ,
• itu secara logis konsisten bahkan dengan Swift ..< . Mungkin saja kedua bahasa itu menyatu!
• dan yang paling penting cukup jelas bahwa Anda mendapatkan angka dalam kisaran yang kurang dari atau sama dengan yang di atas.

@pornel : >=..> more species of fish in Rust operators! Hehe :-)

@Boscop : sudah cukup jelas jika Anda membacanya seperti definisi dalam matematika: 10 >= i > 2 . Untuk sisa jawaban Anda: Saya sangat setuju. Bagian kedua dimaksudkan sebagai motivasi untuk memikirkan kembali ..= vs. ..<= untuk tidak memperkenalkan pemblokir untuk ekstensi mendatang. Saya akan mengedit jawaban saya yang sesuai.

juga bisa mendapatkan tanda untuk memperingatkan atau kesalahan pada notasi ..

Saya tidak ingin .. muncul di mana pun di basis kode saya

Saya ingin memberikan suara lain untuk ..=

Kelemahan dari ..< dan ..<= adalah bahwa kode tersebut sudah valid (rentang eksklusif terbuka kanan dibandingkan dengan nilai lain).

@thepowersgang

Kelemahan dari ..< dan ..<= adalah bahwa kode tersebut sudah valid (rentang eksklusif terbuka kanan dibandingkan dengan nilai lain).

meskipun benar, tampaknya hal ini tidak mungkin menjadi masalah dalam praktiknya, bukan?

Saya lebih suka ... daripada saran lain di sini.. tetapi jika saya harus memilih sintaks alternatif, itu akan menjadi ..=

@nikomatsakis

Saya menentang opsi ..< dan ..<= semata-mata dengan alasan bahwa mereka secara tidak proporsional memperumit proses memperoleh model intuitif tata bahasa bahasa.

Pada catatan yang lebih pribadi, saya menemukan mereka setidaknya sama jelek dan tidak elegannya dengan turbofish.

Saya akan menggunakan .. untuk hak eksklusif dan ..= untuk inklusif sebagai keseimbangan terbaik antara keanggunan visual, aturan tata bahasa yang mudah dipahami secara intuitif, dan membuat keduanya sulit untuk membingungkan.

Apakah ... benar-benar tidak berbeda dari .. ? Mengapa saya sangat menyukainya?

@tshepang

Saya suka ... karena menarik secara estetis... tetapi saya menentangnya karena saya khawatir ini berpotensi menyebabkan bug yang sulit dikenali seperti menulis if (x = 2) { daripada if (x == 2) { di C/C++. (Dan sudah diketahui dengan baik betapa berbahayanya itu.)

@ssokolow

IMO yang lebih baik diselesaikan dengan linting atau flag opsi. Saya tidak melihat banyak gunanya mencampur notasi dalam satu file/proyek.

Juga lebih suka .... daripada opsi lain, memiliki dua kali lipat lebar/spasi harus membuatnya cukup jelas terutama mengingat mereka akan diapit di kedua sisi oleh simbol yang akan membuat ruang negatif itu lebih menonjol daripada terisolasi.

@ssokolow

Saya akan menggunakan .. untuk hak-eksklusif dan ..= untuk inklusif sebagai keseimbangan terbaik antara keanggunan visual, aturan tata bahasa yang mudah dipahami secara intuitif, dan membuat keduanya sulit untuk membingungkan.

Ini bekerja untuk saya. Poin utama adalah apakah kita juga menginginkan sintaks untuk kasus lain (misalnya, <..<= ). Saya pribadi merasa bahwa .. dan ..= mencakup 99,5% kasus. Saya pikir kasus penggunaan utama adalah API seperti drain , dan saat ini kami telah mengadopsi pendekatan yang berbeda di sana .

cc @rust-lang/libs

Kami dapat meninggalkan kasus yang tidak biasa untuk secara langsung membangun rentang menggunakan
struktur literal.

Pada hari Rabu, 22 Februari 2017 jam 16:50, Niko Matsakis [email protected]
menulis:

@ssokolow https://github.com/ssokolow

Saya akan memilih .. untuk hak-eksklusif dan ..= untuk inklusif sebagai yang terbaik
keseimbangan antara keanggunan visual, aturan tata bahasa yang mudah dipahami secara intuitif
pegang, dan membuat keduanya sulit untuk membingungkan.

Ini bekerja untuk saya. Poin utama yang mencuat adalah apakah kita juga ingin a
sintaks untuk kasus lain (misalnya, <..<=). Saya pribadi merasa bahwa .. dan ..=
mencakup seperti 99,5% kasus. Saya pikir kasus penggunaan utama adalah API seperti tiriskan,
dan kami saat ini telah mengadopsi pendekatan yang berbeda di sana
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range
.

cc @rust-lang/libs https://github.com/orgs/rust-lang/teams/libs

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-281815665 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n-aKwYKFq4VI9RizL0GkzXXSjTPwks5rfK2ngaJpZM4F4LbW
.

Saya mengambilnya ..= akan tersedia dalam pola juga? Apa yang akan terjadi dengan sintaks ... ada di sana?

Itu bisa ditinggalkan. Tapi keberadaannya adalah preseden yang cukup kuat untuk
menggunakannya, setidaknya sebagai singkatan.

Pada Rabu, 22 Februari 2017 pukul 18:02, andrewtj [email protected] menulis:

Saya ambil ..= akan tersedia dalam pola juga? Apa yang akan terjadi?
yang ada ... sintaks di sana?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-281834007 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3nw_DaOMNxuIKw6ZFfXJW95QyijY4ks5rfL6DgaJpZM4F4LbW
.

@durka @andrewtj Saya akan menganggap bahwa kita akan mencela itu.

..= dapat digunakan sebagai operator dalam arti yang sama dengan += .
Saya sarankan menggunakan air pasang ~ , misalnya 0~9 , 'A'~'Z' .

Operasi apa yang sesuai dengan ..= ? - jelas tidak dapat bertahan karena
1-9 == -8 .

Pada hari Rabu, 22 Februari 2017 jam 20:04, Junfeng Liu [email protected]
menulis:

..= dapat digunakan sebagai operator dalam arti yang sama dengan +=.
Saya sarankan menggunakan ~, misalnya 0~9, 'A'~'Z'.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-281856846 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n7N2dM4DAzc_uc5JdHit4IJgyvYGks5rfNsPgaJpZM4F4LbW
.

@durka ..= hanya terlihat seperti operator penugasan, kasus penggunaan harus jarang. ~ pasang bukan sub. Gunakan ... juga ok.

impl Fill for Range<String> {
   fn fill() -> String { ... }
}
impl FillAsign for RangeAssign<String> {
   fn fill(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill()  // "abcdef"
(String::new("abc") ..= String::new("f")).fill()  //  ()

Oh maaf, itu terlihat sama di font saya. Saya bertanya, apakah ..= adalah senyawa
operator penugasan seperti +=, operasi apa yang dilakukannya (sesuai
ke +)?

Pada hari Rabu, 22 Februari 2017 jam 20:29, Junfeng Liu [email protected]
menulis:

@durka https://github.com/durka ..= hanya terlihat seperti tugas
operator, use case harus jarang. ~ pasang bukan sub.

impl Isi untuk Rentang{
fn isi() -> String { ... }
}
impl FillAsign untuk RangeAssign{
fn isi(&mut sendiri) { ... }
}
(String::new("abc") .. String::new("f")).fill() // "abcdef"
(String::new("abc") ..= String::new("f")).fill() // ()

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-281861478 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n39uqbADB1rNtBh3PBTRY2XBXOUNks5rfOD-gaJpZM4F4LbW
.

@durka @nikomatsakis oke, semoga ini segera teratasi. Situasi saat ini canggung dan sintaks berubah juga.

@pornel Menghentikan ... di match akan merusak kompatibilitas, jadi ini bukan solusi yang baik. Saya masih menemukan ... yang paling memadai (namun ini kebalikan dari Ruby, tetapi tidak ada masalah serupa yang dibahas oleh Rubyist).

@hyst329 tapi ... dapat lebih rentan terhadap kesalahan, karena hilang atau menambahkan satu . akan memberikan arti baru

Penghinaan tidak merusak sesuatu. Sintaks lama harus didukung selamanya untuk program yang ada, tetapi pengguna dapat diarahkan ke sintaks baru melalui dokumentasi dan rustfmt.

tetapi pengguna dapat diarahkan ke sintaks baru melalui dokumentasi dan rustfmt.

Saya sangat menyarankan untuk tidak menggunakan rustfmt untuk itu. Itu akan memperburuk kualitas footgun-esque dari ... ketika digunakan dalam mode "terapkan perubahan secara otomatis" karena itu dapat menerjemahkan kesalahan ketik secara diam-diam menjadi hal-hal yang terlihat jauh lebih terarah. (Sehingga membuat mereka lebih mudah untuk diabaikan pada pemeriksaan selanjutnya.)

Peringatan kompiler dalam nada "silakan periksa apa yang Anda maksud dan gunakan .. atau ..= " yang tidak dapat diperbaiki secara otomatis akan jauh lebih sesuai dengan upaya yang ada untuk meminimalkan peluang kesalahan manusia.

Harap dicatat saya berbicara dalam konteks pola ... , di mana tidak ada footgun. Saat ini Rust berada dalam situasi bebas footgun sementara di mana pola hanya mengizinkan ... dan ekspresi hanya mengizinkan .. , jadi keduanya aman dari kesalahan ketik.

Tentu saja saya tidak akan merekomendasikan mengonversi ... dalam ekspresi menjadi ..= , karena itu tentu saja hanya akan membuat kesalahan ketik permanen.

Ahh. Aku sudah lupa tentang itu. Terima kasih telah mengingatkan saya.

@adelarsq Sebenarnya, kesalahan umum seperti 'a'..'z' atau 128u8..255u8 dapat dengan mudah diintegrasikan ke dalam cargo-clippy sebagai peringatan, misalnya. Dan juga, lebar .. dan ... jelas berbeda (jika menggunakan font monospace, tentu saja; tidak menggunakannya biasanya merupakan ide yang buruk untuk menulis kode sumber secara umum - tidak hanya Rust) .

Kita bisa membuat sintaks untuk itu menjadi … (unicode horizontal elips) daripada ... Dengan begitu setidaknya tidak ada yang akan mengetiknya secara tidak sengaja.

Sunting: oh tidak ada orang yang memperlakukan saran ini dengan serius: menangis: Maaf atas kebisingannya.

Saya tidak tahu, terakhir saya memeriksa Google Documents secara otomatis mengonversi ... menjadi elipsis. Pemain utama dalam industri penyuntingan teks.

Selain itu, tidak semua orang memiliki kunci Compose untuk mengetik Compose dengan mudah . . ketika mereka ingin …

Di Windows saya bisa mengetik elips menggunakan Alt + 0133 dengan numpad! …

Dan mekanisme berbasis codepoint serupa ada di berbagai lapisan tumpukan pada desktop berbasis X11 (saya ingat GTK+ dan tumpukan input X11 memiliki solusi independennya sendiri) tetapi sangat merepotkan untuk mengingat titik kode berdasarkan angka.

Compose adalah solusi intuitif.

Satu-satunya urutan Alt Windows yang saya ingat adalah Alt + 219 dari semua menu file Batch DOS yang saya buat saat kecil.

Sintaks saat ini sudah ada untuk waktu yang lama, mari kita menstabilkannya dan menghentikan bikeshedding yang tak ada habisnya ini.

Menjaga sintaks saat ini adalah yang terburuk yang bisa kita lakukan karena memiliki banyak kelemahan nyata . Ini bukan hanya bikeshedding -- ini harus dilakukan dengan benar. Melewati seluruh utas, sintaks ..= mendapat penerimaan paling banyak sejauh ini...

Saya merasa seperti sedang mengalahkan kuda mati pada saat ini, tetapi ketika Anda memikirkannya... Perbedaan antara .. dan ... secara harfiah adalah satu salinan dari karakter sekecil mungkin yang Anda miliki. dapat mengetik atau membaca, bercampur dengan sekelompok karakter yang identik, dan memiliki potensi untuk membuat kelas kesalahan yang sangat umum dan sering kali menjengkelkan (kesalahan satu per satu) dalam kasus yang sama sekali tidak dapat dibedakan keduanya kepada manusia dan mesin.

Atau kita bisa melakukan sintaks lainnya di dunia.

Di satu sisi saya menghargai perhatian itu.. di sisi lain, sintaks pencocokan pola ... ini sudah inklusif, membuatnya sangat konsisten dengan sintaks yang sudah digunakan di tempat lain di Rust.

Dan saya pribadi tidak memiliki masalah dalam mengenali perbedaannya, meskipun saya menyadari bahwa orang dengan masalah penglihatan, atau dengan monitor 4k dan font 10pt, mungkin.

Tapi sepertinya konsensusnya ada pada ..= dan saya rasa saya juga setuju dengan itu.

FWIW, saya pernah mengalami situasi di mana saya tidak sengaja mengetik ... ketika saya bermaksud .. dan kemudian tidak menyadarinya untuk sementara waktu, tetapi setelah beberapa saat saya bertanya-tanya mengapa program saya berperilaku aneh.
Jadi ya, seharusnya ada perbedaan yang lebih terlihat, dan ..= paling masuk akal.

Pencalonan untuk diskusi @rust-lang/lang. Saya pikir kita harus mengadopsi ..= dan menyebutnya sehari. Apakah kita memerlukan RFC yang diubah? Lakukan saja? Apakah ini melibatkan penghentian sintaks ... dalam pola? (Saya berasumsi begitu.)

Saya sangat mendukung untuk tidak menggunakan ... untuk rentang. Saya tidak tahu apakah itu telah disebutkan di utas ini atau utas RFC, tetapi selain ... sangat mirip dengan .. , kami mungkin juga ingin menggunakan ... di masa mendatang untuk generik variadik, yang jauh lebih penting daripada rentang inklusif IMO.

..= tampaknya jelas, dan keburukan relatifnya dibenarkan dengan menjadi kurang umum dari .. .

Apakah ini melibatkan penghentian sintaks ... yang ada dalam pola? (Saya berasumsi begitu.)

Sepertinya ini ide yang bagus. Peringatkan ... dan dukung pola .. dan ..= jika kita bisa.

Saya biasanya berhati-hati dalam memperkenalkan peringatan yang akan mempengaruhi begitu banyak orang tanpa juga memiliki alat otomatis untuk memperbarui sintaks, tetapi ... ke ..= adalah perubahan yang sangat sederhana. Kami juga dapat mencela tetapi menunda menjadikannya peringatan sampai kami memiliki alat seperti itu. Apa yang orang lain pikirkan?

Saya sangat mendukung ... karena sintaksnya lebih "biasa"; Saya tidak tahu bahasa apa pun yang menggunakan ..= , tetapi banyak yang menggunakan .. dan ... .

Jika sentimen terhadap ..= kuat, saya lebih memilih untuk tidak menggunakan sintaks rentang inklusif (alih-alih memilih metode (a..b).inclusive() , yang tampaknya cukup ringkas bagi saya) untuk menghindari masalah visual dan sekali lagi gratis naik ... untuk generik variadik.

EDIT: Satu argumen yang bagus terhadap (a..b).inclusive() adalah bahwa kita masih memiliki ... di match dan sayangnya tidak ada sintaks baru untuk menggantikannya. :bingung:

@steveklabnik Maaf jika ini sudah disebutkan di suatu tempat di ini (yang sangat panjang) benang, tapi: apa bahasa lain menggunakan kedua .. dan ... untuk rentang eksklusif dan inklusif, masing-masing?

Rust memiliki sejarah mengadopsi fitur dan sintaks yang berguna dari bahasa lain, tetapi secara selektif , dan menolak atau mengadaptasi hal-hal yang sesuai.

@joshtriplett Ruby menggunakan keduanya, tetapi dengan arti yang berlawanan ( .. inklusif, ... eksklusif). Saya tidak percaya itu adalah ide yang baik di Ruby, dan tampaknya lebih berpotensi membingungkan bagi kita untuk memiliki keduanya, tetapi mundur.

@joshtriplett yang paling saya kenal adalah Ruby; Saya pikir itu mendapatkannya dari Perl tetapi saya tidak sepenuhnya yakin. Saya lebih setuju dengan semantik yang mundur dari Ruby daripada saya dengan ..= .

Sejujurnya, saya lebih suka sintaks rentang inklusif yang stabil daripada yang lain, dan menyadari bahwa ketidaksukaan saya yang intens terhadap ..= adalah hal pribadi, yang mungkin tidak disetujui oleh orang-orang yang berakal.

@steveklabnik Swift menggunakan ..< , saya pikir, kan? Yang tampaknya mirip dengan ..= tetapi lebih buruk, karena mengoptimalkan (imo) kasus yang salah. =)

Swift menggunakan ..< untuk eksklusif dan ... untuk inklusif (istilah mereka adalah
"setengah terbuka" dan "tertutup").

Saya masih suka ..< (dengan .. sebagai singkatan) dan ..=.

Tapi pertanyaan terbuka lainnya (mungkin tidak dalam lingkup masalah pelacakan ini) adalah apakah kita "hanya" mengadopsi sintaks untuk rentang tertutup, atau juga sintaks (sintaks?) untuk rentang dengan titik pertama terbuka, yaitu strawman >..> dan >..=.

Pada Kam, 16 Mar 2017 pukul 14:19, Niko Matsukis [email protected]
menulis:

@steveklabnik https://github.com/steveklabnik Swift menggunakan ..<, saya pikir,
Baik? Yang tampaknya mirip dengan ..= tetapi lebih buruk, karena dioptimalkan untuk
(imo) kasus yang salah. =)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-287147321 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n0Wop5fJh9HVo7pSqo0riHm96Gm4ks5rmX1BgaJpZM4F4LbW
.

Saya tidak keberatan memiliki fungsi inclusive di awal:

for x in inclusive(1..10) {

}

Saya tidak pernah merasa simetri dengan kecocokan adalah argumen yang meyakinkan. Saya pikir kami memutuskan untuk menambahkan pola eksklusif .. , tetapi saya juga tidak menyukainya - nilai dalam pola sekarang tidak cocok dengan pola! Mencocokkan rentang pada dasarnya berbeda dari iterasi melalui rentang, tidak ada alasan mereka harus simetris. Saya akan memiliki preferensi ringan untuk tidak mengizinkan .. dalam pola jika itu masih merupakan pilihan, tetapi saya pikir tidak?

Saya merasa kerugian dengan ..= dan ... keduanya signifikan - ..= cukup aneh, tetapi ... meningkatkan kemungkinan off sebanyak 1 kesalahan.

Lebih baik memiliki operator yang tampak aneh daripada potensi bug yang tidak pernah berakhir (setiap bahasa memperkenalkan operator yang tidak dimiliki orang lain, misalnya ..< di Swift, semua operasi di F# dan Scala). Orang tetap harus membaca buku Rust.
Mempertimbangkan bahwa banyak orang datang ke Rust dari Ruby, kita seharusnya tidak mundur dibandingkan dengan Ruby. (Selain argumen bahwa ... meningkatkan kemungkinan mati sebesar 1 kesalahan.)
Bagaimana Anda bisa menerima ..< di Swift tetapi tidak menerima ..= di Rust? ..= tidak terlalu aneh.

Memperluas jangkauan sintaks dalam pola masih merupakan pertanyaan terbuka juga AFAIK.
Untuk satu hal, kami tidak dapat sepenuhnya melakukannya, karena Enum::Variant(..) sudah
valid dan mengubahnya berarti Enum::Variant(RangeFull) akan rusak.

Pada Kam, 16 Mar 2017 jam 15:07, Boscop [email protected] menulis:

Lebih baik memiliki operator yang tampak aneh (setiap bahasa memperkenalkan
operator yang tidak dimiliki orang lain, misalnya ..< di Swift, semua operasi di F#
dan Scala). Orang tetap harus membaca buku Rust.
Mengingat banyak orang datang ke Rust dari Ruby, kami
seharusnya tidak mundur dibandingkan dengan Ruby. (Selain argumen
bahwa ... meningkatkan kemungkinan mati sebesar 1 kesalahan.)
Bagaimana Anda bisa menerima ..< di Swift tetapi tidak menerima ..= di Rust?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-287160485 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3nz9ZNR2utl7LPTVvQPQ_Ma8sDBGuks5rmYhmgaJpZM4F4LbW
.

Jadi. Saya ingin dapat mengetik hal-hal seperti slice.get(10...30) dan memakan kue saya juga.

Saya telah meyakinkan diri sendiri bahwa saya lebih suka inclusive(0..10) daripada sintaks lainnya:

• Sementara @nagisa ingin menulis slice.get(10...30) , saya tidak ingin harus memperhatikan apakah itu slice.get(10...30) atau slice.get(10..30) . Saya pikir kedekatan sintaks adalah masalah nyata.
• Saya pikir semua orang setuju bahwa ..= tidak estetis dan mungkin tidak intuitif.
• (0..10).inclusive() adalah sintaks yang sama tetapi kurang nyaman. Secara teknis, pendahuluan inclusive mungkin akan mendukung kedua sintaks.

Saya pikir itu akan terlihat seperti ini:

trait IntoInclusive {
    type Inclusive;
    fn inclusive(self) -> Self::Inclusive;
}

fn inclusive<T: IntoInclusive>(range: T) -> T::IntoInclusive {
    range.inclusive()
}

Saya pikir semua orang setuju ..= tidak estetis dan mungkin tidak intuitif.

Saya pikir mengatakan itu adalah sedikit generalisasi yang berlebihan. Saya menemukan ..= lebih estetis dan intuitif daripada metode seperti inclusive() .

(Juga, kita tidak tahu seberapa besar ketidaksukaan terhadap ..= bisa merupakan upaya bawah sadar (atau sadar) untuk menemukan masalah dengan hal-hal yang bukan ... .)

.inclusive() terlalu panjang untuk sesuatu yang sering terjadi (pada catatan itu, saya juga berpikir harus ada bentuk yang lebih pendek untuk .enumerate() ).
Tetapi bahkan jika kita memiliki .inclusive() , seharusnya hanya ada satu fungsi, bukan dua.
Selain itu, tidak memiliki sintaks rentang inklusif tidak akan memungkinkan mereka untuk digunakan dalam match .
Tapi mungkin kita perlu cara untuk menentukan ekstraktor secara umum, seperti di Scala ? Sehingga tipe apa pun dapat digunakan dalam kecocokan, sehingga kecocokan itu secara implisit akan memanggil metode unapply .

(Juga, kita tidak tahu seberapa besar ketidaksukaan terhadap ..= bisa menjadi upaya bawah sadar (atau sadar) untuk menemukan masalah dengan hal-hal yang tidak ....)

Tidak ada dari saya. Ini adalah semacam tuduhan itikad buruk.

Selain itu, tidak memiliki sintaks rentang inklusif tidak akan memungkinkan mereka untuk digunakan dalam kecocokan.

Pola rentang inklusif sudah didukung di match . Faktanya, ini adalah satu-satunya rentang yang kami dukung sebagai pola hari ini.

@withoutboats ya tapi saya berkata "tidak memiliki sintaks rentang inklusif tidak akan memungkinkan mereka untuk digunakan dalam pertandingan". Saat ini ada sintaks tetapi argumen saya menentang .inclusive() karena tidak dapat digunakan dalam pertandingan kecuali kami memiliki ekstraktor seperti Scala. dan inti dari masalah ini adalah bahwa sintaks rentang inklusif tidak boleh menjadi kasus khusus yang hanya berfungsi dalam kecocokan dan untuk menentukan seperti apa sintaks tersebut alih-alih yang sekarang.

Termasuk: for i in 1..10! { }

Sebagai seseorang yang bekerja lebih dari 15 tahun dengan Java/C/C++, saya menemukan bahwa .. vs ... cukup membingungkan dan dapat menyebabkan bug hanya dengan kesalahan pengetikan. Juga hubungannya dengan Ruby membuat ini semakin membingungkan. Itulah mengapa ..= atau alternatif lain lebih baik.

melempar 'topi' saya ke atas ring:

for i in 1..10^

Topi / tanda sisipan yang melambangkan bahwa nilai yang benar berjalan sepanjang _up_.

@leebenson Secara pribadi saya pikir akan lebih baik jika itu di tengah, tidak ditempel di luar.

for i in 1..^10

@retep998 Saya menganggap bahwa setelah saya menekan kirim... itu mungkin lebih baik sebenarnya.

@retep998 Saya suka saran Anda tentang ..^ jauh lebih baik daripada ..= ; tampaknya jauh lebih menggugah maknanya, dan menghindari terlihat seperti varian aneh dari operator penugasan tambahan (seperti += dan *= ). Yang mengatakan, salah satunya akan jauh lebih baik daripada ... .

Saya tidak bisa mendapatkan di belakang ..^ .

Pada tingkat pribadi, saya merasa sangat jelek (sebagian karena .. sangat terpisah secara vertikal dari ^ dalam banyak font).

Sebagai seorang pria UI/UX, saya pikir ini adalah contoh terlalu pintar untuk kebaikan Anda sendiri.

Jika saya datang dari bahasa lain dan melihat ..^ , saya mungkin bahkan tidak mengenalinya sebagai rentang (untuk semua yang saya tahu, 5..^15 bisa menjadi singkatan faktorial parsial yang aneh untuk 15! - 4! ) karena manusia berpikir dalam konteks dan satu-satunya asosiasi yang dimiliki karakter dalam konteks pemrograman arus utama adalah eksponensial.

(Jika kita tidak berpikir dalam konteksnya, ... bisa berarti sesuatu seperti "panggilan balik dimasukkan di sini" atau "pancarkan acara" dengan analogi makna seperti "konten dihilangkan" dalam dialog dalam penulisan prosa, hanya untuk tunjukkan contoh yang paling langsung. Memberinya arti "naik ke atas" yang berarti melalui kemiripannya dengan panah adalah seperti melakukan trik sulap melalui sulap, sejauh bagaimana berinteraksi dengan harapan pendatang baru.)

Sebaliknya, = memiliki preseden untuk merujuk pada tindakan penugasan dan konsep kesetaraan dan tidak ada "sintaks eksponensial yang aneh" -seperti kesalahpahaman untuk ..= karena yang paling dekat dengan " penugasan + kesetaraan" yang belum ditangani oleh operator penugasan adalah "sesuatu yang berkaitan dengan urutan angka, berakhir di sebelah kanan"... yang merupakan definisi yang tidak jelas tetapi tepat tentang apa yang dilakukan sintaks rentang.

Saya juga khawatir bahwa, bahkan jika saya mengenali bahwa ..^ adalah sintaks rentang dari penggunaannya dalam konteks, saya tidak tahu secara intuitif apakah itu inklusif atau eksklusif pada awalnya, karena tidak ada artinya untuk ^ dalam konteks yang relevan, kecuali untuk kemungkinan bahwa 2..^8 adalah singkatan untuk rentang terbuka mulai dari dua dan melangkah dengan mengambil langkah sebelumnya ke pangkat 8. (mis. 2..Inf^8 sebagai lawan dari 2..+8 menjadi singkatan untuk "beralih dari 2 hingga tak terhingga dalam langkah 8".)

Masalah itu juga dihindari oleh ..= karena orang terbiasa berpikir dalam konteks < (eksklusif) vs. <= (inklusif) saat menulis while loop dan loop for gaya-C.

@ssokolow analisis yang sah.

Secara pribadi, saya dapat mendukung ..= atau ..^ . Simbologi keduanya masuk akal bagi saya - yaitu 'sampai dan sama dengan' atau hanya 'sampai', masing-masing. Keduanya memiliki arti yang sama, menurut saya.

Akan sulit untuk menemukan sesuatu yang memuaskan semua orang, karena kita semua membawa sejarah dari bahasa lain dan dengannya, simbologi/bias yang tercemar. Saya awalnya menambahkan tanda ^ _setelah_ nomor, misalnya, karena memasukkan sebelum memiliki perasaan mewakili 'langkah' atau eksponen, sedangkan sufiks membiarkan rentang tidak ternoda, dan entah bagaimana perasaan lebih murni. Tapi itu hanya aku.

Bagaimanapun, saya lebih suka notasi steno dalam beberapa bentuk vs pemanggilan fungsi yang secara implisit memberi +1 pada val kanan. Saya setuju dengan komentar sebelumnya bahwa ini adalah sintaks yang terlalu umum untuk didelegasikan ke sesuatu yang terasa seperti panggilan fungsi. Saya bahkan tidak keberatan ... , tapi memang, itu mungkin = / == dalam pakaian baru dan pasti akan menembak seseorang di kaki...

banyak orang tampaknya secara aktif tidak menyukai ..= tidak ada yang mengatakan sesuatu yang negatif
tentang .... itu diam-diam diabaikan (kecuali beberapa jempol) I
pikir saya akan mengungkitnya lagi dan membuat orang mempertimbangkannya dan memberikan
alasan untuk tidak menggunakannya jika mereka menentangnya.

Saya benci menyebutkannya karena itu hanya lebih berisik, tetapi bagaimana dengan .:
(titik dua) untuk inklusif? Ini 3 titik tetapi 2 karakter, dan saya pikir
bentuk membuatnya berbeda dari ..

Pada Sabtu, 18 Maret 2017 pukul 11:50, Lee Benson [email protected]
menulis:

@ssokolow https://github.com/ssokolow analisis yang sah.

Secara pribadi, saya bisa mendapatkan di belakang baik ..= atau ..^. Simbologi dari keduanya
masuk akal bagi saya - yaitu 'sampai dan sama dengan' atau hanya 'sampai',
masing-masing. Keduanya memiliki arti yang sama, menurut saya.

Akan sulit untuk menemukan sesuatu yang memuaskan semua orang,
karena kita semua membawa sejarah dari bahasa lain dan dengan itu, tercemar
simbologi / bias. Saya awalnya menambahkan tanda ^ setelah nomor, untuk
misalnya, karena memasukkan sebelumnya memiliki perasaan mewakili 'langkah'
atau eksponen, sedangkan sufiks membiarkan rentang tidak ternoda, dan entah bagaimana lebih murni
merasa. Tapi itu hanya aku.

Bagaimanapun, saya lebih suka notasi steno dalam beberapa bentuk vs a
pemanggilan fungsi yang secara implisit memberi +1 pada val kanan. Saya setuju dengan sebelumnya
berkomentar bahwa ini adalah sintaks yang terlalu umum untuk didelegasikan ke sesuatu yang
terasa seperti panggilan fungsi. Aku bahkan tidak keberatan ..., tapi memang begitu, itu
mungkin bug = / == dalam pakaian baru dan pasti akan menembak seseorang di
kaki...

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-287566556 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AIhJ6jWgPwndKaQvVjULlV_OOC6WDO0Cks5rnCeLgaJpZM4F4LbW
.

Oh, apakah ini masih dalam fase bikeshedding? 😆

Membaca kembali, saya pikir saya setuju dengan @nikomatsakis untuk membuatnya ..= dan menyebutnya sehari. Kesamaan .. vs ... terlalu halus, dan saya lebih suka melihat token ... digunakan tanpa ambiguitas untuk generik variadik (https://github.com/ rust-lang/rfcs/pull/1935), di mana ia memenuhi tujuan yang sangat berbeda yang seharusnya mengurangi kebingungan di antara keduanya.

Saya tidak yakin apakah keinginan untuk sintaks yang lebih umum untuk semua varian setengah terbuka masih ada, tapi saya pikir itu tidak sebanding dengan upaya untuk menyediakan sintaks bahasa di luar .. dan ..= .

Saya benci menyebutkannya karena itu hanya lebih berisik, tetapi bagaimana dengan .: (titik dua) untuk inklusif?

Saya pikir @ssokolow membuat beberapa poin bagus tentang: UI/menjadi pintar. Saya berpendapat bahwa mengalihkan arah titik ketiga demi mengelabui mata Anda agar melihat sesuatu yang lain mungkin termasuk dalam kategori itu.

Saya pribadi memiliki _nol_ keberatan dengan adanya titik ketiga, selain mengetahui itu pasti akan membuat beberapa orang tersandung pada akhirnya. Tapi itu juga sangat mudah untuk dijelaskan, jadi saya tidak yakin tanggung jawab harus ada pada bahasa untuk merancang solusi yang cerdas. Apakah '2 titik eksklusif; 3 titik inklusif' benar-benar _yang_ sulit dipahami/di-debug?

Bagaimanapun - siapa yang membuat keputusan akhir, dan apa langkah selanjutnya untuk menutup ini? 18 bulan membahas karakter ketiga mungkin _is_ bikeshedding pada saat ini

Setuju, ^ membuatnya terlihat seperti langkah.
IMO inkonsistensi dengan operator op= tidak masalah karena tidak mungkin kita memiliki a ..= b dalam arti a = a .. b , karena .. adalah bukan operator tetapi gula sintaksis untuk membuat Rentang (dan kami tidak memiliki skema kelebihan beban op umum di mana setiap op secara otomatis mendapatkan bentuk op= , dan .. ).
Saya tidak mengatakan ..= jelas tanpa melihat dokumen. Tetapi begitu Orang melihat dokumen itu, lebih mudah untuk menghafalnya, dan mereka tetap harus melihat dokumen itu.

Mengingat pencalonan @nikomatsakis , saya pikir kita akan membahasnya dalam pertemuan tim lang minggu depan, dan kemungkinan akan menelepon pada saat itu. Saya setuju bahwa ini hanya membutuhkan tim lang untuk menelepon dan mengakhiri pelepasan sepeda.

Saya juga khawatir bahwa, bahkan jika saya mengenali bahwa ..^ adalah sintaks rentang dari penggunaannya dalam konteks, saya tidak tahu secara intuitif apakah itu inklusif atau eksklusif pada awalnya

Sepakat. Sebenarnya, saya sudah melihat sintaks ini di Perl 6 yang artinya eksklusif, kebalikan dari proposal di sini.

@solson Itu argumen yang sangat meyakinkan untuk menentangnya.

Perl tampaknya memiliki sintaks yang sepenuhnya umum, dengan .. artinya inklusif (pada keduanya
sisi) dan ^ di kedua sisi membuat ikatan itu eksklusif.

Pada Sabtu, 18 Mar 2017 pukul 18:51, Josh Triplett [email protected]
menulis:

@solson https://github.com/solson Itu argumen yang sangat menarik
menentangnya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-287580739 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3n7Fnn1_t9BkYOhfS-7oCaGlVff2aks5rnF_5gaJpZM4F4LbW
.

Jadi, saya minta maaf untuk mengatakan, tetapi ketika kami membahas masalah ini dalam pertemuan @rust-lang/lang, kami gagal mencapai konsensus. @withoutboats khususnya memiliki beberapa reservasi parah yang mudah-mudahan mereka dapat mengudara untuk diri mereka sendiri.

Beberapa poin utama yang kami diskusikan:

• Jika kita memiliki sintaks rentang inklusif dalam ekspresi dan pola, itu harus sama
  
  
  
  • yaitu, jika kita mengadopsi x ..= y , itu berarti menghentikan sintaks pola x...y yang ada.
  
  
• Pilihan yang menggoda adalah "tidak melakukan apa-apa" dan hanya menulis (x..y).inclusive() atau semacamnya. Namun, itu tidak akan berfungsi dalam pola (yang mungkin akan tetap sebagai x...y ). Ini menimbulkan beberapa pertanyaan tersendiri:
  
  
  
  • Apakah kita masih menginginkan pola jangkauan yang eksklusif ? misalnya match 3 { 1..3 => false, .. }
    
    
    
    
    
    • Jika demikian, maka kita memiliki potensi kebingungan yang sama!
    
    
    
  
  
  • @withoutboats tampaknya berpikir bahwa mungkin kita tidak menginginkan pola seperti itu. Saya dan @joshtriplett meragukan hal ini; Saya pikir kami berdua berpendapat bahwa mereka adalah jenis hal yang tampaknya tidak relevan sampai Anda menginginkannya, dan kemudian mereka merasa sangat diperlukan . =)
  
  
• Masalah lain seputar pola rentang eksklusif adalah interaksi yang buruk dengan pola irisan (juga tidak stabil) (lihat https://github.com/rust-lang/rust/issues/23121 untuk detailnya).

Saya pikir satu hal yang keluar dari diskusi ini adalah bahwa akan baik untuk membuat keputusan tentang semua faktor yang saling bertentangan sekaligus . Dengan kata lain, untuk mengadopsi keputusan yang menetap:

• Apa yang harus dilakukan tentang ekspresi rentang eksklusif?
• Apakah kita harus mencela/mengubah pola rentang eksklusif yang ada?
• Apa yang harus dilakukan tentang pola rentang inklusif ?
• Apa yang harus dilakukan tentang pola irisan ?

Sebelum saya memulai tulisan ini, saya ingin mengatakan bahwa saya merasa sangat tidak yakin bahwa setiap saat dalam percakapan kami semua sebenarnya membicarakan konsep yang sama. Misalnya, Niko mengatakan bahwa "pola rentang eksklusif tampaknya tidak relevan sampai Anda menginginkannya", tetapi saya pikir Niko dan Josh sedang membicarakan ekspresi rentang inklusif pada saat itu.

(Dan saya pikir di bagian terakhir posting Niko, butir pertama yang saat ini berbunyi "ekspresi rentang eksklusif" harus mengatakan "ekspresi rentang inklusif".)

TL;DR pendapat saya

Tentang ekspresi rentang:

• Kami tidak boleh memperkenalkan sintaks apa pun untuk ekspresi rentang inklusif - baik ... maupun ..= .
• Kita harus menambahkan ke fungsi pendahuluan yang mengambil nilai rentang eksklusif dan mengembalikan nilai rentang inklusif. Jadi, Anda akan menulis inclusive(0..10) (namanya bisa diganti dengan sepeda).

Tentang pola rentang:

• Kami tidak boleh memperkenalkan pola rentang eksklusif, atau cara apa pun untuk membuatnya.

Dengan kata lain, satu-satunya perubahan material yang harus kita lakukan adalah perubahan libs: tambahkan fungsi ke pendahuluan.

Ekspresi rentang

Dasar argumen saya adalah fakta bahwa iterasi melalui nilai rentang inklusif adalah kebutuhan yang tidak biasa. Saya pikir ini dibuktikan oleh fakta bahwa meskipun RFC diterima 18 bulan yang lalu, kami masih belum menstabilkan fitur ini - bukan karena masalah implementasi tetapi karena kami tidak senang dengan pertukarannya.

Saya pikir ekspresi rentang inklusif diperlukan cukup sering sehingga kita harus mendukung cara langsung untuk membuatnya, tetapi tidak cukup sering sehingga mereka mengatasi salah satu kelemahan sintaks yang telah kita diskusikan sejauh ini.

Secara khusus, kelemahan yang dimiliki setiap solusi sintaksis adalah tidak ada satupun dari mereka yang benar-benar mendokumentasikan diri sendiri. Relatif tidak jelas bahwa 0...10 atau 0..=10 adalah ekspresi rentang inklusif . Karena mereka relatif jarang ditemui, ini akan menjadi batu sandungan bagi pengguna yang pertama kali bertemu dengan mereka.

Yaitu, jika pengguna bahkan memperhatikan bahwa mereka tidak berurusan dengan rentang .. "normal". Tentu saja, ini adalah masalah besar dengan ... , tetapi ..= tidak sepenuhnya menghilangkan masalah. Sangat mudah, ketika menelusuri kode, untuk melewatkan satu karakter = (atau ^ atau : atau apa pun). Tidak semudah tambahan . , tapi saya tidak yakin itu cukup terlihat.

Saya benar-benar berpikir bahwa ada "keterlihatan vs kejelasan" trade off antara ... dan ..= . Saya pikir itu lebih jelas apa artinya ... (kecuali Anda berasal dari Ruby, di mana kedua sintaks memiliki arti yang berlawanan) daripada ..= , tetapi jelas kurang terlihat .

Tapi saya pikir fungsi pendahuluan seperti inclusive(0..10) lebih jelas dan lebih terlihat daripada sintaks apa pun yang telah kita diskusikan. Ya, karakternya lebih banyak untuk diketik, tetapi kelemahan atribut itu relatif terhadap frekuensi penggunaan.

Ini juga menghindari masalah penguraian & tokenisasi, dan membantu pengguna dengan masalah prioritas metode vs rentang (sangat mengganggu) yang mengharuskan mereka menulis (0..10).filter dan semacamnya.

Pola jangkauan

Alasan utama saya pikir kita tidak boleh menambahkan .. adalah karena ini memperkenalkan ambiguitas di sekitar pola irisan, yang menurut saya berguna. Saya ingin memecahkan masalah itu dengan tidak harus menyelesaikannya.

Alasan kedua adalah menurut saya gaya mereka sangat buruk (saya tahu orang lain tidak setuju). Sebagai contoh:

if let 1..10 = x { .. }

Saya pikir ini membingungkan, karena 10 tidak cocok dengan pola yang memuatnya. Niko menyebutkan bahwa ini tidak benar-benar berbeda dari ekspresi rentang eksklusif yang tidak menghasilkan 10 , tetapi saya pikir perbedaan besar adalah bahwa kami memiliki banyak preseden sejarah gaya Dijsktra (dan kasus penggunaan) untuk mendukung eksklusif rentang. Datang ke Rust, saya mengharapkan rentang iteratif & slicing menjadi eksklusif, tetapi saya tidak memiliki harapan itu untuk pola.

Ini juga memiliki masalah "off-by-one" yang dimiliki .. / ... dalam ekspresi.

Saya tahu Niko telah menyebutkan bahwa dia ingin menulis:

match x {
    0..10 => { ... }
    10..20 => { ... }
}

Tapi saya sangat ingin melihat:

match x {
    0...9 => { ... }
    10...19 => { .. }
}

Bagaimanapun, saya terkejut bahwa Niko bermaksud bahwa dia kadang-kadang menganggap ini "sangat diperlukan", jadi saya ingin mendengar lebih banyak argumen balasan. Karena mereka harus menjadi constexpr, tampaknya lebih seperti 'baik untuk dimiliki' daripada 'mutlak diperlukan' bagi saya.

Saya benar-benar merasa lebih mudah untuk terpengaruh pada pola rentang eksklusif daripada ekspresi rentang inklusif.

Argumen konsistensi

Niko menyebutkan bahwa memiliki .. dan ... dalam ekspresi dan pola penting baginya karena konsistensi. Saya pada dasarnya sama sekali tidak tergerak oleh argumen ini. Iterasi melalui rentang dan pencocokan pada rentang bukanlah operasi yang benar-benar analog, dan masuk akal bahwa akan ada perbedaan antara cara kita memperlakukannya.

Memang, bahkan tidak ada implementasi connect: 1..10 menghasilkan nilai Range, sedangkan 1...10 cocok dengan nilai integer. Ini tidak seperti mereka memiliki koneksi penataan/penghancuran seperti yang dilakukan sebagian besar sintaks ekspresi/pola simetris kami.

Tampaknya lebih tepat secara teknis untuk menyebut pola "pola domain" daripada "pola rentang" , yang menyoroti ketidaksamaan.

@tanpa perahu

Misalnya, Niko mengatakan bahwa "pola rentang eksklusif tampaknya tidak relevan sampai Anda menginginkannya", tetapi saya pikir Niko dan Josh sedang membicarakan ekspresi rentang inklusif pada saat itu.

Bagi saya, saya telah menemukan rentang eksklusif dan inklusif yang diperlukan pada berbagai waktu (meskipun saya telah menggunakan eksklusif untuk kedua kasus untuk bekerja pada Rust yang stabil, dan harus mengatasinya dengan +1 di bagian atas melompat). Saya ingin mereka tersedia untuk pola dan ekspresi.

Yang mengatakan, secara pribadi, saya tidak akan keberatan menggunakan fungsi untuk rentang inklusif, kecuali bahwa saya ingin memiliki cara untuk menulis rentang inklusif dan eksklusif dalam pola , dan saya ingin kedua sintaks tersebut tidak terlihat mirip secara membingungkan seperti yang dilakukan .. dan ... . Dan diberikan sintaks untuk menulis rentang seperti itu dalam pola, saya tidak tahu bahwa masuk akal untuk memiliki sintaks yang berbeda untuk rentang seperti itu dalam ekspresi.

Secara khusus, kelemahan yang dimiliki setiap solusi sintaksis adalah tidak ada satupun dari mereka yang benar-benar mendokumentasikan diri sendiri. Relatif tidak jelas bahwa 0...10 atau 0..=10 adalah ekspresi rentang inklusif. Karena mereka relatif jarang ditemui, ini akan menjadi batu sandungan bagi pengguna yang pertama kali bertemu dengan mereka.

Saya setuju dengan ini. Ini cukup jarang muncul sehingga saya tidak keberatan dengan sintaks yang kurang ringkas. Namun, saya ingin memiliki beberapa mekanisme untuk menulis rentang inklusif dan eksklusif dalam ekspresi dan pola.

Saya tidak keberatan, misalnya, jika menulis pola rentang inklusif memerlukan makro atau serupa.

@joshtriplett Di sinilah saya ingin menjadi sangat jelas, ketika Anda mengatakan ini:

Saya telah menemukan rentang eksklusif dan inklusif yang diperlukan pada berbagai waktu (meskipun saya telah menggunakan eksklusif untuk kedua kasus untuk bekerja pada Rust yang stabil, dan harus mengatasinya dengan +1 di batas atas).

Tampaknya jelas Anda berbicara tentang ekspresi , tetapi bagian yang Anda kutip adalah tentang pola (saya tahu Anda berbicara tentang pola di paragraf berikutnya, tetapi saya bertanya tentang masalah "kebutuhan" yang tidak dibahas oleh paragraf itu ) .

Status quo untuk pola adalah bahwa kami hanya mendukung pola rentang inklusif, dalam bentuk x...y . Bisakah Anda berbicara lebih banyak tentang jika/ketika Anda menemukan pola rentang eksklusif yang benar-benar membuat frustrasi untuk tidak dimiliki?

@tanpa perahu

Bisakah Anda berbicara lebih banyak tentang jika/ketika Anda menemukan pola rentang eksklusif yang benar-benar membuat frustrasi untuk tidak dimiliki?

Sesuatu seperti

    match offset {
        0x0200 .. 0x0280 => { /* GICD_ISPENDR<n> */ }
        0x0280 .. 0x0300 => { /* GICD_ICPENDR<n> */ }
        0x0300 .. 0x0380 => { /* GICD_ISACTIVER<n> */ }
        0x0380 .. 0x0400 => { /* GICD_ICACTIVER<n> */ }
        0x0400 .. 0x0800 => { /* GICD_IPRIORITYR<n> */ }
    }

vs

    match offset {
        0x0200 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0x0280 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0x0300 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0x0380 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0x0400 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

Saya tidak akan mengatakan itu sangat membuat frustrasi, tetapi yang pertama pasti terlihat lebih bagus.

@withoutboats Untuk kejelasan, di berbagai waktu saya menginginkan ekspresi rentang eksklusif, ekspresi rentang inklusif, dan pola rentang inklusif. Saya tidak dapat begitu saja memikirkan waktu di mana saya sangat peduli untuk memiliki pola jangkauan eksklusif, meskipun saya juga tidak akan menolaknya. Tetapi bahkan jika kita tidak memiliki pola rentang eksklusif, saya masih akan sangat membingungkan jika pola rentang inklusif menggunakan ... dan ekspresi rentang eksklusif menggunakan .. .

@petrochenkov Saya berasumsi itu dimaksudkan untuk diakhiri dengan F , bukan C ?

Saya mengalami kasus yang sama dengan pola rentang hex, misalnya 0x8000...0x9FFF => /* body */ . Saya menemukan bahwa 0x8000..0xA000 memiliki properti yang sedikit lebih intuitif, seperti tanpa harus memikirkannya, saya langsung melihat bahwa ukuran rentang adalah 0xA000 - 0x8000 = 0x2000 dan rentang berikutnya yang berdekatan dimulai dari 0xA000 .

Berurusan dengan +1 diperlukan untuk melihat fakta-fakta ini dalam rentang inklusif adalah perbedaan kecil yang dapat saya jalani, tetapi rentang eksklusif (baik pola dan ekspresi) biasanya lebih sesuai dengan pekerjaan saya.

@petrochenkov Saya dapat melihat mengapa Anda lebih suka rentang eksklusif untuk hexdigits (saya mungkin masih tidak, tetapi ini terasa seperti kesepakatan yang sangat YMMV).

Bagaimana kita menangani ambiguitas sintaks slice?

@joshtriplett

Saya masih akan sangat membingungkan jika pola rentang inklusif menggunakan ... dan ekspresi rentang eksklusif menggunakan .. .

Beginilah cara Rust bekerja hari ini dan sepertinya itu bukan sumber kebingungan yang signifikan?

@solson

Saya berasumsi itu dimaksudkan untuk berakhir di F, bukan C?

Tidak :)
(Hal-hal itu 32-bit dan offset adalah kelipatan empat.)

@tanpa perahu

Saya dapat melihat mengapa Anda lebih memilih rentang eksklusif untuk hexdigit (saya mungkin masih tidak, tetapi ini terasa seperti kesepakatan yang sangat YMMV).

Saya harus mencatat, ini bukan preferensi yang kuat, saya masih akan baik-baik saja dengan menjatuhkan pola eksklusif dan rentang inklusif (tetapi bukan salah satunya, itu akan terlalu konyol).

Bagaimana kita menangani ambiguitas sintaks slice?

Mudah! PATTERN.. => .. @ PATTERN

Alasan utama saya menginginkan rentang inklusif menjadi sederhana adalah bahwa saya telah mengalami situasi lebih dari sekali di mana saya memberikan nilai berhenti dalam suatu variabel dan itu persis nilai maksimum yang dapat dimiliki oleh satu jenis variabel, jadi satu-satunya solusi untuk mengesampingkan overflow pada waktu kompilasi adalah:

1. Menggunakan rentang inklusif (terbersih, tetapi tidak stabil)
2. Upcasting sebelum + 1 (mengasumsikan saya belum menggunakan u64 dan tidak elegan)
3. Mengambil nilai yang lebih rendah dan minus satu maksimum untuk rentang, lalu menjalankan tugas sekali lagi jika sesuai.

Membangun kebiasaan menggunakan rentang inklusif daripada menambahkan + 1 ke algoritme yang tidak memiliki tujuan bawaan adalah cara non-sepele untuk menjaga agar tidak menemukannya lagi nanti di cargo fuzz ... fungsi "jadikan inklusif dari eksklusif" dengan lebih banyak karakter pada namanya daripada + 1 memberi kesan bahwa rentang inklusif adalah hal yang luar biasa, daripada sesuatu yang seharusnya biasa Anda gunakan.

Itulah salah satu alasan terbesar saya menentangnya. Ini menyampaikan kesan bahwa rentang inklusif adalah peretasan, untuk digunakan ketika rentang eksklusif terbukti gagal.

@ssokolow tetapi use case itu ditutupi dengan nyaman oleh fungsi pendahuluan. Tidak ada yang mengambil posisi bahwa seharusnya tidak mungkin membuat rentang inklusif, hanya apakah mereka harus memiliki gula sintaksis untuk membuatnya atau tidak.

Saya suka ide @withoutboats tentang fungsi pendahuluan. Saya pikir tempat lain di mana rentang inklusif mungkin lebih umum adalah ketika Anda tidak menggunakan bilangan bulat, misalnya, dengan menentukan batas pencarian di btree (atau struktur data serupa).

@withoutboats Saya mengedit sedikit ke posting saya saat Anda merespons, tetapi inti dari apa yang saya tambahkan adalah membuat rentang inklusif warga negara kelas dua, secara sintaksis (dengan sintaks yang lebih panjang daripada menambahkan + 1 ke rentang eksklusif ), terasa seperti keputusasaan halus untuk tidak menggunakannya dan kemungkinan footgun "Sampai jumpa di cargo fuzz nanti".

Jika tidak ada yang lain, itu adalah kutil yang bisa diajar.

Rust bukan Python 3.x, dengan dukungan integer tak terbatasnya. Rust tidak menyembunyikan pertukaran perangkat keras dari pengguna, dan saya melihat ..= saya lebih suka hanya sebagai bagian dari menggunakan u32 dan teman-teman daripada int . (Terutama mengingat bahwa kesalahan overflow/underflow adalah hal yang paling umum pada "kotak piala" cargo fuzz sejauh ini.)

EDIT: Harap abaikan bit apa pun yang hanya Anda lihat di notifikasi email untuk ini. Saya baru saja bangun dan saya belum menembak semua silinder.

Saya tidak melihat inclusive(n..m) sebagai keputusasaan sama sekali... Saya lebih suka menulisnya karena ini adalah konstruksi yang sangat jelas yang membuat kode saya lebih mudah dibaca daripada n..(m + 1) dan n..=m (yang saya anggap tidak perlu terlihat aneh ketika kita hanya bisa mengucapkan kata "inklusif").

n..=m lebih merupakan kutil yang dapat diajar daripada inclusive(n..m) IMO.

Saya pikir untuk pertandingan ada keinginan untuk memiliki cakupan lengkap dari rentang numerik, daripada jenis pola tertentu.

Agaknya jika ada sintaks "lanjutkan dari sebelumnya", itu juga akan menyelesaikan masalah.

BTW, karena hanya pola pertama yang cocok, nomor awal sering kali dapat dihilangkan:

    match offset {
        0 ... 0x01FF => {}
        0 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

Saya mengakui bahwa ini mungkin masalah perspektif, tetapi:

1. Ketika saya melihat .. dan ..= , saya berpikir "Hah. Saya bertanya-tanya mengapa mereka memiliki dua sintaks untuk perbedaan kecil", yang kemudian akan mengarahkan saya untuk mencari dokumen yang dapat fokus " 1..pivot dan pivot..end " vs. " x..=y mana y mungkin merupakan nilai maksimum yang mungkin".

2. Sebelum saya cukup berpengalaman untuk terbiasa berpikir dalam hal ukuran variabel, saya baru saja menggunakan + 1 lebih dari inclusive() (jika saya bahkan mencarinya), karena saya telah menggunakan + 1 sejak sekolah dasar, pendek dan mudah diketik, dan diri saya yang tidak berpengalaman terbiasa bekerja dalam bahasa seperti Python dan JavaScript di mana penambahan yang menyebabkan luapan bukanlah sesuatu yang dikhawatirkan orang.

EDIT: ... dan perbedaan konseptual dalam poin 1 itulah yang menurut saya harus kita fokuskan. (yaitu. Bahwa "dari X ke pivot" dan "dari X ke akhir" harus berbeda dalam pikiran programmer.)

@pornel
Ini mengerikan
Dalam kasus khusus ini, rentang awal sangat penting bagi seseorang yang membaca kode, jauh lebih penting daripada masalah rentang inklusif/eksklusif.

@ssokolow menurut saya apa yang membuat +1 menjadi masalah bukanlah jumlah karakter tetapi Anda harus menangani potensi overflow. Juga tidak mengomunikasikan maksud, dan membutuhkan orang tua yang didahulukan. Ini semua tampak jauh lebih penting daripada jumlah karakter.

Memang benar seseorang yang tidak tahu tentang overflow mungkin mencapai +1 sebelum membuat rentang inklusif, tetapi ini tampaknya tidak bergantung pada sintaks. Keduanya menemukan bahwa ..= adalah sesuatu dan bahwa inclusive() adalah sesuatu yang menghadirkan momen yang dapat diajarkan untuk mempelajari mengapa Anda menginginkan rentang inklusif secara khusus.

@petrochenkov

Saya masih akan baik-baik saja dengan menjatuhkan pola eksklusif dan rentang inklusif (tetapi bukan salah satunya, itu akan terlalu konyol) .

Bisakah Anda menjelaskan mengapa Anda merasa begitu kuat tentang hal ini? Saya benar-benar melihat menerima pola eksklusif hanya memiliki kelemahan karena mungkin membuat pengguna mengharapkan 0...10 sebagai ekspresi, tetapi tampaknya tidak terlalu buruk bagi saya.

Bagian dari masalah saya dengan inclusive() adalah bahwa itu "hanya" sebuah fungsi dan saya khawatir orang akan melakukan hal-hal seperti pergi ke indeks sintaks Rust, mencari "rentang" atau "iterator" dan kemudian mengasumsikan ROI yang tidak mencukupi untuk "Melihat [ing] Iterator".

("Saya tidak ingin membaca buku teks jika saya menemukan sesuatu yang berguna... Saya hanya ingin mengulangi suatu rentang dan kembali membuat kemajuan.")

@withoutboats Jika kami memiliki inklusif(a..b), tetapi kami tidak dapat menggunakannya dalam pertandingan, itu tidak layak IMO.
Sebagian besar waktu ketika saya menggunakan rentang inklusif, itu dalam pola yang cocok!
Jadi mengapa kita tidak bisa menghapus ... dan hanya menggunakan ..= di dalam dan di luar pertandingan?

@Boscop proposalnya bukan untuk menghapus ... dalam kecocokan, tetapi untuk meninggalkan pola persis bagaimana mereka stabil.

@ssokolow sepertinya itu bisa diselesaikan dengan cukup mudah dengan catatan di bagian ..

@withoutboats Tapi mengapa tidak menghapus ... dalam pertandingan dan menggunakan ..= sebagai gantinya, jadi itu konsisten?
(sehingga menjadi ..= di dalam dan di luar pertandingan)

Untuk cakupan rentang numerik dalam floating point, bantuan eksklusif. Misalnya, salah satu dari batas-batas ini tertutup sepenuhnya, tetapi tidak yang lain:

match x {
    0.0...3.141592653589792 => 1,
    3.141592653589793...6.283185307179585 => 2,
    6.283185307179586...10.0 => 3,
    _ => 4,
}

Dan menulisnya dengan tumpang tindih malah terasa menjijikkan (dan secara moral mirip dengan "mulai saja semuanya dari -∞ karena lengannya dipesan" di atas). Lihat juga waktu tanggal, seperti bagaimana ISO8601 mengizinkan T24:00, karena hari adalah [00:00, 24:00), bukan [00:00, 23:59:59]. Atau string, atau rasional, atau ...

Diberi pilihan hanya eksklusif atau hanya inklusif, saya akan mengambil eksklusif setiap saat.

(Selain: Pola 1 <= x <= N untuk pengindeksan sebenarnya lebih baik dilakukan sebagai 0 < x <= N , yang juga eksklusif--meskipun setengah tertutup daripada setengah terbuka--untuk alasan yang sama dikatakan Dijkstra, hanya beralih untuk pengindeksan berbasis 1 alih-alih berbasis 0.)

Operator ini akan sangat membantu fungsi penjepit yang saya usulkan di sini: https://github.com/rust-lang/rfcs/pull/1961 namun karena ini belum distabilkan, saya mungkin harus mengubah proposal itu menjadi gunakan dua argumen min dan max sebagai gantinya. InclusiveRange sangat membantu ketika bekerja dengan nilai floating point juga sehingga kita tidak perlu melakukan sesuatu seperti:

0.0..1.0+EPSILON

Saya bahkan tidak yakin apakah itu benar, tetapi saat ini sangat sulit untuk mendeklarasikan rentang inklusif angka floating point.

Cara yang benar untuk melakukan ini adalah dengan nextafter , bukan epsilon. yaitu x...y == x..nextafter(y) . peti ieee754 memperlihatkan fungsi seperti itu

Ups, saya membuat komentar tentang sintaks inclusive(a..b) tetapi saya menyadari itu tidak benar. Bagaimanapun, saya menyukainya tetapi saya harap kami dapat bersepeda dengan nama yang lebih baik.

@durka Nama itu tampak jelas bagi saya. Bisakah Anda menguraikan kekhawatiran Anda dengannya?

Jadi untuk rentang inklusif kita akan memiliki a ... b di match dan inclusive(a..b) luar kecocokan?
Mengapa kita tidak bisa konsisten dan memiliki a ..= b mana-mana?

Apakah ada sesuatu yang menghalangi ops::{RangeInclusive, RangeToInclusive} untuk distabilkan secara formal?

Saat ini sepertinya pemblokir utama adalah perdebatan tentang sintaks, meskipun terlepas dari perdebatan itu, saya cukup yakin bahwa rentang inklusif akan ada terlepas dari apa sintaks akhirnya.

Akan menyenangkan memiliki tipe ini untuk diimplementasikan oleh pustaka stabil, dan kemudian konsumen pustaka ini dapat memutuskan untuk mengaktifkan tanda fitur jika mereka ingin menggunakan sintaks khusus.

Satu hal yang saya perhatikan tentang RangeInclusive tempo hari: sulit untuk dikodekan jika Anda mencoba menerima rentang. Utas penjepit berbicara tentang mengizinkan .clamp(1...9) , tetapi kodenya akhirnya terlihat seperti ini:

    fn clamp(self, r: RangeInclusive<Self>) -> Self where Self : Sized {
        match r {
            RangeInclusive::Empty { .. } =>
                panic!("Cannot clamp to an empty range"),
            RangeInclusive::NonEmpty { start, end } => {
                assert!(start <= end, "Cannot clamp to a degenerate range");
                if self < start { start }
                else if self > end { end }
                else { self }
            }
        }
    }

Perlu berurusan dengan RangeInclusive::Empty rasanya tidak perlu karena tujuannya hanya untuk menerima pasangan dengan sintaks yang bagus. Jika itu bukan enum, itu bisa saja fn clamp(self, RangeInclusive { start, end }: RangeInclusive<Self>) , dan jauh lebih bersih.

Sayangnya saya tidak memiliki jawaban yang baik untuk apa yang harus dilakukan tentang hal itu, karena membutuhkan .into_iter() pada inklusif tetapi tidak eksklusif juga akan disayangkan...

Ide acak: Melihat bagaimana sintaks pola ... tidak benar-benar terkait dengan tipe rentang inklusif, kami mungkin mempertimbangkan untuk menghentikan sintaksnya demi sintaks yang tidak terkait dengan ... diusulkan di sini.

Karena pola rentang inklusif lebih terkait erat dengan pola | , |... bisa menjadi kandidat yang baik:

match {
    1 | 2 | 3 => ...
    1 |... 3  => ...
}

Hasil akhirnya adalah sintaks rentang inklusif dan eksklusif tidak memiliki hubungan 1:1 dengan pencocokan pola lagi, dan dengan demikian tidak perlu konsisten dengannya.

@scottmcm

Sayangnya saya tidak memiliki jawaban yang baik untuk apa yang harus dilakukan tentang hal itu, karena membutuhkan .into_iter() pada inklusif tetapi tidak eksklusif juga akan disayangkan...

Mungkin kita bisa menambahkan pembantu seperti range.nonempty() yang panik untuk rentang kosong, dan mengembalikan sepasang?

Atau kita bisa mengimplementasikan IntoIterator untuk RangeInclusive dan itu tidak akan terlalu jauh dari IMHO.

Kasus penggunaan apa yang dilayani RangeInclusive::Empty? Mengapa rentang inklusif membutuhkan kemampuan untuk mewakili rentang kosong? Bagaimana Anda akan menulis satu? (Perhatikan bahwa Anda sudah dapat menulis hal-hal seperti "rentang dari 5 hingga 4, inklusif", yang mungkin dianggap kosong oleh iterasi.)

@joshtriplett kasus utama meluap, meskipun ada cara untuk memecahkan masalah itu.

@joshtriplett start > end sebenarnya tidak berfungsi untuk mewakili rentang inklusif kosong dalam satu kasus penting: 0u8...255u8 . Ketika Anda masuk ke 255u8...255u8 dan mencoba .next() itu, Anda akan menjadi panik atau membungkus 0u8...255u8 , yang tidak kosong. Jadi alih-alih kita beralih ke varian Empty pada saat itu.

@solson Ah, begitu. Ya, itu menyebalkan, dan ini adalah salah satu kasus penggunaan terbesar untuk rentang inklusif.

(Saya berasumsi maksud Anda 255u8 dalam semua kasus itu.)

(Saya berasumsi maksud Anda 255u8 dalam semua kasus itu.)

Ya terima kasih. Diedit.

@solson namun, kasus ini dapat diperbaiki dengan menukar 0 dan 255 dalam kasus itu

@clarcharr Itu benar. Karena .next() selalu harus membuat kasus khusus pembuatan rentang Empty , itu selalu bisa menghasilkan rentang yang akan diperlakukan sebagai kosong.

Secara pribadi saya lebih suka cara itu karena tidak melibatkan rentang kosong.

Jadi utas ini telah berlangsung selama satu setengah tahun sekarang. Saya baru saja selesai membaca semuanya dan ingin memposting rekap singkat untuk pendatang baru dan semoga membantu kami mengambil keputusan:

Apa yang dilakukan Rust Stable hari ini:

0..5 mewakili rentang setengah terbuka, [0, 1, 2, 3, 4] yang tidak dapat digunakan dalam pencocokan pola
0...5 mewakili rentang tertutup [0, 1, 2, 3, 4, 5] yang hanya dapat digunakan dalam pencocokan pola.

Beberapa bentuk telah diusulkan untuk sintaks rentang tertutup tambahan yang dapat digunakan di luar pencocokan pola. Saya akan membahas masing-masing dan kelebihan dan kekurangannya.

0...5

Kelebihan: Konsisten dengan sintaks pencocokan pola yang ada, membuat bahasa terasa lebih kohesif dengan asumsi tidak ada perubahan yang dilakukan pada sintaks pencocokan pola.

Kekurangan: Mudah salah ketik dan disebabkan oleh satu kesalahan, juga mudah salah memahami maksud karena bahasa lain menggunakan operator ini untuk mengomunikasikan konsep yang berbeda.

0..=5

Kelebihan: Lebih sulit untuk salah ketik, lebih jelas secara semantik

Cons: Tidak konsisten dengan sintaks pencocokan pola yang ada. Dapat menyebabkan pengguna bertanya: Mengapa ... di sini tapi ..= di sini?

0..^5

Sangat mirip dengan ..= tetapi memiliki con tambahan yang terlihat seperti operator eksponensial.

inclusive(0..5)

Kelebihan: Sangat jelas secara semantik. Tidak akan salah ketik.

Kontra: Agak panjang. Juga tidak konsisten dengan sintaks pencocokan pola.

0....5

Kelebihan: Menghindari masalah salah ketik ... juga

Cons: Semantik yang buruk, tidak konsisten dengan sintaks pencocokan pola dan mirip dengan sintaks pencocokan pola.

[0..5] Tidak dapat digunakan. tanda kurung sudah memiliki makna sintaksis dalam bahasa tersebut.

0..<=5 Tidak dapat digunakan. Konflik dengan sintaks yang ada untuk membandingkan nilai dengan rentang.

Setiap opsi yang terdaftar yang memiliki kontra "tidak konsisten dengan sintaks pencocokan pola" dapat ditingkatkan jika kita mengubah sintaks pencocokan pola, tetapi rute tersebut memiliki masalah kompatibilitas mundur. Atau kita juga bisa membuat ... dan (pilih sintaks Anda di sini) setara dalam pencocokan pola untuk menghindari rusaknya kompatibilitas mundur, tetapi mencegah penggunaan ... luar pencocokan pola. Mungkin kami juga dapat memperbarui panduan gaya untuk mencegah penggunaan ... dalam pencocokan pola jika kami menggunakan rute itu.

Ada juga beberapa diskusi tentang membuat sintaks rentang tujuan yang lebih umum yang akan memungkinkan Anda untuk membuat batas atas dan bawah inklusif atau eksklusif, tetapi kami mungkin bahkan tidak memerlukan sintaks itu karena memiliki rentang setengah terbuka dan tertutup kemungkinan mencakup lebih dari 99,9999% kasus penggunaan.

Saya mencoba untuk mewakili diskusi ini sebaik mungkin. Jika Anda merasa saya tidak mengungkapkan maksud Anda secara memadai, beri tahu saya agar saya dapat memperbarui ini.

@Xaeroxe Terima kasih atas ringkasan yang luar biasa.

Mungkin ada alat (mungkin plugin rustfmt) yang secara otomatis mengonversi sumber dari menggunakan ... dalam pencocokan pola ke sintaks baru (mis. ..= ) ketika itu diputuskan.
Dengan begitu kita tidak akan tertahan oleh "semua kode yang ditulis dengan cara lama"..
Tapi itu harus dipanggil dengan niat dari penulis proyek dan harus ada pemberitahuan / headline di semua media karat sehingga semua orang mengetahui perubahannya.
Dengan hal-hal itu saya pikir tidak ada masalah untuk mengubah sintaks ... dalam pencocokan pola ke sintaks baru.

Saya pikir satu hal yang bisa kita lakukan untuk mengatasi masalah sintaks hanya menstabilkan RangeInclusive, seperti yang disarankan @clarcharr . Ini akan membuka blokir orang setidaknya.

Kita juga bisa menambahkan fungsi inclusive (baik hanya ke std::range atau mungkin juga ke pendahuluan); ini tidak menghalangi memiliki sintaks kelas satu suatu hari nanti tetapi membuatnya jauh lebih nyaman untuk membangun RangeInclusive sekarang.

Namun, semua ini tampak seperti keputusan lib jadi saya tidak tahu apakah tim lang memiliki yurisdiksi untuk memutuskan untuk menstabilkan/menambahkan item ini .

Saya pribadi lebih suka mengonversi RangeInclusive itu sendiri menjadi sesuatu yang tidak memiliki varian Empty , kemudian membuat IntoIter memiliki varian. Lebih masuk akal bagi saya mengingat bagaimana pada dasarnya tidak mungkin untuk membuat rentang kosong tanpa secara manual Empty { at } .

Atau, tukar MAX dan MIN pada satu kasus tepi yang saya sebutkan. Itu membuat lebih sulit untuk menulis kode yang lebih umum yang melibatkan RangeInclusive , tetapi sepertinya solusi yang masuk akal untuk masalah ini.

Terlepas dari apa yang terjadi, saya sangat mendukung stabilisasi tipe di perpustakaan standar, yang akan ada terlepas dari masalah sintaks. Hal ini memungkinkan perpustakaan untuk menulis kode stabil yang memungkinkan pemotongan dengan rentang inklusif, sehingga pada saat sintaks stabil, orang telah menerapkan kode yang menggunakan tipe. Sintaks dan tipe berada di bawah tanda fitur yang berbeda karena suatu alasan.

@scottmcm Saya setuju bahwa mungkin harus menjadi utas terpisah pada saat ini.

Dalam upaya untuk menjaga diskusi sintaks bergerak maju, saya akan menawarkan rute yang saya lebih suka untuk ambil.

Saya paling menyukai sintaks ..= , jadi saya merasa kita harus menambahkan gula sintaksis ini sama dengan ... dalam pencocokan pola dan sebagai InclusiveRange di luar pencocokan pola. Kemudian untuk menjaga konsistensi bahasa, kita harus mencoba dan memigrasikan pengguna dan kode mereka ke sintaks ..= dalam pola, menggunakan pengumuman dan alat otomatis. Setelah kami merasa telah memindahkan cukup banyak pengguna dari ... kami dapat menggunakannya sebagai peringatan kompiler dan akhirnya (mungkin bahkan bertahun-tahun dari sekarang) kesalahan kompiler.

Sudah 24 hari sejak proposal saya diberikan dan tidak ada komentar yang diberikan. Haruskah kita bergerak maju dengan rencana itu?

EDIT: Di ponsel saya tidak melihat jempol ke bawah, jadi saya tidak menyadari ada perbedaan pendapat.

@Xaeroxe saya rasa tidak. Saya tidak setuju bahwa mencela ... demi ..= adalah pilihan yang baik karena alasan yang telah saya posting di utas ini. Saya tidak menjawab proposal spesifik Anda karena ide yang sama telah diajukan dan didiskusikan. Satu-satunya hal yang jelas di sini adalah bahwa kita tidak memiliki konsensus. Saya pikir banyak dari kita merasa lelah dengan diskusi.

EDIT: Untuk lebih spesifik, saya tidak ingin mencela ... demi ..= karena:

• Menghentikan sintaks adalah biaya yang sangat besar dalam churn; bahkan jika saya benar-benar menyukai ..= Saya tidak berpikir itu akan sepadan dengan siklus penghentian hanya untuk mendapatkan ekspresi rentang inklusif pada stabil.
• Saya tidak suka ..= , saya pikir itu tidak jelas dan tidak jelas; itu memiliki keuntungan yang kecil kemungkinannya untuk menyebabkan satu kesalahan tetapi itu tidak berarti pengguna, melihatnya untuk pertama kali, akan tahu apa yang mereka lihat.
• Saya tidak setuju dengan premis bahwa perlu ada simetri antara pola dan ekspresi di sini, karena mereka tidak melakukan operasi penataan/penghancuran analog apa pun.

(Saya sedikit mengubah pandangan selama komentar ini, saya memutuskan untuk meninggalkan semuanya sehingga orang lain dapat melihat proses pemikiran saya dan mengapa saya sampai pada kesimpulan yang saya lakukan)

Saya tidak bisa mengomentari biaya penghentian karena kurangnya pengalaman saya dengan hal-hal seperti itu. Namun saya masih mendukung ..= .

Saya pikir pada titik tertentu kita harus bersedia meminta pengguna untuk mempelajari sesuatu. Pemrograman secara keseluruhan adalah sesuatu yang harus dipelajari, sintaks khusus secara umum selalu datang dengan biaya semantik. Saya tidak berharap orang mengenali sintaks pada pandangan pertama, .. sama buruknya dalam hal ini.

Namun memiliki sintaks khusus yang berlebihan dapat menghasilkan bahasa yang terlihat lebih dekat dengan brainfuck daripada yang kita inginkan untuk Rust. Jadi kita harus berhati-hati bahwa kasus yang kita pilih untuk diubah menjadi sintaks khusus sebenarnya cukup umum untuk menjadi layak. Sejujurnya sekarang setelah saya mengetik ini, saya tidak sepenuhnya yakin bahwa kasus ini sepadan. Kebutuhan akan rentang inklusif tidak cukup tinggi untuk menjamin sintaks.

Namun inkonsistensi masih mengganggu saya. Memiliki fungsi inklusif dan ... dalam pencocokan pola terasa seperti memiliki abu-abu dan abu-abu dalam bahasa Inggris. Ketika kita memiliki kesempatan untuk membuat standar, sebagian dari diri saya merasa seperti seharusnya. Ada juga masalah logistik yang sebenarnya dalam melakukan perubahan itu. Jika kita pernah mendesain Rust 2.0 (Itu mungkin gila, saya tidak tahu) mungkin kita harus meninjau kembali ini, tetapi saya kira untuk saat ini memiliki abu-abu dan abu-abu sudah cukup baik.

Saya mendukung penggunaan fungsi inclusive untuk instance di luar pencocokan pola dan ... dalam pencocokan pola saat ini.

@tanpa perahu

1. Jika Anda tidak pernah mencela apa pun, Anda berakhir dengan penyatuan semua (kurang lebih) keputusan buruk seperti C++. Ini memaksa pemula untuk belajar lebih banyak lagi karena segala sesuatunya tidak sekonsisten yang seharusnya.
   Jadi terkadang masuk akal untuk mencela hal-hal untuk memberi jalan bagi solusi yang lebih baik.

2. itu tidak berarti pengguna, melihatnya untuk pertama kali, akan tahu apa yang mereka lihat.

Ini adalah kasus dengan sintaks apapun . Kami (yang tahu Rust) memiliki bias ini karena bagi kami, kode Rust terlihat jelas tetapi siapa pun yang datang ke Rust dari bahasa lain harus sering mencari sintaks. Itu tidak berubah jika kita menggunakan ..= atau ... atau sintaks lainnya untuk rentang inklusif karena misalnya bahasa lain menggunakan ... untuk rentang eksklusif sehingga mereka tetap harus mencarinya .
Seharusnya bukan tujuan kami untuk hanya memperkenalkan fitur yang terlihat jelas:
Jika kami hanya ingin memiliki fitur yang terlihat jelas, kami tidak dapat memiliki sebagian besar fitur yang ada di Rust. Pemula HARUS melihat doc, apa yang salah tentang itu? Dok baik!

1. 
   Jika Anda ingin meminimalkan waktu yang harus dilakukan pemula untuk melihat dokumen, kita harus berusaha keras untuk simetri antara konstruksi dan pencocokan rentang inklusif! (dan konstruksi lainnya)

Seperti yang dikatakan @withoutboats , saya rasa banyak dari kita yang bosan dengan diskusi ini; I untuk satu telah duduk itu untuk sementara waktu. Karena itu, saya meluangkan waktu untuk membaca ulang (terima kasih atas ringkasannya @Xaeroxe!) dan meninjau kembali pemikiran saya di sini.

IMO, masalah terpenting saat ini adalah kombinasi sintaks yang tidak lengkap yang kami sediakan : ... dalam pola, .. untuk ekspresi. Sepasang sintaks ini sangat mengarahkan Anda untuk mengharapkan bahwa .. akan bekerja dalam pola dan ... dalam ekspresi -- dan ternyata tidak. Saya percaya bahwa ini bukan desain yang dapat dipertahankan dalam jangka panjang, dan sangat ingin memperbaikinya.

Saya juga berpikir bahwa, mengingat bahwa kami telah menyediakan sintaks untuk kedua jenis rentang, mungkin lebih baik untuk terus melakukannya. Itu membuat kami memiliki beberapa opsi:

• Stabilkan ... dalam ekspresi dan tambahkan .. ke pola. Ini adalah perubahan yang paling tidak menyakitkan, tetapi memiliki kelemahan yang dibahas dengan baik di sekitar kesalahan satu per satu. Namun, bahasa lain memiliki kombinasi ini dan, sepengetahuan saya, tidak mengalami kesalahan seperti itu.

• Menghentikan ... dalam pola dan ekspresi, menambahkan ..= ke keduanya, dan menambahkan .. ke pola. Menyelesaikan kerugian di atas, lebih menyakitkan (karena penghentian), dan membuka pintu ke jenis rentang lain (seperti eksklusif kiri) di masa mendatang.

Pada titik ini saya sebagian besar mengulangi diskusi, dan sejujurnya, saya tidak berpikir ada banyak lagi yang bisa dikatakan pada saat ini; Saya pikir kami telah mengungkap pengorbanan dan hanya perlu tim lang untuk melakukan evaluasi dan mencapai keputusan. Tetapi dorongan utama dari komentar saya adalah poin awal, tentang mengapa saya pikir sesuatu perlu diubah di sini (dan mengapa hanya menambahkan inclusive tidak cukup, IMO).

Namun, bahasa lain memiliki kombinasi ini dan, sepengetahuan saya, tidak mengalami kesalahan seperti itu.

Saya khawatir tentang bias seleksi di sini. Kami tidak memiliki cara yang dapat diandalkan untuk menilai apakah masalahnya kecil atau hanya jarang menjadi perhatian kami.

Juga, menggunakan ... terasa seperti bertentangan dengan aspek "hindari footguns kecuali trade-off terlalu parah" dari filosofi desain Rust dan praktik terbaik yang muncul. (mis. Saran untuk membuat tipe enum daripada menggunakan bool sehingga lebih sulit untuk mencampur parameter fungsi Anda.)

Misalnya, C telah membuktikan bahwa penugasan dalam pernyataan if berguna jika suatu bahasa tidak memiliki while let , tetapi diketahui bahwa mengetik = Anda maksud adalah == sudah cukup untuk dijadikan pijakan sehingga bahasa seperti Python menolaknya, bahkan ketika ada situasi di mana satu-satunya alternatif tidak seperti biasanya jelek.

Pergi ke arah lain, saya benar-benar memiliki Clippy menangkap kasus seperti ini ketika saya lelah coding sekitar seminggu yang lalu ...

foo == bar;  // This should be `foo = bar;`

...yang tampak seperti contoh sempurna dari jenis kesalahan "tekan tombol terlalu sering" yang kami khawatirkan di sini... dan, tidak seperti " == tidak berpengaruh", ada tidak ada cara yang baik untuk lint untuk .. vs. ... .

@ssokolow Untuk lebih jelasnya, saya baik-baik saja dengan ..= juga; saya tidak berpikir penghentian akan sangat menyakitkan, dan ini adalah perbaikan otomatis yang sangat mudah. Sebagian besar saya hanya ingin menyelesaikan masalah ini.

Saya mungkin bisa hidup dengan menstabilkan .. / ... (yang sudah diterapkan pada malam hari). Saya setuju dengan @aturon bahwa bahasa yang ada menunjukkan ini akan berfungsi.

Seperti yang telah saya katakan, saya benar-benar ingin menstabilkan tipe libstd ketika rust-lang/rfcs#1980 berlalu tanpa memerlukan diskusi sintaksis.

Bersamaan dengan apa yang ditunjukkan @aturon , mungkin berguna untuk menggabungkan masalah pelacakan untuk sintaksis rentang ini dan eksklusif? Mungkin membuat masalah pelacakan terpisah untuk jenis dan menggunakannya untuk menstabilkan jenis sebelum sintaks.

Saya mencalonkan kembali untuk diskusi tim lang. Saya pikir sangat tidak mungkin bahwa ide-ide atau pengorbanan baru yang signifikan akan muncul pada saat ini. Kita perlu mencapai keputusan tentang pengorbanan yang telah ditetapkan.

Pada 18 Mei 2017 9:55:30 PDT, Aaron Turon [email protected] menulis:

Saya mencalonkan kembali untuk diskusi tim lang. Saya pikir itu sangat tidak mungkin
bahwa ide atau pengorbanan baru yang signifikan akan muncul di sini
titik. Kita perlu mencapai keputusan tentang pengorbanan yang telah
ditata.

Aku akan keluar untuk pertemuan minggu depan karena konferensi. Jika hal ini dibahas dalam pertemuan minggu depan, saya akan menyuarakan dukungan saya untuk solusi apa pun selain ... , apakah ..= , inclusive , atau lainnya.

Sebaiknya diskusikan sintaks rest/spread saat kita melakukannya.
Saya memilih .. untuk rentang eksklusif, ... untuk inklusif, .... untuk istirahat/penyebaran.

take_range(..max); // exclusive range
take_range(...max); // inclusive range
take_multiple_args(....tuple); // spread
if let 0..10 = get_num() {} // exclusive range pattern
if let 0...9 = get_num() {} // inclusive range pattern
if let [first, ....rest] = get_slice() {} // rest pattern

Saya akan memilih ... untuk potongan sisanya karena dua alasan:

1. Orang-orang mungkin sudah terbiasa dengan ... berarti "istirahat" dari bahasa seperti CoffeeScript (CoffeeScript menggunakan rest... dalam tanda tangan fungsi untuk varargs dan menyebutnya "percikan") dan Bahasa Inggris (Menggunakan Unicode yang benar codepoint atau tidak, itu tiga periode yang terlihat seperti elipsis, bukan empat, dan orang-orang melakukan pekerjaan yang layak untuk memahami elipsis kira-kira berarti "dan masih banyak lagi tetapi kami tidak mengatakannya dengan keras" dalam bahasa Inggris, murni dari menemukannya digunakan.)

2. Kecuali saya melewatkan sesuatu tentang sintaks Rust, menggunakan .. dan ..= untuk rentang tetapi ... untuk irisan sisanya akan berarti bahwa, dalam setiap situasi, mengetik ... ketika yang Anda maksud adalah .. atau sebaliknya masih merupakan kesalahan waktu kompilasi.

   Untuk ini, saya menggunakan dua asumsi:

   1. Itu menggunakan sintaks istirahat saja (di luar konteks pembongkaran urutan) tidak akan diizinkan sebagai no-op yang rawan salah ketik. (yaitu for _ in ...rest akan sama dengan for _ in rest jika diizinkan, tetapi hampir pasti salah ketik.

   2. Bahwa menggunakan rentang terbuka sebagai pola yang akan ditetapkan tidak valid. (mis. let [first, ..rest] = tidak valid.)

@ssokolow triple dot sudah berarti rentang dalam pola sehingga akan menjadi perubahan besar untuk mengubahnya ke sintaks istirahat.

@poin paux . Aku lupa tentang itu karena suatu alasan.

Sesuatu untuk menggantung tag "jika kita pernah membuat Rust 2.0", mungkin.

triple dot sudah berarti rentang dalam pola sehingga akan menjadi perubahan besar untuk mengubahnya ke sintaks istirahat.

Namun, ... dalam pola harus memiliki ekspresi di kedua sisi, saya percaya ( a...b ), sedangkan sintaks lainnya menggunakan ... sebagai awalan, bukan?

Tim lang membahas fitur ini lagi dalam pertemuan kami hari ini, dan sampai pada kira-kira matriks berikut:

• Mendukung ... dalam pola dan .. dalam ekspresi, dan tidak ada yang lain, adalah desain yang tidak dapat dipertahankan; itu mengarahkan pengguna untuk mengharapkan sintaks yang tidak berfungsi.

• Mengizinkan ... dan .. di kedua tempat akan membantu, tetapi masalah off-by-one adalah masalah nyata; tak satu pun dari kita yang ingin menerima laporan tentang orang-orang yang menghabiskan berjam-jam melacak periode yang salah.

• Pindah ke ..= dan .. kurang menarik secara estetika, tetapi menghindari masalah praktis yang sangat nyata di atas. Kami juga dapat meluncurkannya dengan cara yang sangat lembut: pertama-tama perkenalkan ..= sebagai sintaks alternatif (yang dapat ditulis ulang oleh rustfmt), dan hanya setelah itu menjadi idiomatis, hentikan ... .

Jika Anda tidak tahu, tim merasa bahwa ..= dan .. adalah jalan terbaik kami ke depan. Masalah ini juga telah dibahas sampai-sampai sangat tidak mungkin bahwa argumen baru akan diajukan, jadi kami siap untuk mengambil risiko: kami sedang mencari seseorang yang ingin menerapkan notasi ..= untuk keduanya pola dan ekspresi, dan selanjutnya kita akan pergi ke FCP!

Untuk itu, kami mencari seseorang (atau beberapa orang) untuk mendorong implementasi ke depan. Mungkin ini dapat dilakukan di sejumlah PR yang lebih kecil:

• Untuk memulai, mari tambahkan ..= ke parser sebagai alias untuk ... dan konversi pengujian yang ada.
  
  
  
  • ... harus tetap bekerja, tentu saja, dan kami ingin ini menjadi penghentian "diam", jadi tidak perlu mengeluarkan peringatan dll (belum).
  
  
  • karena itu kita perlu mempertahankan pengujian pada pola ...
  
  
  • Saya pikir mungkin cara untuk melakukannya adalah dengan memodifikasi lexer dengan menambahkan token DotDotEquals ( ini adalah DotDotDot ) dan kemudian memodifikasi parser untuk menerima DotDotEquals mana pun kita berada sekarang terima DotDotDot ( contoh )
  
  
  • ripgrep DotDotDot adalah temanmu di sini ;)
  
  
• ... dalam ekspresi tidak pernah stabil, jadi kita bisa mengubahnya ke ..= dan mematikan dukungan yang lebih lama
  
  
  
  • untuk bersikap baik kepada orang-orang di alam liar, kita bisa melalui periode penghentian, tapi saya tidak yakin itu perlu (pikiran?)
  
  

Perlu diketahui bahwa, saat mengimplementasikan, sintaks extern fn foo(a: u32, ...) tidak boleh diubah menjadi ..=

Tergoda untuk menganggapnya sebagai langkah pertama yang bagus ke dalam kode, tetapi saya tidak akan punya banyak waktu dalam 2 minggu ke depan, jadi jika ada yang ingin mengambilnya, silakan!

Saya pribadi lebih menyukai ..^ daripada ..= , karena a operator= b sudah, untuk beberapa operator, merupakan alias untuk a = a operator b . ^ di sisi lain digunakan jauh lebih sedikit, hanya untuk XOR, sehingga akan menyebabkan lebih sedikit kebingungan.

.. menghasilkan tipe yang berbeda dari tipe operan kiri dan kanan untuk itu, jadi saya tidak melihat itu menjadi masalah untuk ..= . Konteks juga membantu mengidentifikasi tujuan operator, sesuatu seperti += mengembalikan () sehingga dapat muncul sebagai pernyataannya sendiri, biasanya pada barisnya sendiri. Sedangkan ..= mengembalikan InclusiveRange sehingga akan muncul sebagai ekspresi di dalam instruksi lain. Lebih jauh seperti yang disebutkan di atas ..^ sepertinya lebih berkaitan dengan eksponensial daripada rentang.

@Xaeroxe ^ tidak ada hubungannya di Rust dengan eksponensial (meskipun digunakan seperti itu dalam bahasa lain), sementara += , -= , *= all ada di Rust. Bahkan ^= ada.

Tapi idk, tidak apa-apa untuk memiliki ..= juga.

Sejak #42134 digabungkan, bisakah kita pindah untuk menstabilkan struktur perpustakaan sekarang? Saya pikir kita akan ingin menunggu sintaks untuk menyelesaikan sebelum menstabilkan itu, meskipun seperti yang saya katakan sebelumnya, akan sangat membantu untuk menstabilkan struct lebih cepat.

@clarcharr Saya yakin kami telah mengambil keputusan untuk menstabilkan struktur itu serta sintaks ..= jadi kami hanya perlu beberapa PR untuk benar-benar melakukannya.

EDIT: Woops saya salah. Kami mengimplementasikannya di kompiler, menstabilkan sintaks perlu menunggu Periode Komentar Akhir berlalu. Saya pikir kita harus menstabilkan struktur saat ini tetapi itu juga bukan keputusan yang saya buat.

Saya sudah lama berhenti mengikuti topik ini, ketika menurut saya ... sedang membuat konsensus. ..= tampak canggung bagi saya karena hanya terlihat seperti kepura-puraan pada pandangan pertama.

Tapi jauh lebih penting, saya tidak berpikir bahwa bikeshedding ini cukup penting untuk mengubah sintaks pola saat ini.

sintaks ini menyebalkan!
= memiliki arti penugasan, bahkan dalam model +=, -=, *=, tetapi ..= adalah tentang mendapatkan sesuatu. jadi bingung dan jelek.
seperti indeks array mulai dari 0, '...' bagus dan indah, orang akan terbiasa.

@zengsai
..= secara konseptual diturunkan dari operator seperti == dan <= , yang sudah ada di Rust dan menunjukkan perbandingan kesetaraan, bukan penugasan.

(mis. 1..=5 adalah singkatan untuk "Rentang di atas nilai 1 <= x <= 5 " sebagai lawan 1..5 berarti "Rentang di atas nilai 1 <= x < 5 ")

EDIT: Juga, ini bukan masalah "membiasakan diri", ini masalah yang lebih sulit untuk salah dibaca atau salah ketik ketika Anda lelah atau terganggu. Kesalahan satu per satu seperti itu terkenal dengan footgun-y.

Saya sebenarnya tidak sengaja mengetik ... padahal yang saya maksud adalah .. . Untungnya, saya selalu menargetkan Rust yang stabil, jadi kompiler menangkapnya. (Namun, saya tidak dapat mengingat apakah itu kejang otot atau memori otot dengan asumsi saya ingin mengetik pseudo-elipsis karena saya banyak menulis non-fiksi.)

@zengsai ... terlalu halus, terlihat terlalu mirip dengan ..

Akan sangat tidak normal bagi suatu bahasa untuk memiliki jumlah titik yang berbeda yang berarti hal yang berbeda

Menghapus pistol kaki lebih penting daripada menarik secara estetika.

Pendatang baru: Saya telah membuat TL;DR, karena ini adalah utas yang sangat panjang. Anda dapat membacanya di sini: https://github.com/rust-lang/rust/issues/28237#issuecomment -296310123

berbicara kepada " Off-by-one error seperti itu terkenal footgun-y", saya harus mengatakan: masalah salah ketik tidak boleh digunakan sebagai alasan utama perubahan ini.

lihat perbandingan ini, ".." dan "..." vs "=" dan "==", apakah itu berarti kita harus menemukan sintaks lain untuk "==" untuk menghindari masalah kesalahan ketik pengguna? jika "=" dan "==" baik-baik saja, mengapa ".." dan "..." tidak bisa?

Saya telah mengikuti rust-lang lebih dari dua tahun. semut itu telah digunakan di banyak proyek pribadi saya. Saya menyukainya, tetapi sintaks ini benar-benar membuat saya merasa tidak nyaman. tidak hanya menarik secara estetis, tetapi juga mempengaruhi kelancaran penulisan dan pembacaan kode.

@zengsai adalah pemahaman saya bahwa ini bukan terutama tentang kapan _menulis_ kode, tetapi ketika meninjau, membaca, dan memahami kode. Jika Anda tidak mencarinya, Anda bisa lebih mudah melewatkan .. vs. ... sebagai kesalahan satu per satu, sedangkan ..= pasti lebih menonjol dan menang tidak memiliki masalah ini.

Saya tidak yakin saya menyukai sintaks ..= baik dari sudut pandang estetika, tetapi saya dapat melihat dari mana semua orang berasal tentang .. dan ... membaca dengan sangat mirip.

@zengsai Karena = vs. == memiliki solusi yang tidak tersedia untuk .. vs. ... .

Tentu, Anda dapat membingungkan = dan == dalam C... tapi itu adalah footgun yang dikenal dan bahasa yang lebih modern seperti Python dan Rust menyelesaikannya:

1. Ini kesalahan jika Anda mengetik if x = y daripada if x == y (Ini adalah perbaikan yang dibuat Rust dan Python)
2. Ketika saya tidak sengaja mengetik x == y; daripada x = y; , saya mendapat peringatan tentang ekspresi yang tidak berpengaruh.

Tidak ada cara bagi kompiler untuk mengenali bahwa kebingungan .. vs. ... mencurigakan , apalagi salah.

@zengsai .. dan ... mengevaluasi tipe yang menerapkan semua sifat yang sama dan pada dasarnya dapat digunakan secara bergantian (ini berdasarkan desain). Off by one error adalah masalah yang sangat nyata.

Saya ingin memperjelas bahwa saya juga membenci sintaks ini, sehingga saya tidak setuju dengan komentar @aturon bahwa situasi saat ini di mana kami menggunakan .. dan ekspresi dan ... di pola "tidak dapat dipertahankan;" sebenarnya, saya pikir lebih baik memiliki pemutusan daripada memiliki sintaks ini.

Tapi jelas kami tidak akan pernah memiliki konsensus tentang ini, bahwa tidak ada argumen baru yang bisa didapat di utas ini, dan bahwa mayoritas pengguna yang berinvestasi secara aktif (serta tim bahasa lainnya) menyukai perubahan ini. Jadi saya berdiri di samping sehingga kita bisa menyelesaikan masalah ini.

Jika ada penghiburan dalam pengalaman saya, sebagian besar kasus penggunaan tidak pernah benar-benar membutuhkan fitur ini, dan karenanya tidak akan muncul di seluruh kode Anda.

Sebenarnya, saya masih sangat tidak senang dengan penghentian ... dalam pola, dan pada dasarnya saya hanya akan menggertakkan gigi agar masalah ini dapat diselesaikan. Seluruh tim lang setuju bahwa memiliki ekspresi .. dan ... akan menjadi masalah yang mengerikan, menyebabkan beberapa pengguna menghabiskan waktu berjam-jam untuk men-debug masalah kesalahan ketik yang benar-benar tidak terdengar.

Anggota tim lang lainnya sangat yakin bahwa pemutusan antara ekspresi & pola tidak dapat diterima, dan meskipun saya tidak setuju, kita semua telah membuat argumen dan saya tidak berpikir berada di jalan buntu selamanya itu sehat.

@ssokolow Maaf, saya masih tidak setuju dengan Anda. kompiler dapat memperingatkan Anda tentang kesalahan ketik semacam ini, tetapi bagaimana jika Anda mengetik "x=5" di tempat yang seharusnya "x=6" ?

Kompilator bukanlah yang sempurna untuk menghindari kesalahan ketik, pemrogramnya.

jika perubahan ini tidak memiliki efek samping, saya sangat setuju. tapi ini membiarkan bahasa kehilangan estetika, kefasihan menulis dan membaca, yang tidak layak hanya menurut pendapat pribadi saya.

Karat hari ini sudah menemui masalah membaca dan menulis, sintaks yang lebih tidak biasa dan berlawanan dengan intuisi, kurva pembelajaran yang lebih banyak, jangan buat Perl lain.

@withoutboats Kami berdebat dengannya, karena kami menyukainya. Mungkin argumen ini sudah terlambat, dan tidak bisa mengubah apapun, hanya saja...

@zengsai

Tentu saja ada trade-off yang harus dilakukan, tapi saya mendapat kesan bahwa kita tidak akan pernah menyepakati titik keseimbangan terbaik di antara keduanya.

Terlepas dari selera pribadi, saya melihat ..= sebagai harga kecil yang harus dibayar untuk menghindari waktu yang terbuang sia-sia untuk melacak bug.

(Area fokus saya adalah desain UI/UX dan salah satu aturan terbesar yang mereka ajarkan kepada Anda adalah bahwa Anda harus bertujuan untuk membuat kemudahan membuat kesalahan berbanding terbalik dengan kerugian dan/atau waktu perbaikan yang akan ditimbulkannya. )

Menurut pendapat kecil saya, 5 vs. 6 jauh lebih jelas untuk dilihat daripada .. vs ... .

@zengsai Saya menerima terlalu banyak email hanya untuk percakapan ini, bagaimana kalau pindah ke saluran rust IRC untuk mengekspresikan perasaan Anda dengan lebih baik?

@daiheitan Ini adalah komunikasi normal. Jika Anda tidak menyukainya, saya sarankan Anda membatalkan

Saat pertama kali melihat Rust, saya sangat terkejut dengan sintaks .. . (1..10).sum() adalah... jumlah bilangan bulat dari 1 sampai 9? Jika Anda mempresentasikan sintaks ini kepada pendatang baru dan menanyakan apa artinya, kemungkinan besar dia akan mengharapkannya dari 1 hingga 10. Dan dia akan benar untuk melakukannya, karena Anda mengharapkan sintaks simetris untuk mengekspresikan simetris rentang. Mengapa 1 harus dimasukkan tetapi tidak 10?

Menambahkan bentuk asimetris lain ..= untuk rentang simetris membuatnya semakin tidak konsisten secara visual. Orang mungkin bertanya mengapa sisi kiri tidak memerlukan = untuk menjadi inklusif, jadi itu akan menjadi =..= untuk rentang inklusif di kedua sisi.

Sesuatu seperti sintaks Swift ( ..< untuk eksklusif dan ... untuk inklusif) akan menghindari masalah ini dan meningkatkan keterbacaan. Anda dapat dengan mudah menebak artinya dengan benar bahkan jika Anda benar-benar baru dalam bahasa tersebut, jadi ada satu hal yang perlu diingat. Saya mengharapkan sesuatu seperti ini untuk dipilih, terutama mengingat dorongan Rust terhadap keramahan pendatang baru.

@rkarp Sampai batas tertentu, itu mungkin karena bias yang sudah ada sebelumnya.

Misalnya, ada banyak pengaruh Python di Rust dan Python menggunakan rentang setengah terbuka yang sama. (mis. Python range(1, 5) atau myList[1:5] keduanya memiliki perilaku yang sama dengan 1..5 Rust)

Pembenaran untuk itu di Python terikat dengan hanya ada satu sintaks dan memiliki sintaks setengah terbuka membuatnya lebih mudah untuk melakukan hal-hal seperti head, tail = myList[:pivot], mylist[pivot:] .

Konon, mengingat Rust telah melewati 1.0, ada aturan yang cukup ketat untuk tidak melanggar kode yang ada. .. untuk eksklusif di luar pola dan ... untuk eksklusif di dalam pola harus tetap berlaku.

..= berfungsi karena Anda dapat menerima .. (eksklusif) dan ..= (inklusif) di mana saja dan memperlakukan ... sebagai sinonim yang tidak digunakan lagi untuk .. dalam pola.

Sekadar mengatakan, memiliki ..= sebagai token secara teknis merupakan perubahan yang tidak kompatibel, karena memengaruhi aturan :tt di makro. Mungkin tidak akan bermasalah, tetapi Anda mungkin ingin memeriksa untuk memastikan apakah seseorang tidak melakukan itu, mengingat itu mungkin juga merupakan perubahan yang tenang. (alternatifnya mengizinkan .. /* why not */ = , yang menurut saya bukan ide yang bagus)

@ssokolow Secara teknis, ini kesalahan ketik di Rust, bukan kesalahan parse. a = 2 adalah ekspresi yang mengembalikan () , dan if mengharapkan bool , jadi keduanya jelas tidak kompatibel.

Aturan perlahan berubah. Secara teknis ..= adalah 3 token di mana 2 token pertama tidak memiliki spasi setelahnya.

@eddyb : Saya akui, saya tidak sepenuhnya memahaminya. Apakah ada cara untuk memperkenalkan token baru tanpa memengaruhi cara :tt mem-parsingnya?

Kode ini saat ini melaporkan "Aturan 2" dan "Aturan 4". Perubahan ini jika saya memahaminya dengan benar akan mengubahnya menjadi "Aturan 2" dan "Aturan 5".

macro_rules! ex {
    ( . . )   => { "Rule 1: . ." };
    ( .. )    => { "Rule 2: .."};
    { . . = } => { "Rule 3: . . = " };
    { .. = }  => { "Rule 4: .. = " };
    { ..= }   => { "Rule 5: ..=" };
}

macro_rules! show {
    ( $($t:tt)* ) => { println!("{}", ex!($($t)*)) };
}

fn main() {
    show!(..);
    show!(..=);
}

Tidak, ini adalah perubahan dalam cara token didefinisikan. @jseyfried dapat menjelaskan konsekuensinya dengan lebih baik.

Secara teknis, itu kesalahan ketik di Rust, bukan kesalahan parse. a = 2 adalah ekspresi yang mengembalikan (), dan jika mengharapkan bool, maka keduanya jelas tidak kompatibel.

@xfix Terima kasih. Saya tidak memperhatikan dengan benar terakhir kali saya membuat kesalahan ketik itu dan saya masih belum sepenuhnya terbiasa berpikir dalam bahasa berorientasi ekspresi.

Saya telah menyesuaikan komentar saya.

Saya tidak suka sintaks ..= dan saya menentang penghentian ... dalam pola. Jika kita takut akan kesalahan ketik, kita selalu dapat menggunakan struct RangeInclusive { start, end } daripada ... atau ..= untuk singkatannya.

Potensi ambiguitas yang baru saya sadari:

if let 5..=x { ... }

@clarcharr Sepertinya tidak dikompilasi.

rustc 1.17.0 (56124baa9 2017-04-24)
error: unexpected token: `=`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |             ^^

error: aborting due to previous error

@clarcharr @kennytm
Setelah kami memperkenalkan ..= sebagai satu operator, kesalahannya adalah:

error: expected one of `::` or `=`, found `{`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |                  ^

error: aborting due to previous error

Sama seperti sekarang dengan let x=10; if let 5..x {}

Jadi "ambiguitas" ini tidak akan dikompilasi dan karenanya tidak akan menjadi ambiguitas lebih dari if let 5..x {} .

@Boscop Intinya adalah, saat ini jika kita memperlakukan 5.. sebagai pola seperti Some(5) , maka if let 5.. = x akan mirip dengan let Some(5) = x , dan yang terakhir dikompilasi. Komentar saya menunjukkan bahwa 5.. bukan pola, jadi tidak ada bahaya kompatibilitas dari if let untuk memperkenalkan ..= .

Jika kami memperkenalkan fitur ini dan mengizinkan ..= dan .. dalam pola, if let 5..=x harus selalu if let 5.. = x dan harus dikompilasi: if let (single expression) tidak masuk akal, jadi saya tidak percaya ada ambiguitas.

@kennytm jadi kami berdua menunjukkan 2 ambiguitas berbeda yang tidak akan mereka kompilasi. (Tidak jelas yang mana yang dia maksud. Agak ambigu, heh.)

@daboross Seperti yang dikatakan kennytm, 5.. bukan pola dan tidak dapat dikompilasi, bahkan sekarang. Dan ini tidak akan berubah jika kita menambahkan ..= sebagai operator. Tidak ada ambiguitas. Yang penting sekarang, ..= tidak dapat diurai sebagai satu operator tetapi setelah kita dapat menguraikannya sebagai satu operator, tidak ada ambiguitas.

5.. ini bukan pola yang valid, kami juga tidak memiliki pola interval setengah tertutup. Meskipun demikian, kurangnya pola interval setengah tertutup adalah sesuatu yang sering dilihat sebagai sumber inkonsistensi jika dibandingkan dengan ekspresi rentang dan mungkin pada akhirnya diimplementasikan untuk pola juga. Kami juga mungkin ingin menambahkan kemampuan untuk menghilangkan satu sisi interval dalam pola nanti untuk misalnya kecocokan bilangan bulat lengkap.

Jadi sementara pengamatan @ clarcharr tidak selalu menunjukkan ambiguitas ketika tata bahasa saat ini dipertimbangkan, tentu saja ambiguitas ketika mempertimbangkan potensi ekspansi di masa depan yang mungkin bertentangan dengan proposal untuk menggunakan ..= untuk pola.

Dengan mengingat hal itu saya akan menyarankan untuk menggunakan beberapa simbol lain di sini. ^ tampaknya cukup oke bagi saya, karena hanya digunakan dalam konteks ekspresi saat ini IIRC.

(Ini adalah alasan lain mengapa saya pikir itu ide yang baik untuk pindah untuk menstabilkan struct sekarang, dan sintaks nanti.)

@nagisa tidak ada konflik mengenai if let jika token ..= ditambahkan sebelum pola RangeFrom didukung. Seseorang dapat menambahkan spasi antara .. dan = untuk memperjelas, seperti x <- y (penempatan di) vs x < -y (kurang dari + negatif).

(Karena ^ adalah eksklusif -or operator, saya merasa ironis menggunakan ..^ untuk rentang inklusif )

Dalam ribuan rentang yang saya tulis, beberapa di antaranya sepenuhnya tertutup, bahkan mungkin satu atau dua setengah terbuka dengan cara yang salah, saya masih tidak benar-benar melihat perlunya sintaks tambahan. 1..(n+1) tidak terlalu sulit untuk ditulis.

Itu tidak berfungsi untuk end = T::max_value().

Pada 29 Mei 2017 16:33, "Diggory Hardy" [email protected] menulis:

Dalam ribuan rentang yang saya tulis, beberapa di antaranya tertutup sepenuhnya,
bahkan mungkin satu atau dua setengah terbuka dengan cara yang salah, saya masih tidak begitu
melihat perlunya sintaks tambahan. 1..(n+1) tidak terlalu sulit untuk ditulis.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

Saya lebih suka metode pada rentang setengah tertutup untuk ..= sekalipun.

Pada 29 Mei 2017 16:35, "Simonas Kazlauskas" [email protected] menulis:

Itu tidak berfungsi untuk end = T::max_value().

Pada 29 Mei 2017 16:33, "Diggory Hardy" [email protected] menulis:

Dalam ribuan rentang yang saya tulis, beberapa di antaranya sepenuhnya
tertutup, bahkan mungkin satu atau dua setengah terbuka dengan cara yang salah, saya masih tidak
benar-benar melihat perlunya sintaks tambahan. 1..(n+1) tidak terlalu sulit untuk
menulis.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

Saya benar-benar berharap kita sudah menstabilkan sifat dan tipe dengan metode untuk membangunnya karena saya cukup yakin tidak ada perselisihan tentang itu. Tolong jangan biarkan bikeshedding pada sintaks menghambat stabilisasi fungsi inti itu sendiri.

Itu tidak berfungsi untuk end = T::max_value().

Apakah Anda benar-benar ingin mengulangi lebih dari 2^64 nilai, atau bahkan 2^8 nilai? Jika Anda hanya ingin mengulangi beberapa nilai terakhir misalnya u32 , seringkali lebih mudah untuk menambahkannya di dalam loop. Dan jika Anda benar-benar ingin beralih ke 2^B-1 untuk beberapa alasan yang tidak jelas, maka Anda selalu dapat menempelkan if i == END { break; } di akhir perulangan.

Hanya karena bilangan bulat unsigned standar kami mendukung nilai 2^32 atau 2^64 tidak berarti nilai tertinggi yang dapat diwakili sangat sering digunakan. Dan jika Anda melakukan sesuatu dengan u8 , jangan lupa bahwa mungkin lebih mudah bagi CPU untuk menggunakan u32 untuk penghitung.

Tetapi bahkan jika saya tidak melihat perlunya sintaks generator jarak dekat, saya tidak dapat menyangkal argumen tim untuk change . Baiklah :/

Bagaimana kalau keempatnya mencakup semua opsi inklusivitas?

1...10
1>..10
1..<10
1>.<10

Saya membayangkan seseorang harus dapat memahami apa yang mereka maksudkan tanpa penjelasan lebih lanjut, mengingat bahwa operator ketidaksetaraan telah dipalu ke dalam pikiran semua orang dari taman kanak-kanak dan seterusnya ... tidak tahu apakah ini akan menyusahkan dengan cara lain, meskipun.

Atau, kita dapat mengganti pertidaksamaan:

1...10
1<..10
1..>10
1<.>10

... hanya agar yang terakhir tidak terlihat seperti Cartman yang marah.

@vegai dan bagaimana dengan sintaks a..b yang ada yang tentunya tidak akan dihapus? Tidak, saya tidak berpikir menyarankan opsi sintaks baru akan menyelesaikan apa pun.

Hmm, jadi ada dua "potensi ambiguitas" yang muncul:

• if let 5..= x -- seperti yang disebutkan, ini sebenarnya bukan ambiguitas sekarang , tapi bisa jadi. Di sisi lain, ambiguitas semacam ini sering muncul, dan ditangani oleh tokenizer. Artinya, jika kita menganggap ..= sebagai token di parser kita, itu tidak ambigu bahkan jika kita menambahkan pola 5.. di masa depan; anda hanya perlu menulis spasi antara .. dan = (misalnya, let 5.. = x ).
• ambiguitas sehubungan dengan aturan makro. Ini memang menyakitkan dan disayangkan, dan ini adalah salah satu alasan kami beralih ke sistem yang berbeda untuk "makro 2.0", di mana kami menghindari mengekspos kumpulan "token gabungan" kepada pengguna akhir.
  
  
  
  • pada akhirnya, kita dapat menangani macro_rules! back-compat melalui beberapa kode kasus khusus jika perlu; dalam hal apapun, saya pikir tidak ada menghindari masalah semacam ini kecuali dengan menggunakan ... .
  
  

Sebelum menstabilkan rentang inklusif, masalah #42401 juga harus diperbaiki, karena setelah stabilisasi, perbaikan akan menjadi perubahan yang melanggar.

@est31 poin bagus, saya menambahkan itu ke daftar periksa di kepala masalah

Pengirisan str yang diperiksa itu sendiri tidak stabil dan memperbaiki masalah itu tidak memblokir rentang inklusif sama sekali.

Oh, @nagisa benar, itu tidak ada hubungannya dengan sintaks rentang. Bisakah Anda menghapusnya dari kepala lagi? Kesalahanku. Bugnya lebih pada implementasi get , dan oleh karena itu dijaga oleh fitur str_checked_slicing :

    impl SliceIndex<str> for ops::RangeToInclusive<usize> {
        type Output = str;
        #[inline]
        fn get(self, slice: &str) -> Option<&Self::Output> {
            if slice.is_char_boundary(self.end + 1) {
                Some(unsafe { self.get_unchecked(slice) })
            } else {
                None
            }
        }
    [...]

DIHAPUS

Pembaruan kotak centang lainnya: PR https://github.com/rust-lang/rust/pull/42134 menerapkan https://github.com/rust-lang/rfcs/pull/1980 tweak

Bump: bagaimana kita bisa mendapatkan setidaknya struct stabil untuk 1,20?

Bagaimana kalau kita meminjam operator masuk yang terkenal dari C++ untuk sintaks rentang inklusif? 😛

@nikomatsakis dan @rust-lang/libs (Saya tidak tahu bagaimana menandai ini), bagaimana perasaan Anda jika saya mengirimkan PR yang memindahkan struct ke masalah pelacakan yang berbeda, sehingga kita dapat membicarakan stabilisasi untuk mereka di sana? Saya pikir ini akan menjadi cara yang baik untuk bergerak maju dalam menstabilkan mereka lebih cepat sementara kami menunggu sintaks baru diimplementasikan/diselesaikan.

cc @rust-lang/libs (hanya orang dalam tim yang dapat menandai tim mereka atau tim lain)

Terima kasih, @eddyb!

@clarcharr Berdasarkan https://github.com/rust-lang/rust/pull/42275#discussion_r119211211 , saya menduga itu akan dihargai.

Apakah saya terlambat untuk kereta untuk proposal sintaks?
Arus terlihat seperti saat seseorang mencoba menetapkan nilai ke irisan.

for i in a..b {} // [a..b) 
for i in a..+b {} //[a..b] 
for i in a-..b {} //(a..b) 
for i in a-..+b {} // (a..b]

Sintaks ini tidak memungkinkan untuk menambahkan implementasi Add untuk rentang di masa mendatang. Saya tidak benar-benar tahu apakah itu masalah karena saya tidak begitu yakin apa yang akan dilakukan implementasi Add .

Setuju untuk trailing plus. Diubah menjadi awalan.

Karena a.. , ..b dan .. adalah konstruksi yang valid di Rust, ini masih menghasilkan ambiguitas dengan operasi matematika :/

a... / a..= / a..+ tidak akan valid bukan? Karena memiliki rentang tak terbatas yang mencakup titik akhir tidak masuk akal.

Saya tidak akan terlalu khawatir tentang Add , sepertinya itu tidak terlalu umum untuk dilakukan dengan rentang, dan jika Anda mau, Anda bisa melakukannya (x..+y) + z ?

Sunting: sudahlah, baru sadar apa yang Anda maksud. Itu akan menjadi a..+b yang ambigu, bukan? Karena sekarang artinya a.. + b .

@daboross Tidak mengatakan ini adalah ide yang baik atau buruk, tetapi implementasi ini (atau beberapa variasi di dalamnya) mungkin menjadi sesuatu yang kami inginkan untuk rentang di masa mendatang:

impl<T> Add<T> for RangeFrom<T> where T: Add<T> {
    type Output = RangeFrom<T>;
    fn add(self, rhs: T) -> RangeFrom<T> {
        (self.start + rhs)..
    }
}

Impl spesifik ini mungkin atau mungkin bukan ide yang bagus, tetapi saya tidak butuh waktu terlalu lama untuk menjadikannya sebagai kemungkinan kasus penggunaan di masa mendatang. Saya pikir itu akan menjadi ide yang buruk untuk mengecualikan kemungkinan ini atau sesuatu seperti ini ditambahkan karena keputusan sintaks yang ada.

Kekhawatiran saya yang lain adalah bahwa inti dari mengabaikan ... adalah untuk meminimalkan kemungkinan kesalahan ketik yang sulit dikenali dan memungkinkan orang tua untuk membuat perbedaan antara dua arti abstrak yang berbeda a..+b terasa seperti itu akan bergerak kembali ke arah itu.

Selain itu, saya belum melihat pembenaran yang kuat untuk a-..b dan a-..+b luar "bukankah lebih baik demi kelengkapan" sementara .. dan yang diusulkan ..= keduanya tahu, alasan yang valid.

Anda tidak dapat menggunakan + untuk ini karena ini membuat sintaks ekspresi menjadi ambigu.

EDIT: meskipun, saya kira, itu akan memungkinkan penerapan rentang inklusif sepenuhnya di perpustakaan, karena Anda baru saja akhirnya memiliki implementasi <Range as Add<{integral}>>::Output = InclusiveRange .

Saya mungkin menyarankan varian ..! . Ini memiliki sajak produktif dengan .. dan memberikan penekanan tambahan pada titik terakhir sehingga lebih terlihat.

Tentu saja itu akan bertabrakan dengan operator ! tetapi, sejujurnya, saya tidak dapat membayangkan situasi di mana seseorang perlu menempatkan ! dalam subekspresi terikat.

..! memiliki masalah dengan intuisi. Seorang pendatang baru yang belum terbiasa dengan sintaks dapat dengan mudah salah memahami ..! berarti "sampai, tapi tidak..."

Itu juga bertabrakan dengan sintaks untuk "rentang hingga pelengkap bitwise ..." (Yang akan menempatkannya dalam situasi yang mirip dengan menggunakan + )

Setuju. Tetapi di sisi lain ..= dapat disalahartikan sebagai salah satu operator penugasan juga.

Apa yang akan Anda tetapkan jika ini adalah operator penugasan?

Berdasarkan proposal @ snuk182 :

a...b // [a; b] shorthand for RangeIncusive
a..-b // [a; b) new Range shorthand 
a..b // [a; b) old Range shorthand exists for compatibility

Saya ragu apakah kita membutuhkan kombinasi lain. Bagaimanapun, itu dapat ditambahkan nanti:

a-..b // (a; b]
a-.-b // (a; b)  

Meskipun opsi terakhir terlihat agak aneh. ^_^

Harap berhenti mengusulkan sintaks yang berisi operator unary yaitu a..-b , a..!b , a..*b , a..&b atau a?..b , ini tidak akan pernah diterima.

..! memiliki masalah dengan intuisi. Seorang pendatang baru yang belum terbiasa dengan sintaks dapat dengan mudah salah paham ..! berarti "sampai, tapi tidak..."

..= memiliki masalah yang sama dengan intuisi. Siapa pun yang melihat = mengharapkan kepura-puraan atau perbandingan. Saya mengakui bahwa sintaks ini menyelesaikan masalah perbedaan karena setiap kali saya melihat ..= , saya tidak dapat mencegah diri saya bertanya-tanya apa yang dilakukan tanda sama dengan ini di sini.

Satu-satunya sintaks yang diusulkan yang cukup intuitif dan konsisten dengan sintaks saat ini adalah ... . Tapi sepertinya kapal itu telah berlayar.

Pendatang baru harus sering melihat dokumen. Bahkan dengan ... mereka akan melihat dokumen. Ini tidak bisa dihindari. Tetapi ..= memiliki mnemonic yang bagus ( up to dan equal to ) sehingga mereka tidak perlu sering melihat dokumen untuk operator ini.

Bagaimana jika operator ... akan tetap seperti itu, tetapi sebaliknya kita mengubah operator .. menjadi ..⎵ , yaitu dua titik dan spasi (saya harus meletakkannya '⎵ ' di sana karena spasi biasa tidak akan ditampilkan di halaman web ini). Itu akan menjadi satu-satunya tempat dalam bahasa di mana ruang putih penting. Ini juga akan menjadi perubahan yang melanggar, karena semua kode seperti a..b akan mengeluh bahwa tidak ada operator seperti .. , dan saran untuk menambahkan setidaknya satu spasi setelah titik. Saya pikir ruang membuat mereka cukup berbeda secara visual:

a.. b
a...b

@tommit Saya tidak berpikir itu ide yang baik untuk jujur.

Operator saat ini cukup fleksibel mengenai spasi putih, misalnya: a..b dan a .. b adalah sama. Ini mungkin untuk membuatnya konsisten dengan operator lain, seperti a+b dan a + b . Ini tentu saja, melakukan hal yang sama, dan memungkinkan orang untuk menggunakan gaya sintaks yang berbeda. Itu hal yang baik jika Anda bertanya kepada saya!

Sebagai tambahan, notasi ..= konsisten dengan notasi <= dan >= (yang juga dianggap _inclusive_).

Itu selalu baik untuk memeriksa kemungkinan lain apa yang ada, tetapi ini mungkin bukan solusi yang tepat.

Setuju. Jika dibandingkan dengan <= dan >= , ..= terlihat masuk akal, bahkan logis.

Omong-omong, jika Anda penggemar ... atau hanya tidak menyukai tampilan ..= , maka solusi kompromi adalah dengan menggunakan beberapa font dengan ligatur pemrograman, seperti FiraCode dengan ligatur khusus untuk ..= , yang mungkin dipetakan ke ... , atau bahkan sesuatu yang aneh, seperti , atau .

Melanggar perubahan ke semua kode karat yang ada menggunakan rentang ... mati pada saat kedatangan,
maaf. Jika seseorang memiliki proposal kompatibel ke belakang yang sangat serius untuk
mengatasi masalah yang telah diangkat, dan itu belum dibahas
sudah, mari kita dengarkan, tapi setidaknya biarkan itu sebagai standar, ya?
Utas ini penuh dengan gudang sepeda dan tim sudah membuat keputusan jadi
itu bar yang tinggi untuk dibersihkan.

Bagaimanapun, tampaknya masih ada banyak pertikaian tentang sintaks yang sebenarnya. Saya telah mengajukan #43086 untuk menstabilkan setidaknya struct dan ciri-ciri dan impls sehingga fungsionalitas inti dapat digunakan (tampaknya ada permintaan, lihat komentar oleh @ retep998 di atas).

Gajah di dalam ruangan adalah bahwa .. sebenarnya adalah masalah sebenarnya di sini karena tampilannya yang simetris tetapi maknanya asimetris. "Hal yang benar untuk dilakukan" mungkin memerlukan penghentian, tetapi tidak ada keinginan untuk melakukannya karena sudah banyak kode yang menggunakannya.

Menghentikan ... sangat konsisten (tampilan simetris, makna simetris) adalah jalan keluar yang mudah, tetapi dengan menambahkan operator lain yang tidak konsisten di ..= . Sepertinya menambahkan desain yang buruk untuk mengatasi desain buruk sebelumnya.

Ada masalah lain dengan ini karena inkonsistensi ganda ini: Tidak ada cara yang baik untuk menambahkan dua varian inklusivitas yang tersisa (eksklusif di kedua sisi dan eksklusif di sisi kiri saja). Karena .. dan ..= keduanya sudah memiliki = implisit di sisi kiri, kita harus meniadakannya, mungkin dengan < . Jadi mereka harus terlihat seperti ini:

• <..= untuk (a; b]
• <.. untuk (a; b)

Semoga berhasil menebak dengan benar apa artinya ini sebagai pendatang baru. Jadi mereka mungkin (seharusnya) tidak pernah dianggap ditambahkan.

Jika .. tidak begitu mengakar atau bahkan tidak ada, membuat desain yang konsisten untuk semua ini dari awal tampaknya tidak terlalu sulit, misalnya:

• .. (atau ... ) untuk [a; b]
• ..< untuk [a; b)
• <.. untuk (a; b]
• <..< untuk (a; b)

Saya merasa bahwa dua varian terakhir mungkin berguna di beberapa titik, haruskah kita benar-benar memblokir jalan menuju mereka begitu cepat? Bagaimanapun, satu - ..= daripada mencela .. adalah melanggar kode lama, tetapi itu akan menjadi kejahatan yang diperlukan, tidak ada yang perlu dirayakan.

_Edit: Menambahkan contoh dan beberapa komentar untuk kejelasan lebih lanjut._

Saya setuju dengan @rkarp bahwa .. adalah masalah sebenarnya di sini, bukan ... atau ..= . Arti asimetris sangat buruk mengingat bahwa lainnya (lebih populer) bahasa benar-benar melakukan assign arti simetris untuk itu. Baik Kotlin, Ruby, dan Haskell menganggap 5 berada di kisaran 3.5 misalnya. Makalah matematika juga tampaknya mendukung itu. Hal terburuk di sini adalah bahwa pemula tidak memiliki kesempatan untuk menebak perilaku 3.5 di Rust: Anda akan memutuskan bahwa 4 dan hanya 4 adalah anggota dari rentang 3.5 (iterasi di atas titik-titik) atau keduanya 3 dan 5 juga ada di dalamnya (mengulangi 'semua yang dapat kita lihat' dan ekstrapolasi titik-titik).

Saya tidak setuju pada kesulitan mengubah ini namun. Saya pikir saran @adelarsq dapat diterapkan dengan relatif tanpa rasa sakit. Sebagai referensi:

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

Setiap kemunculan x..y (tanpa tanda kurung siku) dapat diterjemahkan ke [x..y[ dan mengeluarkan peringatan kompiler. Setelah beberapa rilis, kompiler dapat dengan mudah menolak untuk mengkompilasi notasi rentang "telanjang" dan bahkan mungkin menawarkan alat untuk secara otomatis mengonversi ke notasi baru.

https://github.com/rust-lang/rust/issues/28237#issuecomment -274216603 itu bukan ide baru dan kami tidak dapat menggunakannya karena alasan yang telah kami sebutkan.

Saya benar-benar setuju dengan gagasan bahwa, jika kita mendesain bahasa dari awal dengan melihat ke belakang, kita ingin mempertimbangkan sintaks dari rentang eksklusif dan inklusif bersama-sama. Saya pikir ..= bukanlah operator yang ideal untuk rentang inklusif; itu hanya pilihan terbaik saat ini di atas meja. Tetapi menghentikan operator jangkauan eksklusif saat ini akan sangat menyakitkan, dan merugikan pengguna dan proyek Rust yang ada.

Ada banyak proposal lain yang bisa berhasil. Misalnya, saya belum melihat ..@ diusulkan, dan x..@y tampaknya menggugah. Tantangannya adalah menemukan sesuatu yang lebih menarik daripada proposal saat ini, sambil mempertahankan kurangnya ambiguitas.

Saya ingin menyoroti komentar @ssokolow dari 2 bulan yang lalu, sebagai pandangan favorit saya tentang simetri:

• ..4 berisi hal-hal < 4
• ..=4 berisi hal-hal <= 4

Saya pikir kita hanya perlu jangkauan inklusif, itu lebih sederhana.
Anda selalu dapat menambahkan +1 atau -1 untuk mengubah rentang.
Dan .. lebih baik, karena .. lebih sederhana dari ... !

@AlexanderChen1989 Seperti yang telah dikatakan sebelumnya di beberapa posting di utas ini, itu tidak mungkin karena mengubah arti .. akan merusak kode yang ada.

Selain itu, sebenarnya tidak sesederhana itu. Terutama, +1 dan -1 dapat menyebabkan integer overflow/underflow.)

Berikut adalah contoh yang berfungsi di nightly (melalui kandidat lama untuk sintaks rentang inklusif) di mana...

• ...loop mana pun yang Anda tempatkan terlebih dahulu akan panik saat overflow/underflow di build debug
• ...mereka akan berperilaku sangat berlawanan dengan yang dimaksudkan dalam rilis build (mis. "0 hingga 0" akan berulang 256 kali dan "0 hingga 255" tidak akan berulang sama sekali)

#![feature(inclusive_range_syntax)]
fn main() {
    let max = 255u8;
    let user_provided = 0u8;

    for x in 0...user_provided-1 {
        println!("(0 to 0, exclusive via 'inclusive - 1'): {}", x);
    }

    for x in 0..max+1 {
        println!("(0 to 255, inclusive via 'exclusive + 1'): {}", x);
    }
}

8 proposal sintaks yang mati pada saat kedatangan telah dibuat sejak tim bahasa membuat keputusan. Pendatang baru silakan baca utasnya. Kami memiliki alasan yang sangat bagus untuk membuat keputusan yang kami janjikan.

IMHO OP harus diperbarui untuk menunjukkan bahwa tidak ada lagi diskusi sintaksis yang harus dilakukan di utas ini, dan setiap proposal sintaksis rentang eksklusif (yaitu (a, b) dan (a, b] rentang) harus dipindahkan ke utas lain.

Ini seharusnya hanya berbicara tentang hal-hal yang perlu dilakukan untuk menstabilkan rencana saat ini.

@clarcharr Saya membuat keputusan sebagian besar sepihak dan menambahkannya ke OP, ide bagus. Jika kebisingan berlanjut, saya akan memilih untuk mengunci utas.

Hai, saya baru dan saya ingin mulai mengerjakan yang satu ini. Saya akan mencoba menulis PR untuk menambahkan ..= sebagai sinonim untuk ... dalam pola, mencela ... dalam ekspresi, dan menampilkan kesalahan yang mengatakan bahwa sintaks telah diubah menjadi ..= . Apakah ini terdengar benar?

@Badel2 keren. Saya sebenarnya sudah memulai -- Saya akan segera mendorong cabang saya dan menautkannya di sini.

@durka hanya untuk memperjelas -- apakah Anda menawarkan untuk membiarkan @Badel2 melanjutkan mulai dari cabang Anda? Bisakah Anda membimbing mereka sebagai bagian dari pekerjaan periode impl? Mereka ada di saluran Gitter.

Saya juga setuju bahwa masalah sebenarnya adalah .. . Jadi, solusi yang lebih menguntungkan adalah menghentikan (tidak mengganti sekaligus, sehingga akan __not__ merusak kode yang ada) .. mendukung sesuatu seperti ..< (tidak akan ada kebingungan antara a..<b dan (a..)<b , karena .. pada akhirnya akan tidak ada lagi).

@hyst329 Silakan baca posting yang sudah dibuat.

Posting pertama mengatakan, dalam teks tebal, "Tidak ada lagi diskusi sintaksis yang harus dilakukan di utas ini."

Selain itu, apa yang Anda gambarkan telah diusulkan di sini beberapa kali oleh orang lain yang tidak membaca diskusi yang ada dan ada beberapa alasan yang diberikan sebagai tanggapan mengapa itu bukan pilihan yang layak.

Maaf ini tidak terlalu konstruktif, tetapi setiap kali saya melihat ..= dan mencoba mengingat apa itu, sepertinya operator penugasan mirip dengan += atau <<= . Rasanya sangat membingungkan bahwa tidak. (Meskipun memang ini di luar konteks, misalnya "dukungan awal untuk sintaks ..= " https://this-week-in-rust.org/blog/2017/10/03/this-week- in-rust-202/)

@SimonSapin Saya telah menyatakan kritik yang sama dengan cara yang lebih konstruktif di atas, menyarankan ..^ sebagai gantinya: https://github.com/rust-lang/rust/issues/28237#issuecomment -304325663

Bagi saya, satu poin besar yang berbicara untuk ..= adalah semacam konsistensi dengan swift (yang memiliki ..< untuk eksklusif dan .. untuk rentang inklusif). Ini membuat saya baik-baik saja dengan pilihan ..= .

@SimonSapin Saya tidak berpikir ada orang yang benar-benar senang dengan itu. Masalahnya, ratusan komentar sayangnya menegaskan bahwa tidak ada alternatif yang lebih baik.

Tambalan ini dicapai untuk meyakinkan saya daripada tidak melakukan apa pun lebih baik daripada mengacaukan sintaks pola saat ini hanya untuk menutupi kasus tepi.

.. memiliki sangat sedikit kasus penggunaan dalam pola dan Anda selalu dapat menanganinya tanpa itu.

... dapat diganti dengan RangeInclusive atau (Bound<T>, Bound<T>) dalam ekspresi yang benar-benar membutuhkannya. Ini lebih bertele-tele tetapi mudah dimengerti.

@UtherII

dan saya yakin bahwa ... tidak dapat dipertahankan pada saat saya diselamatkan dari bug halus oleh pesan kompiler "Anda tidak dapat menggunakan sintaks rentang inklusif pada stabil".

Terlalu mudah untuk secara tidak sengaja menekan . satu kali terlalu banyak (atau, mengingat mekanisme yang terlibat, satu kali terlalu sedikit) ketika Anda menekan beberapa kali secara berurutan dengan cepat.

Saya telah mencentang "Ubah untuk menerima ..= sebagai sinonim untuk ... dalam pola dan untuk menerima ..= dalam ekspresi" karena itu sudah terjadi setelah #44709 dengan dotdoteq_in_patterns dan inclusive_range_syntax masing-masing. Yang tersisa hanyalah dokumentasi dan stabilisasi.

Permintaan Stabilisasi

Saya ingin menstabilkan kisaran inklusif sebesar 1,26 (beta pada 30 Maret, stabil pada 11 Mei) atau sebelumnya. PR stabilisasi telah dikirimkan sebagai #47813.

Ringkasan

3 fitur berikut akan distabilkan:

• inclusive_range_syntax — Sintaks a..=b dan ..=b dalam ekspresi:

  for i in 1..=10 {
      println!("{:?}", &a[..=i]);
  }
  

• dotdoteq_in_patterns — Sintaks a..=b dalam sebuah pola:

  match c {
      b'0'..=b'9' => c - b'0',
      b'a'..=b'z' => c - b'a' + 10,
      b'A'..=b'Z' => c - b'A' + 10,
      _ => unreachable!(),
  }
  

  (Catatan: sintaks a...b masih diterima tanpa peringatan)

• inclusive_range — Jenis std::ops::{RangeInclusive, RangeInclusiveTo} dan bidangnya:

  let r = 1..=10;
  assert_eq!(r.start, 1);
  assert_eq!(r.end, 10);
  

Dokumentasi

Beberapa PR dokumentasi dikirimkan oleh @alercah , terima kasih!

• Buku: https://github.com/rust-lang/book/pull/1134
• Referensi: https://github.com/rust-lang-nursery/reference/pull/215
• Rust-by-Contoh: https://github.com/rust-lang/rust-by-example/pull/1015

tes

Anda dapat menemukan kasus uji di:

• run-pass/range_inclusive.rs —
  tes dasar seperti menggunakan a..=b dalam for-loop, sebagai iterator, sebagai indeks irisan, dan prioritas operator ..= , dan perilaku pengecekan tipe.
• libcore/tests/iter.rs —
  tes lebih lanjut tentang perilaku a..=b sebagai iterator; memeriksa bahwa spesialisasi nth() , min() , max() dan last() berfungsi dengan benar, dan setelah memanggil (5..=5).next() rentangnya menjadi 1..=0 .
• liballoc/tests/str.rs , liballoc/tests/btree/map.rs dan liballoc/tests/vec.rs —
  memeriksa apakah a..=b berfungsi dengan benar di berbagai jenis koleksi.
• parse-fail/range_inclusive.rs dan ui/impossible_range.rs —
  memastikan konstruksi yang tidak masuk akal seperti a..= dan ..= karena ekspresi tidak dapat dikompilasi
• parse-fail/range_inclusive_dotdotdot.rs —
  memastikan kami menolak sintaks ekspresi usang a...b dan ...b .
• run-pass/inc-range-pat.rs —
  memastikan penggunaan a..=b dan a...b dalam suatu pola diterima dan setara.
• compile-fail/range_traits-1.rs dan compile-fail/range_traits-6.rs —
  memastikan RangeInclusive dan RangeInclusiveTo tidak mengimplementasikan PartialOrd (seperti rentang lainnya), dan RangeInclusive tidak mengimplementasikan Copy (tidak dapat mengimplementasikan Salin karena mereka adalah iterator).
• libcore/tests/ops.rs —
  memeriksa apakah iterasi instance RangeInclusive dibuat secara manual berfungsi.

Pertanyaan yang belum terselesaikan

• Menggunakan a..=b dalam for-loop memiliki kinerja yang jauh lebih rendah daripada a..(b+1) karena next() lebih kompleks dan kurang ramah pengoptimal. Ini saat ini sedang dilacak di #45222. Ini saat ini dikurangi dengan #48012 saat menggunakan metode iterator alih-alih for-loop.

  Kita mungkin perlu menjaga agar bidang RangeInclusive tidak stabil jika kita belum ingin berkomitmen pada desain di rust-lang/rfcs#1980.

Kami mungkin perlu menjaga agar bidang RangeInclusive tidak stabil jika kami belum ingin berkomitmen pada desain di rust-lang/rfcs#1980.

+1
Apakah ada kebutuhan untuk mengekspos bidang rentang secara langsung, daripada melalui beberapa antarmuka berbasis metode?

@rfcbot menggabungkan

Berdasarkan ringkasan @kennytm , saya mengusulkan agar kita menstabilkan sintaks rentang inklusif ( ..= ).

(Yang mengatakan, saya menemukan kinerja yang lebih rendah dari ..= agak mengkhawatirkan, dan saya bertanya-tanya apakah masuk akal untuk membuat ..= tidak langsung diimplementasikan Iterator untuk saat ini, di untuk mengurangi ini.)

Anggota tim @nikomatsakis telah mengusulkan untuk menggabungkan ini. Langkah selanjutnya adalah peninjauan oleh sisa tim yang ditandai:

• [x] @BurntSushi
• [x] @Kimundi
• [ ] @KodrAus
• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @tanpa perahu

Tidak ada kekhawatiran saat ini terdaftar.

Setelah mayoritas pengulas menyetujui (dan tidak ada yang keberatan), ini akan memasuki periode komentar terakhirnya. Jika Anda menemukan masalah besar yang belum diangkat pada titik mana pun dalam proses ini, silakan angkat bicara!

Lihat dokumen ini untuk info tentang perintah apa yang dapat diberikan oleh anggota tim yang ditandai kepada saya.

Saya ingin tahu apakah masuk akal untuk membuat ..= tidak langsung mengimplementasikan Iterator untuk saat ini, untuk mengurangi ini.

Ciri-ciri stabil ini diimplementasikan untuk RangeInclusive<T> untuk setidaknya beberapa T s di Nightly saat ini: Iterator , FusedIterator , ExactSizeIterator , Debug , Clone , Eq , PartialEq , Hash , TrustedLen .

@SimonSapin saya lupa, apakah kita sudah menstabilkan struct? (Dengan kata lain, apakah itu bisa diamati?) Saya berasumsi tidak.

yang mengatakan, saya juga benar-benar berpikir bahwa 1..2 dan 1..=2 harus dapat digunakan di semua tempat yang sama, yang menentang membuat perubahan apa pun di sini, dan sebaliknya menyarankan agar kita hanya melakukan mitigasi dan peningkatan optimasi.

Mengapa tidak rentang kasus khusus di mana end == MAX ? Itu dapat menyebabkan rentang paling inklusif memiliki kode yang sama dengan yang eksklusif, dengan pengecualian rentang yang langsung menuju batas memiliki lebih banyak kode. Karena cabang end != Max tidak akan pernah mengubah end , ia dapat dengan mudah digarisbawahi oleh pengoptimal.

@nikomatsakis Tidak,

@SimonSapin

Tidak, strukturnya tidak stabil saat ini. Tapi proposal @kennytm termasuk menstabilkannya.

Jadi begitu; memang, inilah mengapa saya menyebutkan bahwa kita harus menghapus impl Iterator sekarang atau tidak sama sekali. =)

@SimonSapin Saya tidak berpikir kita bisa menstabilkan sintaks ekspresi a..=b tanpa menstabilkan struct. Namun kami dapat membiarkan bidang tersebut tidak stabil, jika kami pikir kami dapat mengubahnya.

Benar, saya tidak bermaksud mengatakan bahwa kita tidak boleh menstabilkan tipe saat menstabilkan sintaks untuk membangun nilai tipe ini.

Huzzah untuk melarikan diri dari jangkauan sintaks bikeshed dan menstabilkan! :tada:

Diberikan mesin waktu, saya berpendapat bahwa tidak ada satu pun dari jenis Rentang yang :Iterator , dan mereka hanya :IntoIterator . Tapi seperti sekarang, saya pikir konsistensi dengan Range adalah pilihan terbaik. Kita dapat menempatkan kasus ini dengan Chain di ember "baik, ternyata iterasi internal terkadang

Satu hal lain yang belum terselesaikan, juga terkait dengan iterasi: apakah kita ingin berkomitmen pada representasi tertentu dari RangeInclusive setelah selesai melakukan iterasi? Saat ini berakhir di 1..=0 , tetapi ada opsi lain yang dibahas . Saya tidak tahu apakah dokumentasi akan cukup untuk membuat orang tidak bergantung padanya, meskipun yang saat ini membuat rentang pasca-iterasi sangat tidak berguna, yang setidaknya mencegahnya.

Kita dapat menempatkan kasus ini dengan Chain di "well, ternyata iterasi internal terkadang lebih cepat".

Saya pikir kami benar-benar perlu memperbaikinya agar memiliki kinerja yang tidak kalah dengan jajaran eksklusif; tidak ada alasan mendasar untuk itu.

tidak ada alasan _fundamental_ untuk itu.

Itu tergantung pada invarian apa yang bisa kita terapkan. Dalam dua formulasi sebelumnya dengan sedikit status tambahan, tidak ada yang memaksa bahwa bit itu benar-benar disetel ketika kami selesai mengulangi (dan sebenarnya itu _tidak_ disetel pada literal seperti 100..=0 ), jadi perulangan kondisi keluar perlu majemuk, yang berarti bahwa LLVM tidak lagi bersedia membuka gulungannya untuk kita, sehingga kita mendapatkan kinerja yang lebih buruk. Memperbaiki sepenuhnya yang sepertinya berarti membuat struct lebih besar dan tidak memiliki bidang pub, membuat RangeInclusive: !Iterator , atau membuat LLVM lebih baik dalam mengoptimalkan loop semacam ini.

Yang mengatakan, saya mencoba beberapa cara berbeda untuk menulis RangeInclusive::next , dan sepertinya pilihan masa lalu saya untuk mencocokkan pada Option<Ordering> membuat LLVM sangat sedih--hanya menempatkan operator perbandingan di sana alih-alih memberi perakitan yang jauh lebih baik. Edit PR ke atas: https://github.com/rust-lang/rust/pull/48057

Diberikan mesin waktu, saya berpendapat bahwa tidak ada satu pun dari tipe Range yang :Iterator, dan mereka hanya :IntoIterator. Tapi seperti sekarang, saya pikir konsistensi dengan Range adalah pilihan terbaik. Kita dapat menempatkan kasus ini dengan Chain di "well, ternyata iterasi internal terkadang lebih cepat".

Saya pada dasarnya setuju dengan ini.

:bell: Ini sekarang memasuki periode komentar terakhir , sesuai ulasan di atas . :lonceng:

:bell: Ini sekarang memasuki periode komentar terakhir , sesuai ulasan di atas . :lonceng:

@rfcbot fcp batal

@withoutboats dan @KodrAus belum mencentang kotak mereka.

@cramertj proposal dibatalkan.

@rfcbot menggabungkan

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

Anggota tim @cramertj telah mengusulkan untuk menggabungkan ini. Langkah selanjutnya adalah peninjauan oleh sisa tim yang ditandai:

• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @tanpa perahu

Tidak ada kekhawatiran saat ini terdaftar.

Setelah mayoritas pengulas menyetujui (dan tidak ada yang keberatan), ini akan memasuki periode komentar terakhirnya. Jika Anda menemukan masalah besar yang belum diangkat pada titik mana pun dalam proses ini, silakan angkat bicara!

Lihat dokumen ini untuk info tentang perintah apa yang dapat diberikan oleh anggota tim yang ditandai kepada saya.

:bell: Ini sekarang memasuki periode komentar terakhir , sesuai ulasan di atas . :lonceng:

@rfcbot fcp keprihatinan Pola rentang memiliki masalah prioritas operator - https://github.com/rust-lang/rust/issues/48501.

( @petrochenkov Sintaksnya adalah <strong i="6">@rfcbot</strong> concern KEYWORD , tanpa fcp . Namun saya pikir hanya anggota tim yang ditandai yang dapat mendaftarkan masalah.)

Periode komentar terakhir sekarang selesai.

Jika #48501 cukup untuk memblokir stabilisasi, saya kira kita harus menunda menunggu #48500 untuk bergabung (dan menstabilkan)? Ugh, kuharap kita bisa menemukan jalan yang lebih cepat. Fitur ini telah lama hadir dan sekarang dalam keadaan genting di mana pesan kesalahan mengarahkan orang ke sintaks yang tidak stabil.

@durka
Saya tidak berpikir stabilisasi ini perlu menunggu stabilisasi https://github.com/rust-lang/rust/pull/48500 .
... dalam pola masih ada dan masih memiliki prioritas lama, jadi jika Anda memiliki &BEGIN ... END dalam suatu pola (saya curiga ini sangat jarang) selalu ada opsi untuk tidak mengubahnya menjadi ..= untuk beberapa waktu.

Saya pikir kita bisa menstabilkan #48500 dengan cukup cepat

Secara pribadi saya akan baik-baik saja dengan mendaratkannya "insta-stable"

inclusive range telah distabilkan karena #47813 pull request telah digabungkan tetapi tidak dalam rilis 1,25, mengapa? Meskipun permintaan tarik digabung pada 16 Maret

@mominul fitur hanya tersedia setelah digabungkan ke cabang master, jadi ..= tersedia mulai dari 1,26, bukan 1,25.

Dengan begitu Anda dapat mengujinya dalam versi beta dan setiap malam sebelum didorong ke stabil.

Terima kasih atas masukannya @kennytm dan @clarcharr ! Rilis Rust 1.26 jelas tidak membosankan setidaknya bagi saya! :senyum:

Saya tahu sudah terlambat untuk ikut serta dalam diskusi ini, tetapi mengapa tidak menghilangkan sintaks .. seluruhnya dan menggunakan kata-kata saja?

Di Scala Anda memiliki 1 to 4 yang menghasilkan [1, 2, 3, 4] , 1 until 4 yang menghasilkan [1, 2, 3] , dan opsional by kata kunci yang mengikuti yang menunjukkan ukuran langkah : 1 to 10 by 2 = [1, 3, 5, 7, 9] .

Ini membuat maksud lebih jelas, dan menghindari kesalahan "satu demi satu" yang tampaknya sangat dikhawatirkan semua orang.

Memang, ini merusak semua kode yang ada, jika sintaks asli tidak tetap didukung.

@ElectricCoffee dalam rentang karat mendukung semua jenis, bukan hanya angka. Saya pikir kita perlu memperkenalkan to dan until sebagai kata kunci untuk mendukung itu, dan itu akan menjadi perubahan yang jauh lebih besar.

Ini bekerja dengan baik di Scala, tetapi pilihan desain Rust sangat berbeda.

@ElectricCoffee meskipun saya ingin merasakannya, saya rasa tidak perlu menambahkan kata kunci tambahan untuk itu.

Saya percaya kata kunci bahasa bawaan harus dijaga seminimal mungkin, karena mungkin bertabrakan dengan nama fungsi atau variabel.

Meskipun to dan until bukan kata-kata yang digunakan di std (sejauh yang saya tahu), saya yakin itu kata-kata umum yang digunakan untuk peti lain dan proyek.

@daboross itu sebenarnya poin yang adil yang tidak saya pertimbangkan, meskipun itu dikatakan, a .. b dalam arti tertentu berarti a to b , terlepas dari apa a dan b sebenarnya.

Dan ya, @timvisee mungkin begitu.

@ElectricCoffee Tetapi jika to berarti ..= dan until berarti .. Anda harus menulis a until b , bukan a to b bukannya a .. b . Seperti yang Anda lihat, tidak "lebih" intuitif untuk menggunakan kata-kata ini daripada operator.. Tetapi akan lebih bertele-tele untuk menulis until mana pun .. digunakan, karena itu jauh lebih umum daripada ..= (jadi jika kata-kata yang digunakan, .. harus diberi kata yang lebih pendek).

Dan Anda benar sekali tentang itu @Boscop , namun itu hanyalah contoh bagaimana kata-kata dapat dilakukan.

Saya yakin saya telah melihat to untuk eksklusif dan upto untuk inklusif dalam beberapa bahasa juga.
Itu semua dimaksudkan sebagai ide.

Di Scala, rentang inklusif lebih banyak digunakan daripada yang eksklusif, dan dengan demikian diberikan kata yang lebih pendek.

@timvisee Satu hanya dapat menggunakan a.to(b) dan a.until(b) , tidak ada kata kunci tambahan yang diperlukan (dan itu tidak membuat sintaks lebih canggung).

@ hyst329 Saya bahkan tidak memikirkannya. Saya harus mengatakan, saya sangat menyukai ide itu! Anda memang benar.

Saya tidak percaya bahwa ini akan menjadi pengganti penuh yang tepat untuk sintaks (/ baru) saat ini. Tapi itu akan menjadi tambahan yang bagus.

Saya harus setuju dengan komentar Boscop tentang intuisi. Selain kata-kata seperti "termasuk" dan "kecuali", bahasa Inggris sehari-hari tidak benar-benar membedakan antara rentang inklusif dan eksklusif dengan cukup kuat sehingga ada jalan pintas yang sudah jadi.

Kecuali jika digunakan dalam konteks di mana "A sampai B" juga digunakan, tidak jelas apakah "A sampai B" berarti rentang inklusif atau eksklusif dalam pidato sehari-hari di sini di Ontario selatan, Kanada, dan "sampai" dikaitkan dengan waktu yang cukup kuat sehingga, ketika digunakan dalam pengertian yang lebih longgar ini, tidak jelas apakah "peristiwa" yang dikaitkan dengan "sampai" adalah "sampai kita melihat X" atau "sampai kita memproses X".

@ hyst329 Memilikinya sebagai metode akan membatasi rentang ke jenis angka. Saya lebih suka tidak memiliki satu sintaks untuk rentang angka dan satu lagi untuk rentang hal lain.

Saya kira kita bisa menambahkan sifat catch-all baru ke pendahuluan untuk membuat rentang, tapi itu masih mendekati perubahan besar untuk hal-hal yang memiliki metode to dan until yang sebenarnya.

Saya akui, saya pikir saran kata kunci adalah lelucon April Mop.
Sintaks ..= telah distabilkan.

Pada Kamis, 5 April 2018 pukul 13.53, David Ross [email protected] menulis:

@ hyst329 https://github.com/hyst329 Memiliki mereka sebagai metode akan membatasi
berkisar ke jenis nomor, meskipun. Saya lebih suka tidak memiliki satu sintaks untuk
rentang angka dan satu lagi untuk rentang hal lain.

Saya kira kita bisa menambahkan sifat catch-all baru ke pendahuluan untuk membuat
rentang, tapi itu masih hampir berubah untuk hal-hal yang memiliki
aktual ke dan sampai metode.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-379021814 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAC3nwBj-b985q1Ez0OHDEHkG6DWV_5nks5tlloZgaJpZM4F4LbW
.

Ya, kami memiliki 300+ komentar tentang masalah ini, dan komentar pertama mengatakan:

tidak ada lagi diskusi sintaks yang harus dilakukan di utas ini . Setiap proposal sintaksis rentang eksklusif yang berbeda harus dilakukan di forum pengguna atau forum internal, setelah Anda membaca semua komentar yang ada dan alasannya di sini. Khususnya, melanggar kompatibilitas mundur adalah non-starter.

Saya akan mengunci masalah ini untuk saat ini, maaf jika saya menginjak kaki apa pun!

Saya percaya bahwa semua yang tercakup dalam masalah ini sudah selesai. Harap buka kembali dan perbarui daftar periksa di pesan asli masalah jika ada hal lain.