たぶんa..b|またはa..b]

これは、単純なタイプミス（.. vs ...）のために、将来、新しい種類の予測できないエラーへの道を開くと思います。 それが....（4期間）だった場合はより良いです。 このようにして、人的要因であるimoのエラーが発生しにくくなります。

https://github.com/rust-lang/rfcs/pull/1592とhttps://github.com/rust-lang/rfcs/pull/1582を組み合わせることで、 ..=を使用することができると思います。代わりに構文。 誰かがより大きなタプルの前にタプルを拡張するための(head..., tail)よりも優れた構文を考えられない限り。

私は排他的な範囲を使用することを意図してきたとき、私は私のコードで_off・バイ・ワンドット_誤りがあったので、私はこの問題を発見しました。

👎 ...構文の場合。 ミスタイプしやすい構文で1つずつエラーが発生するのは、足がかりになると思います。

ただし、この機能は便利なので、 ..=別の構文で使用できれば幸いです。

これの構文は未解決の質問ですか？ ...はすでにマッチステートメントに含まれているので、船は出航したと思いました。

個人的には...範囲を好みますが、すでに..専用バージョンがあるため、問題が発生する可能性があります。 ＃23635を見た後、 ..を廃止し、 ...のみを許可したいと思います。

私はCのようなforループfor i in 0..foo.len()に相当する包括的範囲をよく使用しているので、それをそのままにしておくことをお勧めします（Rustのイテレーターは「1次元」であり、多くの場合、これが必要です。 2D配列や非線形反復で使用するには扱いにくい）。

包括的範囲のオーバーフローの問題はばかげているように見えますが、Rustがusize以外のタイプで使用するのは面倒なので、実際にはこの問題に遭遇することはありません。 範囲for i in 0..(len as usize)作成するときにキャストしなかった場合は、とにかくループ内でi as usize半ダース回使用する必要があります。

この構文はまだ機能ゲートされているので、船が出航していないことを願っています。

swiftが包括的範囲に...を使用し、排他的範囲に..<を使用することを考えると、包括的に..=を使用することはかなり合理的と思われます。

有用な洞察はありませんが、包括的範囲で「実験的」ステータスを終了したいと思います。 Rust By Exampleを調べていたときに、これから恩恵を受けることができる1つのスニペットを見つけました。

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

上 ？ 😄

a ..= b構文と一般化された範囲のRFCを書きたい。 そのような範囲が標準ライブラリでどのように表されるかについて話すために、ディスカッションスレッドを開始しました。

IMHO .. =変に見えます。 Swiftの...と.. <のアプローチは、2つのドットよりも省略記号を好むため、私にはよく見えます。省略記号は省略を表し、範囲の開始と終了の間の数字を省略しています。

私はまだ...そして..十分に良かったと思います。 1文字の違いがあるので、間違いは+/-やx / yなどよりも難しいです。

私は以前にこれを自分で誤解したので（そして私のコメントを削除しました）：

RustのRFCプロセスによると、この提案はRFCプルリクエスト1192ですでにレビュー、議論、承認されてい

機能が異なるはずだと強く感じている場合は、同じRFCプロセスを実行する必要があると思います。これは、言語に変更が加えられる方法だからです。 しかし、この問題はそのための場所ではありません。

@jimblandyおそらく、 @ nikomatsakisにその丁寧なリマインダーとガイダンスをあります。 😇

@shepmasterこれは、

議論/可能性のあるFCPへの指名

これについては、@ rust-lang / langミーティングで話し合いました。 この機能には一般的な不幸感がありました。非推奨にすることを検討しましたが、当面はそれを保留することにしました。 現状では、 ...は2つの大きな反対意見があります。

• ..と...間の混乱のしやすさ;
• @aturonは、より「完全に機能する」範囲構文を使用する方がよいと考えていました。これは、btree反復などのAPIでも使用できます。

そのために、下限と上限のどちらを包括的か排他的かを正確に指定できるような、より一般的な構文を可能にするRFCを誰かが進んで進めてくれるのではないかと考えていました。 @aturonは、そのようなRFCで誰かと協力して喜んでいると思います。

しばらくストールしたことは知っていますが、最近、libstd（上記のリンク）でこれらの完全に機能する範囲を表す方法についてのディスカッションスレッドを開きましたが、誰もコメントしていません:(

上記に関するいくつかの入力があれば、新しいRFCを喜んでお手伝いします。

私は最近、libstd（上記のリンク）でこれらの完全に機能する範囲を表す方法についてのディスカッションスレッドを開きましたが、誰もコメントしていません:(

それは彼らの有用性を幾分反映しています。
任意の包括的排他的範囲を持つことは良い考えのように聞こえますが、 ..と、それよりもはるかに少ない程度で...を除くすべてが使用されることはないと確信しています。

@durka

しばらくストールしたことは知っていますが、libstd（上記のリンク）でこれらの完全に機能する範囲を表す方法についてディスカッションスレッドを開きましたが、誰もコメントしていません:(

これは、大まかに私たちが考えていたアプローチのように見えます。

@petrochenkov

任意の包括的-排他的範囲を持つことは良い考えのように聞こえますが、..を除いてすべてが使用されることはないと確信しています。

正直なところ、私は同意しますが、それでも、より一般的な構文を追求する価値があると思います。 特に、 ...は最適ではないと思いますが、 ..=などのより明示的なものに移行した場合、まれにでも、もう少し一般的なことをしても問題はないでしょう。使用済み。 つまり、体系的にすれば、習得するのはそれほど難しくはないように思われ、 ..と...どちらが「より多くの数」を意味するかについて混乱が生じることはないでしょう。 "。

これは、大まかに私たちが考えていたアプローチのように見えます。

どれ？ 私は自分の投稿でいくつかの代替案を提案しました。

私はしばしば包括的範囲を繰り返したいので、 0...x代わりに0..(x + 1) 0...x入力するのが本当に好き0..(x + 1) 。 これにより1つずつエラーが発生する可能性があることは理解していますが、どのような代替手段がありますか？

Rustの構文を副作用なしに自由に変更できると仮定すると、明らかなパターンはごくわずかです。

そのままで

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

これは大丈夫なソリューションIMHOであり、パターンマッチングでも使用されます。

数学から借りる

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

これは最も完全な構文ですが、同じ量の開閉中括弧の規則に違反し、視覚的に解析が困難です。

Pythonから借りる

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

これは既知のパターンであり、ステップサイズを組み込むこともできます。 RFCプロセスがどのように機能するかはわかりませんが、範囲について話すときはステップサイズも考慮する必要があると思います。

ステップサイズがこのディスカッション（または将来のディスカッション）の一部ではない場合、 ..=と..<は非常に合理的と思われます。

更新： ..=と..<は本当に良い解決策になると思います。 ステップサイズをアダプターとして維持することは、はるかに理にかなっています。

この議論には降順の範囲を組み込む必要がありますか？ 範囲を反転する現在の解決策は非常に混乱しています（ただし、包括的範囲がある場合はおそらくそうではありません）。

たとえば、目を細めることなくこれを読んで理解できますか？

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

編集：そしてGitHubのフォントでは、 lが1ように見えるため、さらに混乱します。

負のステップサイズで十分だと思います。

Matlab構文a:bとa:step:bます。

2016年11月4日00:50、「Ott」 [email protected]は次のように書いています。

負のステップサイズで十分だと思います。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment -258344460、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n3kwnGH6POQb4dGwCwJ8yOGqPSBQks5q6rmDgaJpZM4F4LbW
。

@durkaでは、現在の..に相当するものは何でしょうか。ここで、 aまたはbません。 たった: ？

RFCに記載されていないもの：フィールドに異なる名前が考慮されましたか？

タイプが異なる場合、意味が異なるときにフィールド名を変えると便利な場合があります。 たとえば、「range.start」はすべてのタイプの「下限を含む」です。 ただし、「range.end」は包括的である場合と排他的である場合があります。 「終わり」と（ストローマン）「最後」の区別はそれをより明確にします。

（もちろん、これは、範囲を優先して異なるタイプが放棄された場合は関係ありません。> ...）

包括的範囲はまだstd :: collections :: range :: RangeArgumentを実装する必要があると思います。

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

それで

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

fn foo<T, R: RangeArgument<T>>(arg: R)が包括的またはハーフオープンの範囲を取ることができるように。

@durka a：b構文の問題は、型の帰属があいまいなことです。 変数b 、またはタイプbを求めていますか？ 明らかに、優れたRustプログラマーとして、型を活用していますが、コンパイラーはそれを推測できません。

..数学定義を持つ演算子（ @dueseeコメントに基づく）：

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

使用（ @ 0ttの例に基づく）：

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

この場合、ヒントとして..を使用しますが、境界は[と]与えられます。

@adelarsq ：Rustでは、開始を含まない範囲は必要ありません。 ただし、角かっこ構文は、それらが許可されている場合にのみ意味があります。 さらに、ブラケット構文はすでに使用されています。

..=が包括的範囲の最も合理的な選択だと思います。
...はない..と視覚的に簡単に区別できます。 タイピングのチャンス...意味する場合.. 、またはその逆と気付いていないのとより高い..= 。
（これは、視覚的な目立ちやすさとバグの可能性の両方で、Cでif(a == b)代わりに誤ってif(a = b)入力することに相当します）。
また、 ..=は、その意味を象徴しているため、覚えやすいです（ i ..= jは、範囲i .. jを意味し、 i = j意味します）。

主な不満は、 ...が..とあまりにも似ていることだと思われます。 より多くの文字を含む他の提案がなされた場合、文字の数について誰も文句を言わず、括弧の一致や特定の場所での使用などだけであることに気づきました。
では、包括的範囲の....はどうでしょうか？ それはまだ範囲のように見えるはずです、そして私が言ったように、誰も余分な性格をとる解決策を気にしないようです。 それが..=よりも多かれ少なかれ不安定であるかどうかは議論の余地があります。
for i in 0....10 { println!("just a thought"); }

デフォルトの動作が包括的である場合..！ 演算子が使用されます（ほとんど否定として）。

....の問題は、 ...実際に存在する場合、混乱が生じることです。

Rubyとは正反対なので、 ...も好きではありません。

これまでのところ最良の選択肢は..=だと思います。

@adelarsq 、 ....演算子は... ....演算子を置き換えるので、 ..を実行しようとして、追加の.を追加すると、コンパイルになります。タイムエラー。 ....を実行しようとしてドットを忘れた場合も、エラーになります。

パターンマッチングでは、 ...を使用して包括的範囲を照合するため、包括的範囲の式にも...を使用するのが理にかなっています。
ステップ付きの範囲については、Haskell構文を使用します。例： 1,3..9 => [1,3,5,7]

ステップ/リバースなどの範囲の場合、複雑なリテラルではなく、古き良き関数（ある種のRangeコンストラクター）を使用したいと思います。

クワッドドット....で大丈夫です（ただし、 ..=は私見でも問題ありません）。 一貫性を保つために、パターンマッチングでも許可される可能性があります（最終的に... 、パターンの

私にとって..=は、 ....はない視覚的な意味です。

私はちょうど何かに気づきました：

数学では、 ∀ i: 0 ≤ i < 10と書くことができます。

for i in 0 ..< 10 { }

これは一貫しています。

ただし、ステートメント∀ i: 0 ≤ i ≤ 10は次のように変換されます

for i in 0 ..= 10 { }

ここで、≤は=に変換され、一貫性がないと感じます。

これはバイクシェディングかもしれませんが、

for x in 0 ..<= 10 { }

より正しいと感じます。 これは私のCのバックグラウンドが原因である可能性があります

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

「 iが10限り、何かをする」という意味になります。 CIでは、値を飛び越えて無限ループになる可能性があるため、ループ条件で==を使用しないことをお勧めします。 これはRustでは発生しませんが、 for i in 1 ..= 10をCに変換すると、まさにそれが示唆される可能性があります。

さらに進んで、

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

自明でしょう。

編集：これは、 =だけを使用すると混乱する可能性があることを示すための悪い逆の例です。 建設的というよりも混乱を招いたため、削除しました。

@duesee >=..>はどのように自明ですか？ <=..> （<= 10かつ> 0）であるべきではありませんか？
IMOそれは自明ではなく、不可解であり、オペレーターとしては長すぎます。
（演算子は3文字のIMOより長くすることはできません）。
ところで、私たちはすでに逆反復方向を表現する方法を持っています： .rev()
包括的範囲とおそらく.step_by()演算子のみが必要です。
このステップの構文はa .. b | s （および包括的範囲の場合： a ..= b | s ）になります。

@norru ：あなたの例for i in (1..l.len()).rev() { ... }は非常に非現実的です。ほとんどの場合、スライス（ for x in arr[1..].rev() { ... } ）を使用しますが、インデックススタイルの反復を使用する必要がある場合でも（基本的にのみ） i ）にない配列要素を変更するとき、私はまったく読みにくいとは思いません。 （ただし、引数がリテラルの数値でない場合は、通常、 ..前後にスペースを残します： (1 .. arr.len()).rev() ）

>=..> Rustオペレーターの魚の種類が増えました！

しかし、私は..<=大好きです（編集：ええと、 <= 0 =>ように見えるmatchを除いて:(）

• プレーンな..とは非常に異なります。
• ..=の+=意味はありません。
• Swiftの..<でも論理的に一貫しています。 両方の言語が収束する可能性があります！
• そして最も重要なことは、あなたがより少ないか、上部の1に

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

@Boscop ：数学の定義のように読んだら自明です： 10 >= i > 2 。 あなたの答えの残りのために：私は絶対に同意します。 2番目の部分は、将来の拡張のためにブロッカーを導入しないように、 ..=と..<=を再考する動機として意図されていました。 それに応じて回答を編集します。

..表記で警告またはエラーを発生させるフラグを取得することもできます

..をコードベースのどこにも表示したくない

..=にもう一度投票したいのですが

..<と..<=の欠点は、それらがすでに有効なコードであるということです（別の値と比較されている右オープンの排他的範囲）。

@thepowersgang

.. <および.. <=の欠点は、それらがすでに有効なコードであるということです（別の値と比較されている右オープンの排他的範囲）。

本当ですが、これが実際に問題になる可能性はかなり低いようですよね？

私はここにある他の提案よりも...を非常に好みます。しかし、別の構文を選択する必要がある場合は、 ..=

@nikomatsakis

..<と..<=オプションは、言語の文法の直感的なモデルを取得するプロセスを不釣り合いに複雑にしているという理由だけで反対しています。

もっと個人的な話ですが、私はそれらが少なくともターボフィッシュと同じくらい醜くてエレガントではないと思います。

私は一緒に行くと思います..右排他用および..=込み用として視覚的な優雅さの最適なバランス、直感的に把握することが容易であり、混乱への2つの困難を作る文法規則。

...本当に..と区別がつかないのですか？ なぜ私はそれがとても好きなのですか？

@tshepang

私は...が美的に魅力的であるため好きです...しかし、 if (x == 2) {ではなくif (x = 2) {を書くのと同じように、気づきにくいバグを引き起こす可能性があるのではないかと心配しているので、反対します。 C / C ++ではif (x == 2) { 。 （そして、それがどのような危険であることが判明したかは十分に確立されています。）

@ssokolow

リンティングまたはオプションフラグによってより適切に解決されるIMO。 単一のファイル/プロジェクトで表記を混合することはあまり使用されていません。

また、他のオプションよりも....を優先します。幅/間隔を2倍にすると、特に、両側に記号が隣接していることを考えると、その負のスペースが孤立している場合よりも目立つようになります。

@ssokolow

視覚的なエレガンス、直感的に理解しやすい文法規則、および2つを混同しにくいものの間の最良のバランスとして、..を右排他的に、.. =を包括的に使用します。

わたしにはできる。 主な問題は、他の場合の構文も必要かどうかです（たとえば、 <..<= ）。 個人的には、 ..と..=が99.5％のケースをカバーしていると感じています。 主なユースケースはdrainようなAPIだと思いますが、現在、そこではいます。

cc @ rust-lang / libs

まれなケースは、を使用して範囲を直接構築することに任せることができます
構造体リテラル。

2017年2月22日水曜日午後4時50分、ニコ・マサキス[email protected]
書きました：

@ssokolow https://github.com/ssokolow

私は..を右排他的に、.. =を包括的に最適なものとして使用します
視覚的なエレガンスと直感的に理解しやすい文法規則のバランス
把握し、2つを混同しにくくします。

わたしにはできる。 主なこだわりは、私たちも欲しいかどうかです
他の場合の構文（例：<.. <=）。 私は個人的にそれを感じます..そして.. =
ケースの99.5％のようにカバーします。 主なユースケースは、ドレインなどのAPIだと思います。
現在、そこでは明確なアプローチを採用しています
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range
。

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

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-281815665 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n-aKwYKFq4VI9RizL0GkzXXSjTPwks5rfK2ngaJpZM4F4LbW
。

..=もパターンで利用できるようになりますか？ そこでの既存の...構文はどうなるのでしょうか。

非推奨になる可能性があります。 しかし、その存在はかなり強力な前例です
少なくとも速記としてそれを使用します。

18:02の水曜日、2017年2月22日には、andrewtj [email protected]は書きました：

私はそれを取ります.. =パターンでも利用できるようになりますか？ どうなるか
そこに既存の...構文？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-281834007 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3nw_DaOMNxuIKw6ZFfXJW95QyijY4ks5rfL6DgaJpZM4F4LbW
。

@ durka @ andrewtj私たちはそれを非推奨にするだろうと思います。

..=は、 +=と同じ意味で演算子として使用できます。
tide ~使用することをお勧めします。たとえば、 0~9 、 'A'~'Z'です。

..=はどの操作に対応しますか？ -は明らかに実行不可能です。
1-9 == -8 。

20:04の水曜日、2017年2月22日には、Junfeng劉[email protected]
書きました：

.. =は、+ =と同じ意味で演算子として使用できます。
〜を使用することをお勧めします。たとえば、0〜9、 'A'〜'Z'です。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-281856846 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n7N2dM4DAzc_uc5JdHit4IJgyvYGks5rfNsPgaJpZM4F4LbW
。

@durka ..=代入演算子のように見えますが、ユースケースはまれである必要があります。 ~はサブではなく潮です。 ...を使用しても問題ありません。

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()  //  ()

申し訳ありませんが、私のフォントでも同じように見えます。 .. =が複合であるかどうか、私は尋ねていました
+ =のような代入演算子、それが実行する操作（対応する
+）？

20:29の水曜日、2017年2月22日には、Junfeng劉[email protected]
書きました：

@durka https://github.com/durka .. =割り当てのように見えます
演算子、ユースケースはまれでなければなりません。 〜はサブではなく潮です。

範囲のimplFill{{
fn fill（）->文字列{...}
}
RangeAssignのimplFillAsign{{
fn fill（＆mut self）{...}
}
（String :: new（ "abc"）.. String :: new（ "f"））。fill（）// "abcdef"
（String :: new（ "abc"）.. = String :: new（ "f"））。fill（）//（）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-281861478 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n39uqbADB1rNtBh3PBTRY2XBXOUNks5rfOD-gaJpZM4F4LbW
。

@durka @nikomatsakisわかりました、まあ、これがすぐに解決されることを願っています。 現在の状況は厄介であり、構文の変更も厄介です。

@pornel卑下...でmatch 、それは良い解決策ではないので、互換性を破ります。 私はまだ...が最も適切なものだと思っています（ただし、これはRubyの正反対ですが、Rubyistによって同様の問題が議論されていません）。

@ hyst329ただし、 ...はエラーの影響を受けやすくなります。これは、 .を

非推奨は物事を壊しません。 古い構文は既存のプログラムで永久にサポートされる必要がありますが、ユーザーはドキュメントとrustfmtを介して新しい構文に向けて操作できます。

ただし、ユーザーはドキュメントとrustfmtを介して新しい構文に誘導できます。

そのためにrustfmtを使用しないことを強くお勧めします。 「変更を自動的に適用する」モードで使用すると、タイプミスをより目的のあるものに静かに変換できるため、フットガン風の...品質が悪化します。 （したがって、後の検査で見落としやすくなります。）

自動修正できない「意味を確認して..または..=いずれかを使用してください」というコンパイラの警告は、ヒューマンエラーの可能性。

フットガンが存在しないパターンの既存の...コンテキストで話していたことに注意してください。 現在、Rustは一時的なフットガンのない状況にあり、パターンでは...のみが許可され、式では..のみが許可されるため、どちらもタイプミスから安全です。

もちろん、式の...を..=に変換することはお勧めしません。もちろん、タイプミスが永続的になるだけだからです。

ああ。 私はそれを忘れていました。 思い出させてくれてありがとう。

@adelarsq実際、 'a'..'z'や128u8..255u8ような一般的なエラーは、たとえば警告としてcargo-clippy簡単に統合できます。 また、 ..と...幅は明らかに異なります（もちろん、等幅フォントを使用する場合、それを使用しないことは、Rustだけでなく一般的にソースコードを書くための悪い考えです） 。

構文を...ではなく… （ユニコードの水平楕円）にすることができます。そうすれば、少なくとも誤って入力することはありません。

編集：ああ、誰もこの提案を真剣に扱っていませんでした：cry：ノイズでごめんなさい。

わかりません。最後に、GoogleDocsが自動的に...を省略記号に変換することを確認しました。 テキスト編集業界の主要プレーヤー。

また、誰もが便利作曲を入力するためのComposeキーを持っています。 。 彼らが欲しいとき…

Windowsでは、テンキーでAlt + 0133を使用して省略記号を入力できます。 …

同様のコードポイントベースのメカニズムは、X11ベースのデスクトップのスタックのさまざまなレイヤーに存在します（GTK +とX11入力スタックには独自の独立したソリューションがあることを覚えています）が、コードポイントを番号で覚えるのは非常に面倒です。

作曲はṽèŕÿ直感的なソリューションです。

私が覚えている唯一のWindowsAltシーケンスは、子供の頃に作成したすべてのDOSバッチファイルメニューのAlt + 219です。

現在の構文はすでに長い間存在しているので、それをすでに安定させて、この無限のバイクシェディングを止めましょう。

現在の構文を維持することは、多くの実際の欠点があるため、私たちができる最悪の事態です。 これは単なるバイクシェディングではありません-それは正しく行われるべきです。 スレッド全体をスキップして、 ..=構文がこれまでで最も受け入れられました...

この時点で死んだ馬を倒しているような気がしますが、考えてみると... ..と...の違いは、文字通り、可能な限り最小の文字の1つのコピーです。入力または読み取りが可能で、同一の文字のグループと混合され、他の方法では完全に区別できない場合に、非常に一般的で、しばしばイライラするほど見つけにくいエラークラス（1つずつエラー）を作成する可能性があります。人と機械に。

または、文字通り、世界の他の構文を実行することもできます。

一方では、その懸念に感謝します。他方では、現在の...パターンマッチング構文はすでに包括的であり、Rustの他の場所ですでに使用されている構文と完全に一致しています。

個人的には違いを認識するのに問題はありませんが、視力に問題がある人、または4kモニターと10ptフォントを使用している人はそうかもしれません。

しかし、コンセンサスは..= 、私もそれで大丈夫だと思います。

FWIW、 ..を意味するときに誤って...入力してしばらく気付かなかったという状況がありましたが、しばらくすると、プログラムが奇妙に動作する理由がわかりました。
そうです、もっと目に見える違いがあるはずです、そして..=が最も理にかなっています。

@ rust-lang / langディスカッションにノミネートします。 ..=を採用して、それを1日と呼ぶべきだと思います。 修正されたRFCが必要ですか？ 早くやれよ？ これには、パターン内の既存の...構文の非推奨が含まれますか？ （私はそう思います。）

範囲に...を使用しないことに強く賛成です。 それは、このスレッドまたはすでにRFCのスレッドで言及されているかどうかは知りませんが、他に...不当に似た見た目にされている.. 、我々はまた、使用することをお勧めします...将来的には、可変範囲IMOよりもはるかに重要な可変個引数ジェネリックの

..=は明らかなようで、比較的醜いのは..よりも一般的ではないことで正当化されます。

これには、パターン内の既存の...構文の非推奨が含まれますか？ （私はそう思います。）

これは良い考えのようです。 ...警告し、可能であればパターンで..と..=両方をサポートします。

構文を更新するための自動化ツールがなくても、多くの人に影響を与える警告を導入することには一般的に警戒していますが、 ...から..=への変更は特に簡単です。 また、非推奨にすることもできますが、そのようなツールができるまで警告にすることを延期します。 他のみんなはどう思いますか？

...はより「通常の」構文であるため、私は強く支持しています。 ..=を使用する言語はわかりませんが、 ..と...を使用する言語はたくさんあります。

..=に対する感情が強い場合は、視覚的な問題を回避し、再び無料にするために、包括的範囲構文を使用しないことをお勧めします（代わりに、 (a..b).inclusive()メソッドを選択します。これは私には十分簡潔に思えます）。可変個引数ジェネリックの場合は...アップします。

編集： (a..b).inclusive()に対する1つの良い議論は、残念ながら、 matchにはまだ... 、それを置き換える新しい構文がないということです。 ：混乱している：

@steveklabnikこれがこの（非常に長い）スレッドのどこかですでに言及されている場合はお詫びしますが、他のどの言語が排他的範囲と包括的範囲にそれぞれ..と...両方を使用していますか？

Rustには、他の言語の便利な機能と構文を採用した歴史がありますが、選択的に、必要に応じて拒否または適応します。

@joshtriplett Rubyは両方を使用しますが、意味が逆になります（ ..は包括的で、 ...は排他的です）。 Rubyでそれが良い考えだったとは思いません。両方を持っていると、さらに混乱する可能性がありますが、逆になります。

@joshtriplett私が最もよく知っているのはRubyです。 Perlから入手したと思いましたが、完全にはわかりません。 ..=よりも、Rubyから逆方向にセマンティクスを使用する方が問題あり

正直なところ、私は他の何よりも安定した包括的範囲構文を好み、 ..=に対する私の激しい嫌悪は個人的なものであり、合理的な人々が同意しない可能性があることを認識しています。

@steveklabnik Swiftは..<を使用していると思いますよね？ これは..=似ているように見えますが、（imo）間違ったケースを最適化するという点でさらに悪いです。 =）

Swiftは.. <を排他的に使用し、...を包括的に使用します（これらの用語は
「ハーフオープン」および「クローズド」）。

私はまだ.. <（..を省略形として）と.. =が好きです。

しかし、別の未解決の質問（おそらくこの追跡の問題の範囲内ではない）は、閉じた範囲の構文を「ただ」採用するのか、それとも最初のポイントが開いた範囲の構文（構文？）を採用するのか、つまりストローマン> ..>と> .. =。

14:19の木、2017年3月16日には、ニコMatsakis [email protected]
書きました：

@steveklabnik https://github.com/steveklabnikSwiftは.. <を使用していると思います、
正しい？ これは.. =に似ているように見えますが、最適化するという点でさらに悪いです
（imo）間違ったケース。 =）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-287147321 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n0Wop5fJh9HVo7pSqo0riHm96Gm4ks5rmX1BgaJpZM4F4LbW
。

プレリュードにinclusive関数が含まれていてもかまいません。

for x in inclusive(1..10) {

}

一致との対称性が説得力のある議論だと感じたことはありません。 排他的な..パターンを追加することにしたと思いますが、それらも嫌いです。パターンの値がパターンと一致しなくなりました。 範囲の一致は、範囲の反復とは根本的に異なります。対称である必要がある理由はありません。 それでもオプションである場合、パターンで..を許可しないことを穏やかに好みますが、そうではないと思いますか？

..=と...両方の欠点は重要だと思います。 ..=はかなり奇妙ですが、 ...はオフの可能性を1エラー増やします。

このような終わりのないバグの可能性よりも、奇妙な外観の演算子を使用することをお勧めします（すべての言語で、他の言語にはない演算子が導入されます。たとえば、Swiftの..< 、F＃とScalaのすべての演算）。 とにかく人々はRustの本を読まなければならないでしょう。
多くの人がRubyからRustに来ていることを考えると、Rubyに比べて逆行するべきではありません。 （ ...は、オフの可能性を1エラー増加させるという議論に加えて。）
Swiftでは..<を受け入れても、Rustでは..=を受け入れないようにするにはどうすればよいですか？ ..=はそれほど奇妙ではありません。

パターンで範囲構文を拡張することは、AFAIKと同様に未解決の問題です。
一つには、 Enum::Variant(..)がすでに存在するため、完全に実行することはできません。
有効で、 Enum::Variant(RangeFull)を意味するように変更すると壊れます。

15:07の木、2017年3月16日には、Boscopの[email protected]は書きました：

奇妙に見える演算子を使用することをお勧めします（すべての言語で導入されます
他の人が持っていない演算子。たとえば、Swiftでは.. <、F＃ではすべての演算
およびScala）。 とにかく人々はRustの本を読まなければならないでしょう。
多くの人がRubyからRustに来ていることを考えると、
Rubyと比較して逆方向にあるべきではありません。 （議論に加えて
その...オフの可能性が1エラー増加します。）
Swiftでは.. <を受け入れますが、Rustでは.. =を受け入れないようにするにはどうすればよいですか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-287160485 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3nz9ZNR2utl7LPTVvQPQ_Ma8sDBGuks5rmYhmgaJpZM4F4LbW
。

そう。 slice.get(10...30)ようなものを入力して、ケーキも食べられるようにしたいと思います。

私は、他のどの構文よりもinclusive(0..10)を強く好むと確信しました。

• @nagisaはslice.get(10...30)を書きたいのですが、それがslice.get(10...30)かslice.get(10..30)か、細心の注意を払う必要はありません。 構文の近さは本当の問題だと思います。
• ..=は美的ではなく、おそらく直感的ではないことに誰もが同意していると思います。
• (0..10).inclusive()は同じ構文ですが、あまり便利ではありません。 技術的には、 inclusiveプレリュードはおそらく両方の構文をサポートします。

私はそれがこのように見えると思います：

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

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

私は誰もが同意すると思います.. =は美的ではなく、おそらく直感的ではありません。

それは少し一般化しすぎだと思います。 ..=は、 inclusive()ような方法よりも美的で直感的であることがわかりました。

（また、 ..=に対する嫌悪感のどれだけが、 ...ではないものの問題を見つけるための潜在意識（または意識的）な努力である可能性があるかはわかりません。）

.inclusive()は、非常に頻繁に発生するものには長すぎます（その点で、 .enumerate()は短い形式も必要だと思います）。
ただし、 .inclusive()があったとしても、関数は2つではなく、1つだけである必要があります。
さらに、包括的範囲構文がないと、 matchで使用できません。
しかし、 Scalaのように、一般的な方法でエクストラクターを指定する方法が必要なのかもしれません。 マッチで任意のタイプを使用できるようにするため、マッチは暗黙的にそのunapplyメソッドを呼び出します。

（また、.. =に対する嫌悪感のどれだけが、そうでないものの問題を見つけるための潜在意識（または意識的）な努力である可能性があるかはわかりません....）

私からはありません。 これは一種の悪意の告発です。

さらに、包括的範囲構文がないと、それらを一致して使用することはできません。

包括的範囲パターンは、 matchすでにサポートされています。 実際、今日パターンとしてサポートしている範囲はこれらだけです。

@withoutboatsええ、しかし私は「包括的範囲構文がないと、それらを一致して使用することはできません」と言いました。 現在、構文はありますが、Scalaのようなエクストラクタがないと一致して使用できないため、私の議論は.inclusive()に反対しました。 そして、この問題の要点は、包括的範囲構文は、一致してのみ機能し、現在の構文の代わりに構文を決定する特別なケースであってはならないということです。

包括的： for i in 1..10! { }

Java / C / C ++で15年以上働いている人として、 ..と...はかなり混乱していて、入力ミスだけでバグが発生する可能性があることがわかりました。 また、Rubyとの関係は、これをさらに混乱させます。 そのため、 ..=またはその他の代替手段が適しています。

私の「帽子」をリングに投げる：

for i in 1..10^

正しい値がずっと_up_になることを象徴する帽子/キャレット。

@leebenson個人的には、外側にタックを付けずに、真ん中に置いた方がいいと思います。

for i in 1..^10

@ retep998送信を

@ retep998 ..=よりもはるかに良い..^提案が好きです; それはその意味をはるかに喚起しているように見え、拡張代入演算子（ +=や*= ）の奇妙な変形のように見えることを避けます。 そうは言っても、どちらも...よりはるかに優れています。

..^後回しにすることはできません。

個人的なレベルでは、それは非常に醜いです（ ..は、多くのフォントで^から垂直方向に切り離されているためです）。

UI / UXの人として、それは自分の利益のために賢すぎる例だと思います。

別の言語から来て..^ 、それを範囲として認識できない場合があります（私が知っている限り、 5..^15は15! - 4!奇妙な部分的因子計画の省略形である可能性があります

（文脈で考えなかった場合、 ...は、「コールバックがここに挿入される」または「イベントを発行する」のようなものを意味する可能性があります。最も直接的な例を示します。矢印に似ていることで「ずっと上に行く」という意味を与えることは、新参者の期待とどのように相互作用するかという点で、手先の早業で魔法のトリックを行うようなものです。）

対照的に、 =は、割り当てのアクションと平等の概念の両方を参照する前例があり、 ..=に最も近いため、「奇妙なべき乗構文」のような誤解はありません。割り当て演算子によってまだ処理されていない「割り当て+等式」は、「右側の数字で終わる数列と関係がある」です...これは、範囲構文が行うことのあいまいですが適切な定義です。

また、 ..^がコンテキストでの使用から範囲構文であることを認識したとしても、 ^は意味がないため、最初は包括的か排他的かが直感的にわからないのではないかと心配しています。関連するコンテキストでの2..^8は、2から始まり、前のステップを8の累乗でステップするオープンエンド範囲の省略形である可能性があります（つまり、 2..Inf^8は、「2から無限大まで8ステップで繰り返す」の省略形である2..+8 2..Inf^8とは対照的です。）

whileループを作成するとき、人々は< （排他的）と<= （包括的）の観点から考えることに慣れているため、この問題は..=によっても回避されます。およびCスタイルのforループ。

@ssokolow合法的な分析。

個人的には、 ..=または..^いずれかを後回しにすることができます。 どちらの記号も私には意味があります。つまり、それぞれ「最大」または「最大」または単に「最大」です。 私の考えでは、どちらも同じ意味です。

私たちは皆、他の言語からの歴史を持ち込み、それとともに、汚染された象徴/偏見を持っているので、誰もが満足するものを思い付くのは難しいでしょう。 たとえば、前に挿入すると「ステップ」または指数を表す感覚があったのに対し、接尾辞は範囲を汚染せず、どういうわけかより純粋な感覚を残したため、最初に^記号を数字の_後_に追加しました。 しかし、それは私だけです。

いずれにせよ、私は、右側のvalを暗黙的に+1する関数呼び出しよりも、何らかの形式の省略表記を好むでしょう。 これは、関数呼び出しのように感じるものに委任するには構文が一般的すぎるという以前のコメントに同意します。 私も...気にしませんが、確かに、それはおそらく新しい服の= / ==バグであり、誰かを足で撃つことになります...

多くの人が積極的に嫌いなようです.. =誰も否定的なことを言いませんでした
約....それは静かに無視されました（いくつかの親指を除いて）私は
私はそれを再び持ち出し、人々にそれを考えてもらい、
彼らがそれに反対しているならそれを使わない理由。

それはただのノイズなので、私はそれについて言及することさえ嫌いですが、どうでしょうか。：
（ドットコロン）包括的ですか？ ドットは3つですが2文字で、
形はそれを..と区別します。

11:50時土、2017年3月18日には、リー・ベンソン[email protected]
書きました：

@ssokolowhttps ：//github.com/ssokolow正当な分析。

個人的には、.. =または.. ^のどちらかを後回しにすることができます。 どちらかの象徴
私には理にかなっています-つまり、「最大」または「最大」または単に「最大」、
それぞれ。 私の考えでは、どちらも同じ意味です。

みんなを満足させるものを思いつくのは難しいでしょう、
私たちは皆、他の言語から歴史を持ち込み、それとともに汚染されているからです
シンボル/バイアス。 最初に番号の後に^記号を追加しました。
たとえば、前に挿入すると「ステップ」を表す感覚があったためです。
または指数ですが、接尾辞は範囲を汚染せず、どういうわけかより純粋なままにしました
フィーリング。 しかし、それは私だけです。

いずれにせよ、私は何らかの形での速記法を好むでしょう。
右側の値を暗黙的に+1する関数呼び出し。 以前に同意します
これはあまりにも一般的な構文であり、
関数呼び出しのように感じます。 私も気にしません...しかし、確かに、それは
おそらく= / ==新しい服のバグで、誰かを撃つことになります
足...

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-287566556 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AIhJ6jWgPwndKaQvVjULlV_OoC6WDO0Cks5rnCeLgaJpZM4F4LbW
。

ああ、これはまだバイクシェッド段階ですか？ 😆

振り返ってみると、 ..=して、1日と呼ぶことに同意すると思います。 ..と...の類似性は微妙すぎるため、可変個引数のジェネリックス（https://github.com/）にあいまいさを持たずに...トークンを使用したいと思います。 rust-lang / rfcs / pull / 1935）、2つの間の混乱を少なくするための非常に明確な目的を果たします。

すべてのハーフオープンバリアントに対してより一般化された構文が必要かどうかはわかりませんが、 ..および..=以外の言語構文を提供する価値はないと思います。 。

それはただのノイズなので、私はそれについて言及することさえ嫌いですが、包括的であるために。:(ドットコロン）はどうですか？

@ssokolowは、UI /賢いという点でいくつかの素晴らしい点を挙げたと思います。 目を騙して他の何かを見るようにするために3番目のドットの方向を切り替えることは、おそらくそのカテゴリに含まれると思います。

私は個人的に、3番目のドットがあることに_ゼロ_異議を唱えていますが、最終的には一部の人をつまずかせることになっていることを知っています。 しかし、説明するのも非常に簡単なので、巧妙な回避策を設計する責任が言語にあるべきかどうかはわかりません。 '2ドットは排他的です。 3ドットを含む '本当に把握/デバッグするのは難しいですか？

いずれにせよ、誰が最終決定を下し、これを終わらせるための次のステップは何ですか？ 3番目のキャラクターについて話し合う18か月は、おそらくこの時点でバイクシェディングです😄

同意しました、^はそれをステップのように見せます。
..はop=演算子とのIMOの不一致は、 a = a .. bの意味でa ..= bを持つ方法がないため問題ありません。演算子ではなく、範囲を構築するためのシンタックスシュガーです（そして、任意のopが自動的にop=と..形式を取得する一般的なopオーバーロードスキームはありません）。
ドキュメントを見なくても..=が明確だと言っているのではありません。 しかし、人々がドキュメントを見ると、覚えやすくなり、とにかくドキュメントを見る必要があります。

@nikomatsakisの指名を考えると、来週のlang-teamミーティングでそれについて話し合い、その時点で電話をかけることになると思います。 私は、これにはlangチームが電話をかけてバイクシェディングを終了するだけでよいことに同意します。

また、 ..^がコンテキストでの使用から範囲構文であることを認識したとしても、最初はそれが包括的であるか排他的であるかが直感的にわからないのではないかと心配しています。

同意しました。 実際、私はすでにPerl 6でこの構文を見てきました。ここでは、ここでの提案とは逆に、排他的を意味します。

@solsonそれはそれに対して非常に説得力のある議論です。

Perlは完全に一般的な構文を持っているようで、..は包括的を意味します（両方で
側面）と^のいずれかの側は、その境界を排他的にします。

18:51時土、2017年3月18日には、ジョシュ・トリプレット[email protected]
書きました：

@solsonhttps ：//github.com/solsonそれは非常に説得力のある議論です
それに対して。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-287580739 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n7Fnn1_t9BkYOhfS-7oCaGlVff2aks5rnF_5gaJpZM4F4LbW
。

申し訳ありませんが、@ rust-lang / langミーティングでこの問題について話し合ったとき、コンセンサスに達することができませんでした。 特に@withoutboatsにはいくつかの厳しい予約があり、うまくいけば自分たちで放映することができます。

私たちが議論したいくつかの主要なポイント：

• 式とパターンに包括的範囲構文がある場合、それは同じである必要があります
  
  
  
  • つまり、 x ..= yを採用する場合、既存のx...yパターン構文を廃止することを意味します。
  
  
• 魅力的なオプションは、「何もしない」ことで、 (x..y).inclusive()などと書くだけです。 ただし、それはパターンでは機能しません（おそらくx...y ）。 これはそれ自身のいくつかの質問を提起します：
  
  
  
  • それでも排他的な範囲パターンが必要ですか？ 例： match 3 { 1..3 => false, .. }
    
    
    
    
    
    • もしそうなら、私たちは同じ潜在的な混乱を持っています！
    
    
    
  
  
  • @withoutboatsは、おそらくそのようなパターンは必要ないと考えているようです。 私自身と@joshtriplettはこれを絶対に必要だと感じています。 =）
  
  
• 排他的範囲パターンに関する別の問題は、（不安定な）スライスパターンとの相互作用が不十分であることです（詳細については、https：//github.com/rust-lang/rust/issues/23121を参照してください）。

この議論から生まれたのは、相反するすべての要素を一度に決定するのが良いということだと思います。 言い換えれば、解決する決定を採用するには：

• 排他的範囲式についてはどうすればよいですか？
• 既存の排他的範囲パターンを非推奨/変更する必要が
• 包括的範囲パターンについてはどうすればよいですか？
• スライスパターンはどうしたらいいですか？

この記事を書き始める前に、会話の各瞬間で私たち全員が実際に同じ概念について話していることを非常に不確かに感じたことを言いたいと思います。 たとえば、ニコは「排他的な範囲パターンは、必要になるまでは無関係に見える」と言っていますが、当時、ニコとジョシュは包括的な範囲表現について話していたと思いました。

（そして、ニコの投稿の最後の部分で、現在「排他的範囲式」を読んでいる最初の箇条書きは「包括的範囲式」と言うべきだと思います。）

TL; DR私の意見

範囲式について：

• ...でも..=でもない、包括的範囲式の構文を導入しないでください。
• 排他的範囲値を取り、包括的範囲値を返す関数をプレリュードに追加する必要があります。 したがって、 inclusive(0..10)と記述します（名前はバイクシェッドにすることができます）。

範囲パターンについて：

• 排他的な範囲パターン、またはそれを作成する方法を導入するべきではありません。

言い換えれば、私たちが行うべき唯一の重要な変更は、libsの変更です。つまり、プレリュードに関数を追加します。

範囲式

私の議論の基本は、包括的範囲の値を反復処理することはまれなニーズであるという事実です。 これは、RFCが18か月前に受け入れられたにもかかわらず、実装の問題ではなく、トレードオフに満足していないために、この機能をまだ安定させていないという事実によって裏付けられていると思います。

包括的範囲式は、それらを作成する簡単な方法をサポートするのに十分な頻度で必要になると思いますが、これまでに説明した構文の欠点を克服するのに十分な頻度ではありません。

特に、すべての構文ソリューションが共有している欠点は、それらのどれも実際には自己文書化されていないことです。 0...10または0..=10が包括的範囲式であることは比較的明白ではありません。 それらに遭遇することは比較的まれであるため、これは、初めてそれらに遭遇するユーザーにとってつまずきになります。

つまり、ユーザーが「通常の」 ..範囲を処理していないことに気付いた場合です。 もちろん、これは...の大きな問題ですが、 ..=問題が完全に解消されるわけではありません。 コードをざっと読むと、その1つの=文字（または^または:など）を見逃すのは簡単です。 余分な.ほど簡単ではありませんが、私はその目立つことを十分に確信していません。

私は実際、 ...と..=間には「注目度と自明性」のトレードオフがあると思います。 ...何を意味するのか（2つの構文が反対の意味を持つRubyから来ている場合を除いて）は..=よりも明白だと思いますが、それほど目立たないことは間違いあり

しかし、 inclusive(0..10)ようなプレリュード関数は、これまでに説明したどの構文よりも明白であり、注目に値するものだと思います。 はい、入力する文字数は多くなりますが、その属性の欠点は使用頻度に関連しています。

また、解析とトークン化の問題を回避し、 (0..10).filterなどを記述する必要がある（非常に厄介な）範囲とメソッドの優先順位の問題でユーザーを支援します。

範囲パターン

..追加すべきではないと思う主な理由は、スライスパターンの周りにあいまいさが生じるためです。これは便利だと思います。 その問題を解決する必要がないことで解決したいと思います。

2番目の理由は、彼らがかなり悪いスタイルだと思うことです（他の人が同意しないことを私は知っています）。 例えば：

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

10はそれを含むパターンと一致しないため、これは混乱を招くと思います。 ニコは、これは10を生成しない排他的範囲式と実際には違いはないと述べましたが、大きな違いは、排他的をサポートするためのDijsktraスタイルの歴史的先例（およびユースケース）がたくさんあることです。範囲。 Rustに入って、私は反復とスライスの範囲が排他的であることを期待していましたが、パターンについてはその期待を持っていませんでした。

また、式の.. / ...にある「オフバイワン」の問題もあります。

私はニコが彼が書きたいと言ったことを知っています：

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

しかし、私は本当に強く見たいと思います：

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

とにかく、ニコが時々これらを「絶対に必要」だと思っていることに驚いたので、もっと反論を聞きたいです。 それらはconstexprでなければならないので、私にとっては「絶対に必要な」ものというよりも「持っているといい」のように思えます。

包括的範囲表現よりも排他的範囲パターンの方が確実に揺れやすいと思います。

一貫性の議論

ニコは、表現とパターンの両方に..と...両方を含めることが、一貫性のために彼にとって重要であると述べました。 私は基本的にこの議論にまったく動じていません。 範囲を反復処理することと範囲を照合することは、実際には類似した操作ではなく、それらの処理方法に違いがあることは理にかなっています。

実際、実装接続すらありません。 1..10は範囲値を生成しますが、 1...10は整数値と一致します。 ほとんどの対称的な式/パターン構文のように、構造化/破壊化の接続があるわけではありません。

パターンを「範囲パターン」よりも「ドメインパターン」と呼ぶ方が技術的に正しいようです🤓これは非類似性を強調しています。

@withoutboats

たとえば、ニコは「排他的な範囲パターンは、必要になるまでは無関係に見える」と言っていますが、当時、ニコとジョシュは包括的な範囲表現について話していたと思いました。

私の側では、さまざまな時点で排他的範囲と包括的範囲の両方が必要であることがわかりました（ただし、安定したRustで作業するために両方のケースで排他的を使用し、上部に+1して回避する必要がありました。バウンド）。 パターンと表現の両方で利用できるようにしたいと思います。

とはいえ、個人的には、包括的範囲と排他的範囲の両方をパターンで記述する方法が必要な場合を除いて、包括的範囲の関数を使用することに異論はありません。これら2つの構文が紛らわしく似ていないようにしたいと思います。 ..と...ように。 そして、そのような範囲をパターンで記述するための構文を考えると、式のそのような範囲に対して異なる構文を使用することが理にかなっていることを私は知りません。

特に、すべての構文ソリューションが共有している欠点は、それらのどれも実際には自己文書化されていないことです。 0 ... 10または0 .. = 10が包括的範囲式であることは比較的明白ではありません。 それらに遭遇することは比較的まれであるため、これは、初めてそれらに遭遇するユーザーにとってつまずきになります。

私はこれに同意します。 これは非常にまれにしか発生しないので、構文がコンパクトでないことに異論はありません。 私は、しかし、式とパターンの両方における包括的かつ排他的な範囲を記述するためにいくつかのメカニズムを持っていると思います。

たとえば、包括的範囲パターンを作成するためにマクロなどが必要な場合でもかまいません。

@joshtriplettあなたがこれを言うとき、これは私が本当に明確にしたいところです：

さまざまな時点で排他的範囲と包括的範囲の両方が必要であることがわかりました（ただし、安定したRustで作業するには両方の場合に排他的を使用し、上限を+1にして回避する必要がありました）。

あなたが表現について話していることは明らかですが、あなたが引用したセクションはパターンについてでした（あなたが次の段落でパターンについて話していることは知っていますが、その段落が扱っていない「必要性」の問題について尋ねています😃） 。

パターンの現状は、 x...y形式の包括的範囲パターンのみをサポートしているということです。 排他的な範囲パターンが本当に欲求不満であることがわかった場合/いつ、それについてもっと話すことができますか？

@withoutboats

排他的な範囲パターンが本当に欲求不満であることがわかった場合/いつ、それについてもっと話すことができますか？

何かのようなもの

    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> */ }
    }

特にイライラするとは言えませんが、最初の方が確かに見栄えがします。

@withoutboatsわかりやすくするために、さまざまな時点で、排他的範囲式、包括的範囲式、および包括的範囲パターンが必要でした。 排他的なレンジパターンを持っていることに深く気を配っていた時代を思いとどまらせることはできませんが、それらにも反対はしません。 ただし、排他的な範囲パターンがない場合でも、包括的範囲パターンで...を使用し、排他的範囲式で..使用すると、非常に混乱します。

@petrochenkov私はそれらがFではなくC Fで終わることを意図していたと思いますか？

0x8000...0x9FFF => /* body */ 16進範囲パターンで同じケースに遭遇しました。 0x8000..0xA000は、少し直感的なプロパティがあることがわかりました。たとえば、それについて考える必要がない場合、範囲のサイズが0xA000 - 0x8000 = 0x2000あり、次の隣接する範囲が0xA000から始まることがすぐにわかります。

これらの事実を包括的範囲で確認するために必要な+1対処することは、私が生きることができる小さな違いですが、排他的範囲（パターンと表現の両方）は通常、私の仕事により適しています。

@petrochenkovなぜあなたが16進数の排他的範囲を好むのかがわかります（私はまだそうではないかもしれませんが、これは非常にYMMVの取引のように感じます）。

しかし、スライス構文のあいまいさをどのように処理しますか？

@joshtriplett

包括的範囲パターンが...を使用し、排他的範囲式が..使用する場合、それでも非常に混乱します。

これがRustの今日の仕組みであり、大きな混乱の原因ではないように思われますか？

@solson

それらはCではなくFで終わることを意図していたと思いますか？

番号 ：）
（これらは32ビットで、 offsetは4の倍数です。）

@withoutboats

なぜあなたが16進数の排他的範囲を好むのかがわかります（私はまだそうではないかもしれませんが、これは非常にYMMVの取引のように感じます）。

注意する必要がありますが、これは強い好みではありません。排他的パターンと包括的範囲の両方を削除しても問題ありません（ただし、そのうちの1つではなく、ばかげすぎます）。

しかし、スライス構文のあいまいさをどのように処理しますか？

簡単に！ PATTERN.. => .. @ PATTERN

包括的範囲を単純にしたい主な理由は、変数で停止値を渡す状況に何度も遭遇したことです。これは、1つの変数タイプが保持できる最大値であるため、唯一の解決策です。コンパイル時にオーバーフローを除外するには、次のようにします。

1. 包括的範囲を使用する（最もクリーンですが、安定していません）
2. + 1前のアップキャスト（私はまだu64に参加しておらず、エレガントではないと仮定します）
3. 範囲の値の小さい方と最大のマイナス1を取り、必要に応じてタスクをもう一度実行します。

固有の目的がないアルゴリズムに+ 1を追加するのではなく、包括的範囲を使用する習慣を構築することは、後でcargo fuzz再び遭遇するのを防ぐための重要な方法です... + 1よりも名前に多くの文字が含まれる「排他的から包括的」関数は、包括的範囲は、習慣的に使用する必要があるものではなく、例外的なものであるという印象を与えます。

それが私が反対する最大の理由の1つです。 これは、包括的範囲がハックであり、排他的範囲が失敗したことが実証された場合に使用されるという印象を伝えます。

@ssokolowですが、そのユースケースはプレリュード関数で快適にカバーされています。 包括的範囲を作成することは不可能であるという立場をとっている人は誰もいません。それらを作成するための構文糖衣が必要かどうかだけです。

プレリュード関数の@withoutboatsのアイデアが好き

@withoutboatsあなたが応答している間、私は自分の投稿にかなりの+ 1を追加するよりも長い構文で）包括的範囲を二級市民にすることです）、それらを使用することに対する微妙な落胆のように感じ、「後でcargo fuzzでお会いしましょう」というフットガンの可能性があります。

他に何もないとしても、それは教えやすさの疣贅です。

RustはPython3.xではなく、無制限の整数をサポートしています。 Rustは、ハードウェアのトレードオフをユーザーから隠しません。私が好む..=は、 int代わりにu32とその友人を使用することの一部として見ています。 （特に、オーバーフロー/アンダーフローエラーがcargo fuzzの「トロフィーケース」で最も一般的なものであることを考えると。）

編集：このための電子メール通知にのみ表示されるビットは無視してください。 目が覚めたばかりで、まだすべてのシリンダーで発砲していません。

inclusive(n..m)を落胆とはまったく思っていません... n..(m + 1)とn..=m両方よりもコードを読みやすくする非常に明確な構造であるため、これを書きたいと思います。

n..=mは、 inclusive(n..m) IMOよりも教育性の疣贅です。

一致させるには、特定のタイプのパターンではなく、数値範囲を完全にカバーしたいという要望があると思います。

おそらく、「前から続行」構文があれば、問題も解決するでしょう。

ところで、最初のパターンのみが一致するため、開始番号は省略できることがよくあります。

    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> */ }
    }

私はこれが視点の問題かもしれないことを認めます、しかし：

1. ..と..=を見ると、「ええと、なぜこんなに小さな違いで2つの構文があるのだろうか」と思うので、焦点を当てることができるドキュメントを探しに行くことになります。 " 1..pivotおよびpivot..end "対 " x..=yここでyは可能な最大値である可能性があります"。

2. 可変サイズの観点から習慣的に考えるのに十分な経験を積む前は、 inclusive()よりも+ 1を使用していました（探していたとしても）。 + 1小学校以来、短くて入力しやすいです。私の経験の浅い自己は、PythonやJavaScriptのような言語での作業に慣れており、加算によってオーバーフローが発生することは人々が心配することではありません。

編集： ...そして、私たちが焦点を当てるべきだと思うのは、ポイント1の概念的な違いです。 （つまり、「Xからピボットへ」と「Xからエンドへ」はプログラマーの心の中で区別されるべきです。）

@pornel
これはひどいです😄
この特定のケースでは、範囲の開始は、コードを読む人にとって本当に重要であり、包括的/排他的な範囲の問題よりもはるかに重要です。

@ssokolow +1を問題にしているのは文字数ではなく、オーバーフローの可能性を処理する必要があるように思えます。 また、意図も伝達せず、優先順位括弧をラングリングする必要があります。 これらはすべて、文字の数よりもはるかに重要であるように思われます。

オーバーフローについて知らない本当の人は、包括的範囲を作成する前に+1に到達する可能性がありますが、これは構文に依存していないようです。 ..=が物であり、 inclusive()が物であることに気付くと、包括的範囲が特に必要な理由を学ぶための教えられる瞬間が生まれます。

@petrochenkov

排他的パターンと包括的範囲の両方を削除しても問題ありません（ただし、そのうちの1つではなく、ばかげすぎます） 。

なぜあなたがこれについてとても強く感じるのかについて詳しく教えてください。 排他的なパターンを受け入れることは、ユーザーが式として0...10を期待する可能性があるという欠点があるだけだと確信していますが、私にとってはそれほど

inclusive()に関する私の問題の一部は、それが「単なる」関数であり、Rust構文インデックスに移動し、「範囲」または「イテレータ」を検索して、ROIが不十分であると想定するなどのことを人々が行うのではないかと心配しています。 「See [ing] Iterators」の場合。

（「偶然に教科書を読みたくないので、何か役に立つものが見つかります。..範囲を繰り返して、進歩に戻りたいだけです。」）

@withoutboats包括的（a..b）があるが、それをマッチで使用できない場合、IMOの価値はありません。
包括的範囲を使用している場合、ほとんどの場合、一致パターンになっています。
では、なぜ...を削除して、試合の内外で..=使用できないのでしょうか。

@Boscopの提案は、一致する...を削除するのではなく、パターンを安定した状態のままにすることです。

@ssokolowは、 ..セクションのメモでかなり簡単に解決できるようです

@withoutboatsしかし、マッチで...を削除し、代わりに..=使用して、一貫性を保つのはなぜですか？
（試合の内外で..=ように）

浮動小数点の数値範囲カバレッジについては、排他的ヘルプが役立ちます。 たとえば、これらの境界の1つは完全にカバーされていますが、他の境界はカバーされていません。

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

そして、オーバーラップでそれを書くことは、代わりに不快に感じます（そして、上記の「腕が注文されているので、すべてを-∞から始める」と道徳的に似ています）。 1日は[00：00、23：59：59]ではなく[00：00、24：00）であるため、ISO8601でT24：00が許可される方法などの日時も参照してください。 または文字列、または有理数、または..。

排他的論理和または包括的論理和の選択を考えると、私は毎回排他的論理和を取ります。

（余談ですが、インデックス作成の1 <= x <= Nパターンは、実際には0 < x <= Nとして実行する方が適切です。これも排他的ですが、ダイクストラが言ったのと同じ理由で、半分開いているのではなく半分閉じています。 0ベースではなく1ベースのインデックスに切り替えました。）

この演算子は、私がここで提案したクランプ機能に非常に役立ちました： https ：

0.0..1.0 + EPSILON

それが正しいかどうかさえわかりませんが、現時点では、浮動小数点数の包括的範囲を宣言することは非常に困難です。

これを行う正しい方法nextafter 、イプシロンではなく、 x...y == x..nextafter(y) 。 ieee754クレートはそのような機能を公開し

おっと、私はinclusive(a..b)構文についてコメントしましたが、それが真実ではないことに気づきました。 とにかく、私はそれが好きですが、もっと良い名前を自転車に乗せることができるといいのですが。

@durka名前は私には明らかなようです。 それについての懸念について詳しく説明していただけますか？

だから、包括的な範囲については、我々は持っているでしょうa ... bでmatchとinclusive(a..b)試合の外？
一貫性を保ち、どこにでもa ..= bを設定できないのはなぜですか？

ops::{RangeInclusive, RangeToInclusive}が正式に安定するのを妨げるものはありますか？

今のところ、主要なブロッカーは構文に関する議論のようですが、その議論に関係なく、最終的な構文が何であるかに関係なく、包括的範囲が存在すると確信しています。

安定したライブラリを実装するためにこれらのタイプがあると便利です。そうすれば、これらのライブラリの利用者は、特別な構文を使用したい場合に機能フラグを有効にすることを決定できます。

先日RangeInclusiveについて気付いたことがあります。範囲を受け入れようとしている場合、コーディングするのは面倒です。 クランプスレッドは.clamp(1...9)許可することについて話していましたが、コードは次のようになります。

    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 }
            }
        }
    }

RangeInclusive::Emptyを処理する必要があるのは、適切な構文でペアを受け入れることだけが目的であるため、不要だと感じます。 列挙型でない場合は、 fn clamp(self, RangeInclusive { start, end }: RangeInclusive<Self>)であり、はるかにクリーンである可能性があります。

残念ながら、私はそれについて何をすべきかについて良い答えを持っていません。なぜなら、包括的であるが排他的ではない.into_iter（）を要求することも残念なことです...

ランダムなアイデア： ...パターン構文が包括的範囲タイプに実際に関連していないことを確認すると、ここで提案されている...とは無関係の構文を優先して、その構文を非推奨にすることを検討できます。

包括的範囲パターンは|パターンとより密接に関連しているため、 |...が適切な候補になる可能性があります。

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

最終的な結果として、包括的および排他的範囲構文は、パターンマッチングと1：1の関係がなくなり、一貫性を保つ必要がなくなります。

@scottmcm

残念ながら、私はそれについて何をすべきかについて良い答えを持っていません。なぜなら、包括的であるが排他的ではない.into_iter（）を要求することも残念なことです...

たぶん、空の範囲でパニックになり、ペアを返すrange.nonempty()ようなヘルパーを追加できますか？

または、 RangeInclusiveに対してIntoIteratorを実装することもできますが、IMHOからそれほど遠くはありません。

RangeInclusive :: Emptyはどのようなユースケースを提供しますか？ 包括的範囲に空の範囲を表す機能が必要なのはなぜですか？ どのように書きますか？ （「5から4までの範囲」のようなものをすでに書くことができることに注意してください。この反復はおそらく空として扱われます。）

@joshtriplettメインケースはオーバーフローですが、その問題を解決する方法はいくつかあります。

@joshtriplett start > endは、1つの重要なケース、 0u8...255u8 、空の包括的範囲を表すために実際には機能しません。 あなたがされたら255u8...255u8としてみてください.next()それは、どちらのパニックやラップになるだろう0u8...255u8空ではありません、。 その代わりに、その時点でEmptyバリアントに切り替えます。

@solsonああ、なるほど。 ええ、それは苦痛です、そしてそれ

（これらすべての場合で255u8を意味すると仮定します。）

（これらすべての場合で255u8を意味すると思います。）

そう、ありがとう。 編集しました。

@solsonただし、この場合は、0と255を交換することで修正できます。

@clarcharrそうですね。 .next()常にEmpty範囲の生成を特殊なケースにする必要があるため、空として扱われる範囲を常に生成する可能性があります。

個人的には、空の範囲が含まれていないので、その方法の方が好きです。

したがって、このスレッドは1年半続いています。 私はそれをすべて読み終え​​たところです。新参者のために簡潔な要約を投稿し、うまくいけば私たちが決定を下すのを手伝いたいと思います。

Rust Stableが今日行うこと：

0..5は、パターンマッチングで使用できないハーフオープン範囲[0、1、2、3、4]を表します
0...5は、パターンマッチングでのみ使用できる閉範囲[0、1、2、3、4、5]を表します。

パターンマッチング以外で使用できる追加の閉範囲構文については、いくつかの形式が提案されています。 それぞれとその長所と短所について説明します。

0...5

長所：既存のパターンマッチング構文と一貫性があり、パターンマッチング構文に変更が加えられていないことを前提として、言語のまとまりを感じさせます。

短所：タイプミスが発生しやすく、1つのエラーが原因で発生します。また、この演算子を使用してさまざまな概念を伝達する他の言語が原因で、意図を誤解しやすくなります。

0..=5

長所：タイプミスがより難しく、意味的に明確

短所：既存のパターンマッチング構文と矛盾しています。 ユーザーに質問をさせる可能性があります：なぜそれは...ここですが.. =ここですか？

0..^5

..=非常によく似ていますが、べき乗演算子のように見えるという点で追加の欠点があります。

inclusive(0..5)

長所：意味的に非常に明確です。 タイプミスはありません。

短所：ちょっと長いです。 また、パターンマッチング構文と矛盾しています。

0....5

長所： ...のタイプミスの問題も回避します

短所：セマンティクスが不十分で、パターンマッチング構文と矛盾し、パターンマッチング構文に似ています。

[0..5]使用できません。 括弧は、言語においてすでに構文上の重要性を持っています。

0..<=5使用できません。 値を範囲と比較するための既存の構文と競合します。

「パターンマッチング構文と矛盾する」という欠点を持つリストされたすべてのオプションは、パターンマッチング構文を変更した場合に改善される可能性がありますが、そのルートには下位互換性の問題があります。 または、下位互換性を損なうことを避けるために、パターンマッチング内で...と（ここで構文を選択）を同等にすることもできますが、パターンマッチング以外での...の使用を防ぎます。 おそらく、スタイルガイドを更新して、そのルートをたどる場合にパターンマッチングで...を使用しないようにすることもできます。

上限と下限の両方を包括的または排他的にすることができる、より汎用的な範囲構文を作成することについてもいくつかの議論がありましたが、半分開いた範囲と閉じた範囲がカバーする可能性があるため、おそらくその構文は必要ありませんユースケースの99.9999％。

私はこの議論をできる限り表現しようとしました。 私があなたの主張を適切に表現しなかったと感じたら、私に知らせてください。私はこれを更新することができます。

@Xaeroxeすばらしい要約をありがとう。

おそらく、それが決定されたときに、新しい構文（たとえば、 ..= ）にパターンマッチングで...を使用することからソースを自動変換するツール（おそらくrustfmtのプラグイン）を持つことが可能です。
そうすれば、「古い方法で書かれたすべてのコード」にとらわれることはありません。
ただし、プロジェクトの作成者の意図を持って呼び出す必要があり、すべての錆びた媒体に通知/見出しを付けて、全員が変更を認識できるようにする必要があります。
これらのことで、パターンマッチングの...構文を新しい構文に変更することは問題ないと思います。

@clarcharrが提案したように、構文の問題を回避するためにできることの1つは、

inclusive関数を追加することもできます（ std::rangeだけに、または場合によってはプレリュードにも）。 これは、いつかファーストクラスの構文を持つことを排除するものではありませんが、今すぐRangeInclusiveを構築する方がはるかに便利です。

ただし、これらはすべてlibsの決定のように見えるため、langチームがこれらのアイテムを安定化/追加することを決定する管轄権を持っているかどうかはわかりません😅。

私は個人的に変換することを好むだろうRangeInclusive持っていない何かに自分自身をEmpty行い、その後、バリアントをIntoIterバリアントを持っています。 Empty { at }を手動で使用せずに空の範囲を作成することは本質的に不可能であることを考えると、私にはもっと理にかなっています。

または、前述のワンエッジケースでMAXとMINを交換します。 そのため、 RangeInclusiveを含むより一般的なコードを書くのは難しくなりますが、問題に対する合理的な解決策のようです。

何が起こっても、構文の問題に関係なく存在する標準ライブラリの型を安定させることを大いにサポートしています。 これにより、ライブラリは、包括的範囲でのスライスを可能にする安定したコードを記述できるため、構文が安定するまでに、人々は型を使用するコードをすでに実装しています。 構文とタイプは、理由により異なる機能フラグの下にあります。

@scottmcmこの時点では、おそらく別のスレッドである必要があることに同意します。

構文の議論を前進させ続けるために、私は私が取りたいルートを提供するつもりです。

私は..=構文が最も好きなので、この構文糖衣をパターンマッチングでは...と等しく、パターンマッチング以外ではInclusiveRangeとして追加する必要があると思います。 次に、言語の一貫性を維持するために、アナウンスと自動ツールを使用して、ユーザーとそのコードをパターンの..=構文に移行してみてください。 ...から十分な数のユーザーを移行したと感じたら、コンパイラー警告を使用し、最終的に（おそらく今から数年後）コンパイラーエラーを使用することができます。

私の提案が出されてから24日が経ちましたが、コメントはありません。 その計画を進めるべきでしょうか？

編集：モバイルでは親指が下がっていないので、反対意見があることに気づきませんでした。

@Xaeroxeそうは思いません。 私は卑下することを同意しない...の賛成で..= 、私はすでにこのスレッドに投稿している理由のために良い選択です。 同じアイデアがすでに提案され、議論されていたので、私はあなたの特定の提案に答えませんでした。 ここで明らかなのは、コンセンサスがないことだけです。 私たちの多くは議論に疲れを感じていると思います。

編集：より具体的には、 ...を非推奨にして、 ..=を優先したくありません。理由は次のとおりです。

• 構文の廃止は、チャーンの莫大なコストです。 ..=が一義的に気に入ったとしても、stableで包括的範囲式を取得するだけでは非推奨サイクルの価値はないと思います。
• 私は..=好きではありません、それは自明ではなく、不明瞭だと思います。 これには、1つのエラーが発生する可能性が低いという利点がありますが、ユーザーが初めてそれを見ると、自分が何を見ているのかがわかるわけではありません。
• ここでは、パターンと式の間に対称性が必要であるという前提に同意しません。これらは、類似した構造化/破壊化操作を行わないためです。

（私はこのコメントの間に少し意見を変えました、私は他の人が私の思考プロセスと私がした結論に達した理由を見ることができるようにそれをすべて残すことにしました）

そのようなことについての経験が不足しているため、非推奨のコストについてはコメントできません。 しかし、私はまだ..=をサポートしています。

ある時点で、ユーザーに何かを学んでもらうことをいとわないようにする必要があると思います。 プログラミングは全体として学ぶべきものであり、一般に特殊な構文は常にセマンティクスにいくらかのコストがかかります。 私は人々が一見構文を認識することを期待していません、 ..はこの点で同じように悪いです。

ただし、特殊な構文が多すぎると、Rustが望んでいる言語よりもbrainfuckに近い言語になる可能性があります。 したがって、特別な構文に変換することを選択したケースは、実際にはそれだけの価値があるほど一般的であることに注意する必要があります。 正直に言うと、これを入力したので、このケースがその価値があるかどうかは完全にはわかりません。 包括的範囲の必要性は、構文を保証するほど高くはありません。

しかし、矛盾はまだ私を悩ませています。 包括的関数とパターンマッチングの...を持つことは、英語で灰色と灰色の両方を持っているような感じです。 私たちの一部が私たちがすべきだと感じていることを標準化する機会があるとき。 ただし、その変更を行う際には、実際のロジスティック上の問題もあります。 Rust 2.0を設計する場合（それは非常識かもしれませんが、私にはわかりません）、これを再検討する必要があるかもしれませんが、今のところ、グレーとグレーの両方で十分だと思います。

現時点では、パターンマッチング以外のインスタンスにinclusive関数を使用し、パターンマッチングに...を使用することをサポートしています。

@withoutboats

1. 何も非難しないと、C ++のようなすべての（多かれ少なかれ）悪い決定の結合になってしまいます。 これは、物事が可能な限り一貫していないため、初心者にさらに多くを学ぶことを余儀なくさせます。
   したがって、より良いソリューションに道を譲るために非推奨にすることが理にかなっている場合があります。

2. これは、ユーザーが初めてそれを見るときに、自分が何を見ているのかを知っているという意味ではありません。

これは、どの構文に..= 、 ...またはその他の構文を包括的範囲に使用しても変更されません。たとえば、他の言語は排他的範囲に...を使用するため、とにかく検索する必要があります。 。
明らかな外観の機能のみを導入することが私たちの目標ではありません。
見た目がわかりやすい機能だけを使用したい場合、Rustの既存の機能のほとんどを使用することはできません。 ドキュメントを見ている初心者とにかく、何がそれについてとても悪いですの？ ドキュメントは良いです！

1. 
   初心者がドキュメントを見る時間を最小限に抑えることに関心がある場合は、構築と包括的範囲の一致の対称性を追求する必要があります。 （およびその他の構成）

@withoutboatsが言ったように、私たちの多くはこの議論にうんざりしていると思います。 私はしばらくの間それを座っていました。 そうは言っても、私は時間をかけて読み直し（@Xaeroxeの要約に感謝します！）、ここで私の考えを再検討しました。

IMO、最も重要な問題は、今私たちが提供する構文の不完全な組み合わせは次です。 ...パターンで、 ..式の。 この構文のペアは、 ..がパターンで機能し、 ...が式で機能することを強く期待しますが、機能しません。 これは長期的には持続可能な設計ではないと思いますので、本当に修正したいと思います。

また、両方の種類の範囲の構文を提供したことを考えると、おそらくそれを継続するのが最善だと思います。 それは私たちにいくつかのオプションを残します：

• 式の...を安定させ、パターンに..を追加します。 これは最も苦痛の少ない変更ですが、オフバイワンエラーに関するよく議論された欠点があります。 それでも、他の言語にはこの組み合わせがあり、私の知る限り、そのようなエラーでひどく苦しむことはありません。

• パターンと式で...を廃止し、両方に..=を追加し、パターンに..を追加します。 上記の欠点を解決し、（非推奨のために）より苦痛になり、将来的には他の種類の範囲（左限定など）への扉を開きます。

この時点で、私は主に議論を再ハッシュしています。正直なところ、この時点でこれ以上言うことはないと思います。 私たちはトレードオフを明らかにしたと思います。評価を行って決定を下すには、langチームが必要です。 しかし、私のコメントの主な目的は、ここでinclusive追加するだけでは不十分な理由、IMO）についての最初のポイントです。

それでも、他の言語にはこの組み合わせがあり、私の知る限り、そのようなエラーでひどく苦しむことはありません。

ここで選択バイアスが気になります。 問題が軽微なものなのか、それともめったに気付かないのかを判断する信頼できる方法はありません。

また、 ...を使用すると、Rustの設計哲学と新たなベストプラクティスの「トレードオフが厳しすぎない限り、フットガンを避ける」という側面に反するように感じます。 （たとえば、 boolを使用するのではなく、新しいenumタイプを作成することをお勧めします。これにより、関数パラメーターを混同しにくくなります。）

たとえば、Cは、言語にwhile letがない場合、 ifステートメントでの割り当てが役立つことを証明しましたが、 ==を意味するときに=と入力すること==は十分なフットガンであり、Pythonのような言語は、唯一の選択肢が特徴的に醜い状況が存在する場合でも、それを拒否します。

逆に言えば、1週間ほど前にコーディングに疲れていたときに、実際にClippyにこのようなケースをキャッチさせました...

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

...ここで心配している「キーを何度も押した」という間違いの完璧な例のようです...そして「 ==は効果がない」とは異なり、 ..対...リントする良い方法はありません。

@ssokolow明確にするために、私も..=大丈夫です。 非推奨はそれほど苦痛ではないと思います。これは非常に簡単な自動修正です。 ほとんどの場合、この問題を解決したいだけです。

私はおそらく.. / ...を安定させて生きることができます（これはすでに毎晩実装されています）。 私は@aturonに同意します。存在する言語は、これが機能することを示唆しています。

私が言ったように、私はrust-lang / rfcs＃1980が通過するときに、構文の議論を必要とせずにlibstd型を安定させたいと思っています。

@aturonが指摘したことに

私はlangチームの議論に再指名します。 この時点で、大幅に新しいアイデアやトレードオフが発生する可能性は非常に低いと思います。 提示されたトレードオフについて決定を下す必要があります。

2017年5月18日午前9：55：30PDT、アーロンテューロン[email protected]は次のように書いています。

私はlangチームの議論に再指名します。 ありそうもないと思います
これにより、大幅に新しいアイデアやトレードオフが発生します。
点。 これまでのトレードオフについて決定を下す必要があります
レイアウト。

会議のため、来週の会議に出かける予定です。 これが来週の会議で議論される場合... 、 ..= 、 inclusive 、 ...以外のソリューションに対するサポートを表明します。

そこにいる間、rest / spread構文について議論する価値があります。
私は..を排他的範囲に、 ...を包括的に、 ....を残り/拡散に投票します。

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

次の2つの理由から、残りのスライスに...を投票します。

1. 人々は、CoffeeScript（CoffeeScriptはvarargsの関数署名でrest...を使用し、それらを「スプラット」と呼びます）や英語（正しいUnicodeを使用）などの言語からの「休息」を意味する...にすでに精通している可能性がありますコードポイントであろうとなかろうと、それは4つではなく、省略記号のように見える3つの期間であり、人々は、純粋にそれに遭遇することから、英語で「もっとありますが、私たちはそれを大声で言っていません」を意味するように省略記号を理解するというまともな仕事をします使用中で。）

2. Rustの構文について何かが足りない場合を除いて、範囲に..と..=を使用しますが、残りのスライスに...を使用すると、すべての状況で...と入力することになります。 ..を意味する場合、またはその逆の場合でも、コンパイル時エラーになります。

   このために、私は2つの仮定に基づいて操作しています。

   1. （シーケンスアンパックコンテキストの外で）REST構文のみを使用することは、タイプミスが発生しやすいno-opとして許可されません。 （つまり、許可されている場合、 for _ in ...restはfor _ in restと同じになりますが、ほぼ間違いなくタイプミスです。

   2. 割り当てられるパターンとして自由形式の範囲を使用することは無効になります。 （つまり、 let [first, ..rest] =は無効になります。）

@ssokolowトリプルドットはすでにパターンの範囲を意味しているため、残りの構文に変更するための

@phauxポイント。 どういうわけか忘れてしまいました。

おそらく、「もし私たちがRust2.0を作ったら」というタグをぶら下げるための何か。

トリプルドットはすでにパターンの範囲を意味しているので、それを残りの構文に変更するための重大な変更になります。

ただし、パターンの...は、両側に式が必要です（ a...b ）が、残りの構文ではプレフィックスとして...を使用します。

langチームは、今日の会議でこの機能について再度話し合い、おおよそ次のマトリックスに到達しました。

• パターンで...をサポートし、式で..をサポートするだけで、他には何もできません。 これにより、ユーザーは構文が機能しないことを期待するようになります。

• 両方の場所で...と..を許可することは役に立ちますが、オフバイワンの問題は本当の懸念事項です。 私たちの誰もが、誤った期間を追跡するのに何時間も費やしている人々の報告を受け取りたがっていません。

• ..=と..移動すると、見た目はあまり魅力的ではありませんが、上記の非常に現実的な問題を回避できます。 非常に穏やかな方法で展開することもできます。最初に代替構文として..=を導入し（rustfmtはこれに書き換えることができます）、慣用的になった後でのみ...廃止します。

わからない場合は、チームは..=と..が最善の道だと感じています。 この問題は、新しい議論が提起される可能性が非常に低いという点でも議論されているので、思い切って準備ができています。両方に..=表記を実装したい人を探していますパターンと表現、そして続いてFCPに行きます！

そのために、実装を推進してくれる人（または何人かの人）を探しています。 おそらく、これはいくつかの小さなPRで行うことができます。

• まず、 ..=を...エイリアスとしてパーサーに追加し、既存のテストを変換してみましょう。
  
  
  
  • もちろん、 ...は機能し続けるはずです。これを「サイレント」な非推奨にしたいので、警告などを発行する必要はありません（まだ）。
  
  
  • したがって、 ...パターンでテストを続ける必要があります
  
  
  • おそらくこれを行う方法は、 DotDotEqualsトークン（これは既存のDotDotDot ）を追加してレクサーを変更しパーサーを変更しDotDotEqualsを受け入れることだと思います。 DotDotDot受け入れるようになりました（例）
  
  
  • ripgrep DotDotDotはここのあなたの友達です;）
  
  
• ...は決して安定していなかったので、それを..=して、古いサポートを削除することができます
  
  
  
  • 野生の人々に親切にするために、私たちは非推奨の期間を経ることができましたが、それが必要かどうかはわかりません（考え？）
  
  

実装時に、構文extern fn foo(a: u32, ...)を..=変更しないでください😆

コードへの良い最初のステップのように見えるので、それを取りたくなりましたが、次の2週間はあまり時間がないので、誰かがそれを手に入れたい場合は、お気軽に！

私は賛成で個人的にもっとよ..^より..=として、 a operator= b 、いくつかの演算子のために、すでにの別名であるa = a operator b 。 ^は、XORに対してのみ使用されることがはるかに少ないため、混乱が少なくなるはずです。

..は、その左右のオペランドのタイプとは異なるタイプを生成するため、 ..=問題であるとは思われません。 コンテキストは、演算子の目的を識別するのにも役立ちます。たとえば、 +=は()返すため、通常は独自の行に独自のステートメントとして表示できます。 ..=はInclusiveRangeを返すため、他の命令内の式として表示されます。 さらに、前述のように、 ..^は、範囲よりもべき乗に関係しているように見えます。

@Xaeroxe ^は、べき乗とRustとは関係ありませんが（他の言語ではそのまま使用されます）、 += 、 -= 、 *=すべてRustに存在します。 実際、 ^=存在します。

しかし、idk、 ..=もあるのは問題ありません。

＃42134がマージされたので、ライブラリ構造体を安定させるために移動できますか？ 構文が安定するのを待ってから安定させたいと思いますが、前に述べたように、構造体をより早く安定させると便利です。

@clarcharrその構造と..=構文を安定させるという決定に至ったと思うので、実際にそれを行うにはいくつかのPRが必要です。

編集：うわー私は間違っていた。 コンパイラに実装しているので、構文を安定させるには、最終コメント期間が経過するのを待つ必要があります。 現時点では構造を安定させる必要があると思いますが、それも私の決断ではありません。

...がコンセンサスを作っているように思えたとき、私はずっと前に主題に従うのをやめました。 ..=は一見愛情のように見えるので、私にはぎこちなく見えます。

しかし、もっと重要なのは、このバイクシェディングが現在のパターン構文を変更するほど重要ではないと思うことです。

この構文は最悪です！
= + =、-=、* =モデルでも、割り当ての意味がありますが、.. =は何かを取得することです。 とても混乱して醜い。
配列インデックスが0から始まるように、「...」は美しくて美しく、人々はそれに慣れるでしょう。

@zengsai
..=は、概念的には==や<=などの演算子から派生します。これらの演算子は、Rustにすでに存在し、代入ではなく等価比較を示します。

（つまり、 1..=5は "Range over values 1 <= x <= 5 "の省略形であり、 1..5は "Range over values 1 <= x < 5 "を意味します）

編集：また、それは「それに慣れる」ことの問題ではありません、それはあなたが疲れているか気が散っているときに読み間違えたりタイプを間違えたりするのがより難しい問題です。 そのようなオフバイワンエラーは、有名なフットガンです。

すでに..を意味しているのに、実際に誤って...入力してしまいました。 ありがたいことに、私は常に安定したRustをターゲットにしているので、コンパイラーがそれをキャッチしました。 （しかし、私はノンフィクションの執筆をたくさんしているので、疑似省略記号を入力したいと思ったので、それが筋肉のけいれんなのか筋肉の記憶なのか思い出せません。）

@zengsai ...は微妙すぎて、 ..に似すぎています

言語が異なることを意味する異なる数のドットを持つことは本当に異常です

フットガンを取り外すことは、審美的に魅力的であるよりも重要です。

新規参入者：これは非常に長いスレッドであるため、TL; DRを作成しました。 ここで読むことができます： https ：

「そのようなオフバイワンエラーは有名なフットガンです」と言えば、私は言わなければなりません。タイプミスの問題は、この変更の主な理由として使用されるべきではありません。

この比較、「..」と「...」と「=」と「==」を見てください。これは、ユーザーのタイプミスの問題を回避するために、「==」の他の構文を見つける必要があることを意味しますか？ 「=」と「==」で問題ない場合、なぜ「..」と「...」ができないのですか？

私は2年以上rust-langをフォローしています。 antそれは私のプライベートプロジェクトの多くで使用されました。 私はそれが大好きですが、この構文は本当に私を不快に感じさせます。 見た目に美しいだけでなく、コードの読み書きの流暢さにも影響します。

@zengsaiは、主にコードを_書く_ときではなく、コードを確認、読み取り、理解するときのことだと理解していました。 ..を探していない場合は、 ...は1つずつエラーになりますが、 ..=間違いなく目立ち、勝ちますこの問題はありません。

美的観点からも..=構文が好きかどうかはわかりませんが、 ..と...どちらから来ているのかは非常によく似ています。

@zengsai = vs. ==は、 .. vs. ...では利用できないソリューションがあるためです。

もちろん、C言語では=と==を混同する可能性があります...しかし、これは認識されているフットガンであり、PythonやRustなどのより現代的な言語は次のことを解決しました。

1. 入力した場合はエラーですif x = yではなくif x == y （これは錆やPythonが作った修正です）
2. 私が誤って入力した場合はx == y;ではなくx = y; 、私は効果がありません表現についての警告を受けました。

..と...混同が怪しいことは

@zengsai ..と...は、すべて同じ特性を実装し、本質的に交換可能に使用できる型に評価されます（これは仕様によるものです）。 1つのエラーによるオフは非常に現実的な問題です。

私もこの構文が嫌いなことを明確にしておきたいので、 @ aturonのコメントに同意しません。現在の状況では、 ..と式および...しています。パターンは「受け入れられない」です。 実際、この構文を使用するよりも、切断する方が望ましいと思います。

しかし、これについてはコンセンサスが得られないこと、このスレッドで新しい議論がないこと、積極的に投資しているユーザーの大多数（および言語チームの残りの部分）がこの変更を支持していることは明らかです。 だから私は脇に立っているので、問題を解決することができます。

私の経験では、ほとんどのユースケースでこの機能が実際に必要になることはないので、コード全体に表示されることはありません。

実際、私はまだパターンで...を廃止することに本当に不満を持っており、基本的にはこの問題を解決できるように歯を食いしばるつもりです。 langチーム全体が、 ..と...両方の式を使用することはひどい疣贅であり、一部のユーザーは完全にサイレントなタイプミスの問題のデバッグに何時間も費やすことに同意します。

残りのlangチームは、表現とパターンの間に断絶があることは容認できないと強く感じています。私は同意しませんが、私たちは皆、議論をしました。永遠に膠着状態にあることは健康的ではないと思います。

@ssokolow申し訳ありませんが、私はまだあなたに同意することはできません。 コンパイラはこの種のタイプミスを警告することができますが、「x = 6」であるはずの場所に「x = 5」と入力するとどうなりますか？

コンパイラはタイプミスを避けるのに最適なものではありません、プログラマーはそうです。

この変更に副作用がなければ、私は完全に同意します。 しかし、これにより、言語の美的感覚、読み書きの流暢さが失われます。これは、私の個人的な意見では価値がありません。

今日のさびはすでに読み書きの問題に直面しています。より一般的で直感に反する構文であるほど、学習曲線が大きくなり、別のPerlにしないでください。

@withoutboats私たちはそれについて議論します、

@zengsai

確かにトレードオフがありますが、それらの間の最良のバランスポイントについては決して合意できないという印象を受けます。

個人的な好みに関係なく、私は..=を、バグを追跡するために非常に多くの時間を浪費する可能性があることを回避するために支払う小さな価格だと考えています。

（私の焦点はUI / UXデザインであり、彼らが教えてくれる最大のルールの1つは、間違いを犯しやすくすることは、それが引き起こす害や修正までの時間に反比例することを目指すべきだということです。 ）。

私の小さな意見では、 5対6は、 ..対...よりもはるかにわかりやすくなっています。

@zengsaiこの会話のためだけにたくさんのメールを受け取っていますが、あなたの気持ちをよりよく表現するために錆びたIRCチャンネルに移動してみませんか？

@daiheitanこれは通常の通信です。気に入らない場合は、このメールの

Rustを最初に見たとき、 ..構文に本当に驚いていました。 (1..10).sum()は... 1から9までの整数の合計ですか？ この構文を新参者に提示して、それが何を意味するのかを尋ねると、彼はそれが1から10になることを期待する可能性が非常に高くなります。対称構文が対称を表現することを期待するので、彼はそうするのが正しいでしょう。範囲。 なぜ1を含める必要がありますが、10を含める必要はありませんか？

対称範囲に別の非対称形式..=を追加すると、これはさらに視覚的に一貫性がなくなります。 左側が包括的であるために=を必要としない理由を疑問に思うかもしれません。したがって、両側の包括的範囲の場合は=..=になります。

ような何かスウィフトの構文（ ..<排他的のための...込み用）これらの問題を回避し、読みやすさを向上させるであろう。 言語にまったく慣れていない場合でも、意味を正しく推測するのは簡単なので、覚えておくべきことが1つ少なくなります。 特にRustの新参者への配慮を考えると、このようなものが選ばれることを期待していました。

@rkarpある程度、それはおそらく既存のバイアスによるものです。

たとえば、Rustには多くのPythonの影響があり、Pythonは同じ種類のハーフオープン範囲を使用します。 （つまり、Pythonのrange(1, 5)またはmyList[1:5]どちらもRustの1..5と同じ動作をします）

Pythonでのその正当性は、構文が1つしかないことに関係しており、構文が半分開いているため、 head, tail = myList[:pivot], mylist[pivot:]ようなことが簡単になりました。

とはいえ、Rustが1.0を通過したことを考えると、既存のコードを壊さないことについてはかなり厳格なルールがあります。 ..排他的なパターンの外側とのための...排他的な内部のパターンのためには有効なままにする必要があります。

..=は、どこでも.. （排他的）と..= （包括的）を受け入れ、 ...を..非推奨の同義語として扱うことができるため機能しますパターンで。

..=をトークンとして持つことは、マクロの:ttルールに影響を与えるため、技術的に互換性のない変更です。 おそらく問題はないでしょうが、静かな変化である可能性があることを考慮して、誰かがそれを行わないかどうかを確認することをお勧めします。 （別の方法は.. /* why not */ =許可することですが、これは良い考えではないと思います）

@ssokolow技術的には、解析エラーではなく、Rustのタイプエラーです。 a = 2は()を返す式であり、 ifはbool予期しているため、明らかに互換性がありません。

ルールはゆっくりと変化しています。 技術的には、 ..=は3つのトークンであり、最初の2つにはスペースがありません。

@eddyb ：

このコードは現在、「ルール2」と「ルール4」を報告しています。 この変更は、正しく理解すれば「ルール2」と「ルール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!(..=);
}

いいえ、トークンの定義方法の変更です。 @jseyfriedは、結果をより適切に説明できます。

技術的には、これはRustのタイプエラーであり、解析エラーではありません。 a = 2は（）を返す式であり、boolを期待する場合は、明らかに互換性がありません。

@xfixありがとう。 前回そのタイプミスをしたときは、適切な注意を払っていませんでしたし、式指向言語の観点から考えることにまだ完全には慣れていません。

コメントを調整しました。

私は..=構文が好きではなく、パターンで...を非推奨にすることに反対しています。 タイプミスが心配な場合は、省略形として...や..=ではなく、常に構造体RangeInclusive { start, end }使用できます。

私が気付いた潜在的なあいまいさ：

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

@clarcharrコンパイルされていないようです。

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
..=を1つの演算子として導入すると、エラーは次のようになります。

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

error: aborting due to previous error

今と同じようにlet x=10; if let 5..x {}

したがって、この「あいまいさ」はコンパイルされず、したがってif let 5..x {}以上のあいまいさにはなりません。

@Boscop要点は、現在、 5..をSome(5)ようなパターンとして扱う場合、 if let 5.. = xはlet Some(5) = xに似ており、後者はコンパイルされます。 私のコメントが示すその5..パターンではないので、互換性の危険がありませんからif let導入するために..= 。

この機能を導入し、パターンで..=と..両方を許可する場合、 if let 5..=xは常にif let 5.. = xあり、コンパイルする必要があります： if let (single expression)は意味をなさないので、あいまいさはないと思います。

@kennytmなので、2つの異なるあいまいさについて、コンパイルされないことを示しました。 （彼がどちらを意味するのかは明確ではありませんでした。ちょっとあいまいでしたね。）

@daboross kennytmが言ったように、 5..はパターンではなく、現在でもコンパイルされません。 そして、演算子として..=を追加しても、これは変わりません。 あいまいさはありません。 重要なのは、 ..=を1つの演算子として解析できないようになったことですが、1つの演算子として解析できれば、あいまいさはありません。

5..は現在有効なパターンではなく、ハーフクローズドインターバルパターンもありません。 とはいえ、ハーフクローズ間隔パターンの欠如は、範囲式と比較した場合に不整合の原因と見なされることが多く、パターンにも実装される可能性があります。 また、完全な整数一致など、後でパターンの間隔の片側を省略する機能を追加することもできます。

したがって、@ clarcharrの観察は、現在の文法を考慮した場合に必ずしもあいまいさを指摘しているわけではありませんが、パターンに..=を使用するという提案と矛盾する可能性のある将来の拡張を考慮する場合は確かにあいまいです。

そのことを念頭に置いて、ここで他の記号を使用することをお勧めします。 ^は、現在IIRCの式コンテキストでのみ使用されているため、私にはかなり問題ないようです。

（これは、構造体を安定させるために移動し、後で構文を安定させることをお勧めするもう1つの理由です。）

@nagisa RangeFromパターンがサポートされる前にトークン..=が追加された場合、 if letに関する競合はありません。 x <- y （配置）とx < -y （+負未満）のように、 ..と=間にスペースを追加して曖昧さを解消することができます。

（ ^は排他的論理和演算子なので、包括的範囲に..^を使用するの

私が書いた何千もの範囲の中で、それらのかなりの数が完全に閉じており、おそらく1つか2つでも間違った方法で半分開いていますが、追加の構文の必要性はまだわかりません。 1..(n+1)を書くのはそれほど難しいことではありません。

これは、end = T :: max_value（）では機能しません。

2017年5月29日16:33、「DiggoryHardy」 [email protected]は次のように書いています。

私が書いた何千もの範囲の中で、それらのかなりの数が完全に閉じています、
たぶん1つか2つでも間違った方法で半分開いて、私はまだ本当にしません
追加の構文の必要性を参照してください。 1 ..（n + 1）を書くのはそれほど難しいことではありません。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
。

私は.. =よりも半分閉じた範囲での方法を好みます。

2017年5月29日16:35、「SimonasKazlauskas」 [email protected]は次のように書いています。

これは、end = T :: max_value（）では機能しません。

2017年5月29日16:33、「DiggoryHardy」 [email protected]は次のように書いています。

私が書いた何千もの範囲の中で、それらのかなりの数が完全に
閉じた、多分1つか2つの半分開いた間違った方法で、私はまだしません
追加の構文の必要性を実際に確認してください。 1 ..（n + 1）はそれほど難しくありません
書きます。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
。

特性と型を構築する方法ですでに安定させたいと思っています。それについては意見の相違はないと確信しているからです。 構文上のバイクシェディングがコア機能自体の安定化を妨げないようにしてください。

これは、end = T :: max_value（）では機能しません。

本当に2 ^ 64以上の値、あるいは2 ^ 8の値を繰り返したいですか？ u32などの最後のいくつかの値のみを繰り返し処理する場合は、ループ内に1つ追加する方が簡単な場合がよくあります。 また、なんらかの理由で2^B-1を繰り返し処理したい場合は、ループの最後でいつでもif i == END { break; }を使用できます。

標準の符号なし整数が2 ^ 32または2 ^ 64の値をサポートしているからといって、表現可能な最高の値が頻繁に使用されるわけではありません。 また、 u8で何かをしている場合は、とにかくCPUがu32をカウンターに使用する方がおそらく簡単であることを忘れないでください。

しかし、クローズドレンジジェネレーター構文の必要性がないとしても、チームの変更に対する議論に反論することはできません。 しかたがない ：/

これらの4つをすべての包括的オプションに含めるのはどうですか？

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

幼稚園以降、不平等の演算子がみんなの心に打ち込まれていることを考えると、それ以上の説明なしに、それらが何を意味するのかを理解できるはずです...しかし、これらが他の方法で苦痛になるかどうかはわかりません。

または、不等式を切り替えることもできます。

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

...最後のものが怒っているカートマンのように見えないようにするためです。

@vegaiと、確かに削除されない既存のa..b構文についてはどうでしょうか。 いいえ、新しい構文オプションを提案しても何も解決されないと思います。

うーん、2つの「潜在的なあいまいさ」が発生しました。

• if let 5..= x -すでに述べたように、これは..=をトークンと見なすと、将来5..パターンを追加してもあいまいではありません。 ..と=間にスペースを入れる必要があります（例： let 5.. = x ）。
• マクロルールに関するあいまいさ。 これは確かに苦痛で不幸なことであり、「マクロ2.0」の別のシステムに移行している理由の1つです。このシステムでは、「複合トークン」のセットをエンドユーザーに公開することを避けています。
  
  
  
  • 最終的には、必要に応じて、特別な場合のコードを介してmacro_rules!バックコンパットを処理できます。 いずれにせよ、 ...を使わない限り、この種の問題を回避することはできないと思います。
  
  

包括的範囲を安定させる前に、問題＃42401も修正する必要があります。安定化後の修正は重大な変更になるためです。

@ est31良い点、私はそれを

チェックされたstrslicing自体は不安定であり、その問題を修正しても包括的範囲はまったくブロックされません。

ああ、 @ nagisaは正しいです、それは範囲構文とは何の関係もありません。 もう一度頭から外してもらえますか？ 私の間違い。 バグはむしろgetの実装にあり、したがって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
            }
        }
    [...]

削除されました

別のチェックボックスの更新：PR https://github.com/rust-lang/rust/pull/42134は、 https：//github.com/rust-lang/rfcs/pull/1980の調整を適用しました

バンプ：少なくとも1.20で構造体を安定させる方法はありますか？

包括的範囲構文のために、C ++から有名なgo-to演算子を借りるのはどうですか？ 😛

@nikomatsakisと@ rust-lang / libs（これにタグを付ける方法はわかりません）、構造体を別の追跡問題に移動するPRを送信した場合、どのように感じますか？そこの？ これは、新しい構文が実装/解決されるのを待つ間、それらをより早く安定させるために前進するための良い方法だと思います。

cc @ rust-lang / libs（チーム内の人だけが自分のチームまたは他のチームにタグを付けることができます）

ありがとう、@ eddyb！

@clarcharr https://github.com/rust-lang/rust/pull/42275#discussion_r119211211に基づいて、いただければ幸いです。

構文提案の電車には遅すぎますか？
誰かがスライスに値を割り当てようとしているように、現在のように見えます。

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]

この構文では、将来、範囲にAdd実装を追加できなくなります。 Add実装が何をするのかよくわからないので、それが問題かどうかはわかりません。

トレーリングプラスに同意します。 プレフィックスに変更されました。

a.. 、 ..bおよび..はRustで有効な構成であるため、これでも数学演算であいまいさが生じます：/

a... / a..= / a..+は有効ではありませんが、正しいですか？ 制限のない範囲を持つことはエンドポイントを含むので、実際には意味がありません。

Addについて(x..+y) + z実行できます。 ？

編集：気にしないで、あなたが何を意味するのかを理解しただけです。 あいまいになるのはa..+bでしょう？ 今のところ、それはa.. + b意味します。

@daborossこれが良いアイデアまたは悪いアイデアだと言っているわけではありませんが、この実装（またはそのバリエーション）は、将来の範囲に必要なものになる可能性があります。

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)..
    }
}

この特定の実装は良いアイデアかもしれませんし、そうでないかもしれませんが、将来のユースケースとして考え出すのにそれほど時間はかかりませんでした。 既存の構文の決定により、このようなものが追加される可能性を排除するのは悪い考えだと思います。

私の他の懸念は、 ...を却下することの全体的なポイントは、タイプミスを認識しにくい可能性を最小限に抑え、括弧が抽象的なa..+b 2つの異なる意味の違いを生むことを可能にすることです。その方向に戻ります。

さらに、現在の..と提案されている間、「完全性のためにいいのではないか」を超えて、 a-..bとa-..+b確固たる正当化をまだ見ていません。 ..=両方とも、既知の有効な論理的根拠を持っています。

式の構文があいまいになるため、これに+を使用することはできません。

編集：ただし、 <Range as Add<{integral}>>::Output = InclusiveRange実装になってしまうため、ライブラリに包括的範囲を完全に実装できるようになると思います。

..!バリアントを提案するかもしれません。 ..生産的な韻を踏んでおり、最後のドットをさらに強調して目立たせています。

もちろん、演算子!と衝突しますが、正直言って、バインドされた部分式に!を入れる必要がある状況を想像することはできません

..!は直感性に問題があります。 構文にまだ精通していない初心者は、 ..!を「最大であるが...ではない」という意味であると簡単に誤解する可能性があります。

また、「...のビット単位の補数までの範囲」の構文とも衝突します（これにより、 +を使用するのと同様の状況になります）

同意。 しかし一方で、 ..=は代入演算子の1つとしても誤解される可能性があります。

これが代入演算子だったら、何に代入しますか？

@ 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

他の組み合わせが必要かどうかは疑問です。 いずれの場合も、後で追加できます。

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

最後のオプションは少し奇妙に見えますが。 ^_^

単項演算子を含む構文の提案をやめてください。つまり、 a..-b 、 a..!b 、 a..*b 、 a..&bまたはa?..b 。受け入れられました。

..！ 直感性に問題があります。 構文にまだ精通していない初心者は、簡単に誤解する可能性があります..！ 「までですが、そうではありません...」を意味します

..=は、直感性に関して同じ問題があります。 =を見た人は誰でも、愛情や比較を期待しています。 ..=を見るたびに、この等号がここで何をしているのか疑問に思うのを防ぐことができないので、この構文が完全に識別可能性の問題を解決することを確認します。

非常に直感的で現在の構文と一致する唯一の提案された構文は...です。 しかし、船は出航したようです。

とにかく、初心者はドキュメントを頻繁に見る必要があります。 ...でも、ドキュメントを確認します。 これは避けられません。 ただし、 ..=には優れたニーモニック（ up toとequal to ）があるため、この演算子のドキュメントを頻繁に調べる必要はありません。

...演算子がそのままで、代わりに..演算子を..⎵ 、つまり2つのドットとスペースに変更するとどうなりますか（ '⎵ '通常のスペースがこのWebページに表示されないため、そこに文字があります）。 それは、空白が重要な言語の1つの場所になります。 a..bようなすべてのコードは、 ..のような演算子がないと文句を言い、ドットの後に少なくとも1つのスペースを追加するようにアドバイスするため、これも重大な変更になります。 私はスペースがそれらを視覚的に十分に区別できると思います：

a.. b
a...b

@tommit正直に言うとそれは良い考えではないと思います。

演算子は現在、空白に関して非常に柔軟です。たとえば、 a..bとa .. bは同じです。 これはおそらく、 a+bやa + bなどの他の演算子との一貫性を保つためです。 もちろん、これらは同じことを行い、人々が異なる構文スタイルを使用できるようにします。 あなたが私に尋ねればそれは良いことです！

さらに、 ..=表記は、 <=および>=表記（これらも_包括的_と見なされます）と一致しています。

他にどのような可能性があるかを確認することは常に良いことですが、これはおそらく正しい解決策ではありません。

同意。 <=および>=と比較すると、 ..=は論理的でさえ、もっともらしいように見えます。

ちなみに、 ...ファンである場合、または..=外観が気に入らない場合、妥協案は、プログラミング合字でフォントを使用することです。..=用の特別な合字を持つFiraCodeなど..= 、これは...にマッピングされる場合もあれば、⩷、⩦、≔などの奇妙なものにマッピングされる場合もあります。

範囲を使用して既存のすべての錆コードに重大な変更を加えました...到着時にデッド、
ごめん。 誰かが本当に深刻な下位互換性のある提案をしている場合
提起された懸念に対処し、それは議論されていません
すでに聞いてみましょうが、少なくともそれを標準として維持しましょうね。
このスレッドは自転車小屋でいっぱいで、チームはすでに決定を下しました
それはクリアするための高いバーです。

いずれにせよ、実際の構文についてはまだ多くのバイクシェッドが進行しているようです。 コア機能を使用できるように、少なくとも構造体と特性および実装を安定させるために＃43086を提出しました（需要があるようです。上記の@ retep998によるコメントを参照してください）。

部屋の中の象は、 ..が実際には対称的な外観であるが非対称な意味であるため、ここでの本当の問題であるということです。 「正しいこと」はおそらくそれを非推奨にすることを伴うでしょうが、非常に多くのコードがすでにそれを使用しているので、それをする意志はありません。

完全に一貫性のある... （対称的な外観、対称的な意味）を廃止するのは簡単な方法ですが、 ..=さらに別の一貫性のない演算子を追加するという犠牲が伴います。 以前の悪いデザインを回避するために悪いデザインを追加しているようです。

この二重の不整合のために、これには別の問題があります。残りの2つの包括性バリアント（両側で排他的で左側のみで排他的）を追加する良い方法はありません。 ..と..=両方がすでに左側に暗黙の=を持っているので、おそらく<を使用して、それをなんとかして否定する必要があります。 したがって、次のように表示する必要があります。

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

これらが新参者として何を意味するのかを正しく推測して頑張ってください。 したがって、おそらく（当然のことながら）追加されたとは見なされません。

..がそれほど定着していないか、存在すらしていなかった場合、これらすべての一貫した設計をゼロから考え出すことはそれほど難しいことではありません。たとえば、次のようになります。

• .. （または... ）のために[a; b]
• ..<場合は[a; b)
• <.. for (a; b]
• <..<場合は(a; b)

最後の2つのバリアントは、ある時点で役立つ可能性があると感じていますが、実際にそれらへのパスを非常に迅速にブロックする必要がありますか？ いずれにせよ、 ..を廃止するよりも..=を選択する唯一の正当な理由は、はるかに古いコードを壊すことですが、それはせいぜい必要な悪であり、祝うものは何もありません。

_編集：より明確にするために例といくつかのコメントを追加しました。_

..がここでの実際の問題であり、 ...や..=ではないという点で、 @ rkarpに同意します。 非対称の意味は、他の（より人気のある）の言語が実際にそれに左右対称の意味を割り当てる行うことを考慮すると、特に悪いです。 Kotlin、Ruby、Haskellはどちらも、たとえば5を3..5の範囲にあると見なします。 数学の論文もそれを支持しているようです。 ここでの最悪のことは、初心者がRustでの3..5の動作を推測する機会がないことです。4と4だけが範囲3..5（ドットの反復）のメンバーであるか、またはその両方であると判断します。 3と5もその中にあります（「私たちが見ることができるすべて」とドットの外挿を繰り返します）。

しかし、これを変更することの難しさに同意しません。 @adelarsqの提案は、比較的

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

任意の発生x..y （角括弧なしでは）に変換することができる[x..y[およびコンパイラの警告を発します。 いくつかのリリースの後、コンパイラは単に「裸の」範囲表記のコンパイルを拒否し、新しい表記に自動的に変換するツールを提供することさえできます。

https://github.com/rust-lang/rust/issues/28237#issuecomment -274216603これは新しいアイデアではなく、すでに述べた理由により使用できません。

後知恵を利用して言語をゼロから設計する場合は、排他的範囲と包括的範囲の構文を一緒に検討したいと思うという考えに完全に同意します。 ..=は、包括的範囲の理想的な演算子ではないと思います。 これは、現在テーブルにある最良のオプションです。 しかし、現在の排他的範囲演算子を廃止することは非常に苦痛であり、既存のRustユーザーとプロジェクトに不快感を与えます。

うまくいく可能性のある他の多くの提案があります。 たとえば、私は..@提案されているのを見たことがなく、 x..@yは刺激的であるように見えます。 課題は、あいまいさの欠如を維持しながら、現在の提案よりも説得力のあるものを見つけることです。

対称性の私のお気に入りのビューとして、2か月前の@ssokolowのコメントを強調したいと思いました。

• ..4は< 4ものが含まれています
• ..=4は<= 4ものが含まれています

包括的範囲のみが必要だと思います。それはもっと簡単です。
範囲を変更するには、いつでも+1または-1を追加できます。
そして..は..よりも優れています。なぜなら..は...よりも単純だからです！

@ AlexanderChen1989このスレッドの複数の投稿で以前に述べたように、 ..の意味を変更すると既存のコードが破損するため、これは不可能です。

さらに、それは実際にはそれほど単純ではありません。 最も注目すべきは、 +1と-1が整数のオーバーフロー/アンダーフローを引き起こす可能性があることです。）

これはnightlyで

• ...最初に配置したループは、デバッグビルドのオーバーフロー/アンダーフローでパニックになります
• ...リリースビルドで意図されたものとは完全に反対の動作をします（つまり、「0から0」は256回繰り返され、「0から255」はまったく繰り返されません）

#![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人の到着時に死んだ構文の提案がなされました。 新規参入者はスレッドを読んでください。 私たちが約束した決定を下すには、非常に正当な理由がありました。

IMHO OPを更新して、このスレッドで構文の議論を行う必要がないことを指摘し、排他的範囲構文（つまり、（a、b）および（a、b]範囲）の提案を別のスレッドに移動する必要があります。

これは、現在の計画を安定させるために行う必要があることについてのみ話す必要があります。

@clarcharr私はほとんど一方的な決定を下し、それをOPに追加しました。良い考えです。 ノイズが続く場合は、スレッドをロックすることに投票します。

こんにちは、私は新しいので、これに取り組み始めたいと思います。 パターンで...同義語として..=を追加し、式で...を廃止し、構文が次のように変更されたことを示すエラーを表示するPRを作成しようとします。 ..= 。 この音は正しいですか？

@ Badel2かっこいい。 私は実際に始めました-すぐにブランチをプッシュして、ここにリンクします。

@durkaは明確にするために、 @ Badel2をブランチから開始することを提案していますか？ impl期間の作業の一環としてそれらを指導できますか？ 彼らはGitterチャンネルにいます。

また、実際の問題は..ことに同意します。 したがって、より好ましい解決策は、 ..<ようなものを優先して..を非推奨にすることです（一度に置き換えないので、既存のコードを壊すことはありません）（ a..<b間に混乱はありません） (a..)<b 、 ..は最終的には存在しなくなるため）。

@ hyst329すでに作成された投稿をお読みください。

最初の投稿では、太字のテキストで、「このスレッドで構文に関する議論を行うべきではありません」と述べています。

それはさておき、あなたが説明することは、既存の議論を読んでいない他の人によってすでに何度もここで提案されており、それが実行可能な選択肢ではない理由に応じて与えられた複数の理由があります。

申し訳ありませんが、これはあまり建設的ではありませんが、 ..=を表示してそれが何であるかを思い出そうとするたびに、 +=または<<=似た代入演算子のように見えます。 そうでないことは非常に混乱します。 （確かにこれは文脈から外れていますが、たとえば「 ..=構文の初期サポート」https://this-week-in-rust.org/blog/2017/10/03/this-week-さびで-202 /）

@SimonSapin上記で同じ批判をより建設的な方法で表現し、代わりに..^提案しました： https ：

私にとって、 ..=を表す..< .. 、包括的範囲の場合は..=選択しても大丈夫

@SimonSapin完全に満足している人はいないと思います。 問題は、残念ながら何百ものコメントがより良い代替案がないことを確認していることです。

このパッチは、エッジケースをカバーするためだけに現在のパターン構文を台無しにするよりも、何もしないよりも私を納得させるために達成されました。

..はパターンのユースケースがほとんどなく、それがなくてもいつでも対処できます。

...は、実際にそれらを必要とする式でRangeInclusiveまたは(Bound<T>, Bound<T>)に置き換えることができます。 より冗長ですが、理解しやすいです。

@UtherII

...そして、コンパイラの「安定した範囲で包括的範囲構文を使用することはできません」というメッセージによって微妙なバグから救われたとき、 ...は受け入れられないと確信していました。

すばやく連続して複数回押すと、誤って. 1回多すぎて（または、関係するメカニズムを考えると、1回少なすぎて）ヒットするの

「パターンで...同義語として..=を受け入れ、式で..=を受け入れるように変更する」をチェックしました。これは、＃44709の後にすでに当てはまるためです。 dotdoteq_in_patternsとinclusive_range_syntax機能。 残っているのは、文書化と安定化だけです。

安定化の要請

包括的範囲を1.26 （3月30日ベータ、5月11日安定）またはそれ以前に安定させたい。 安定化PRは＃47813として提出されました。

概要

次の3つの機能が安定します。

• inclusive_range_syntax —式のa..=bおよび..=b構文：

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

• dotdoteq_in_patterns —パターン内のa..=b構文：

  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!(),
  }
  

  （注： a...b構文は、警告なしで引き続き受け入れられます）

• inclusive_range — std::ops::{RangeInclusive, RangeInclusiveTo}タイプとそのフィールド：

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

ドキュメンテーション

いくつかのドキュメントPRが@alercahから提出され

• 本： https ：
• リファレンス： https ：
• Rust-by-Example： https ：

テスト

テストケースは次の場所にあります。

• run-pass/range_inclusive.rs —
  forループでのa..=b使用、イテレータ、スライスインデックス、 ..=演算子の優先順位、タイプチェックの動作などの基本的なテスト。
• libcore/tests/iter.rs —
  イテレータとしてのa..=bの動作に関するさらなるテスト。 nth() 、 min() 、 max() 、 last()特殊化が正しく機能し、 (5..=5).next()呼び出した後の範囲が1..=0 。
• liballoc/tests/str.rs 、 liballoc/tests/btree/map.rsおよびliballoc/tests/vec.rs —
  a..=bがさまざまなコレクションタイプで正しく機能することを確認します。
• parse-fail/range_inclusive.rsおよびui/impossible_range.rs —
  式がコンパイルできないため、 a..=や..=などのナンセンス構造を保証します
• parse-fail/range_inclusive_dotdotdot.rs —
  非推奨の式構文a...bおよび...bを確実に拒否します。
• run-pass/inc-range-pat.rs —
  パターンでのa..=bとa...b両方の使用が受け入れられ、同等であることを確認します。
• compile-fail/range_traits-1.rsおよびcompile-fail/range_traits-6.rs —
  RangeInclusiveとRangeInclusiveToが（他の範囲と同様に） PartialOrd実装せず、 RangeInclusiveがCopy実装しないことを保証します（できません）反復子であるため、コピーを実装します）。
• libcore/tests/ops.rs —
  手動で作成されたRangeInclusiveインスタンスの反復が機能することを確認します。

未解決の質問

• a..=bをforループで使用すると、 next()がより複雑でオプティマイザーに適さないため、 a..(b+1)よりもパフォーマンスが大幅に低下します。 これは現在＃45222で追跡されています。 これは現在、forループの代わりにイテレータメソッドを使用する場合に＃48012によって軽減されます。

  rust-lang / rfcs＃1980の設計にまだコミットしたくない場合は、 RangeInclusiveのフィールドを不安定に保つ必要があるかもしれません。

rust-lang / rfcs＃1980の設計にまだコミットしたくない場合は、RangeInclusiveのフィールドを不安定に保つ必要があるかもしれません。

+1
メソッドベースのインターフェイスではなく、範囲フィールドを直接公開する必要はありますか？

@rfcbotfcpマージ

@kennytmの要約に従って、包括的範囲構文（ ..= ）を安定させることを提案します。

（とはいえ、 ..=パフォーマンスの低下はやや懸念されており、当面は..=を直接実装しないIteratorにするのが理にかなっているのではないかと思います。これを軽減するために。）

チームメンバーの@nikomatsakisは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

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

現在リストされている懸念はありません。

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

これを軽減するために、当面は.. =直接実装されていないイテレータを作成するのが理にかなっているのではないかと思います。

これらの安定した特性は、現在のNightlyの少なくともいくつかのTに対してRangeInclusive<T>で実装されます： Iterator 、 FusedIterator 、 ExactSizeIterator 、 Debug 、 Clone 、 Eq 、 PartialEq 、 Hash 、 TrustedLen 。

@SimonSapin忘れてしまいましたが、構造体はすでに安定していますか？ （言い換えれば、それは観察可能ですか？）私はそうではないと思っていました。

そうは言っても、私も本当に、 1..2と1..=2はすべて同じ場所で使用できるはずだと思います。これは、ここで変更を加えることに反対し、代わりに、緩和策を追求して改善する必要があることを示唆しています。最適化。

end == MAX特別な場合の範囲はどうですか？ これにより、境界に直接行くものがより多くのコードを持っていることを除いて、排他的なものと同じコードを持つ最も包括的な範囲につながる可能性があります。 end != Maxブランチはend変更しないため、オプティマイザーによって簡単にインライン化できます。

@nikomatsakisいいえ、構造体は現在不安定です。 しかし、@ kennytmの提案には、それらを安定させることが含まれています。

@SimonSapin

いいえ、構造体は現在不安定です。 しかし、@ kennytmの提案には、それらを安定させることが含まれています。

そうですか; 確かに、これが、 Iterator implを今すぐ削除する必要があると述べた理由です。 =）

@SimonSapin構造体を安定させずに、 a..=b式の構文を安定させることはできないと思います。 ただし、変更する可能性があると思われる場合は、フィールドを不安定なままにすることができます。

そうです、これらの型の値を作成するための構文を安定させるときに、型を安定させるべきではないと言うつもりはありませんでした。

範囲構文のバイクシェッドを脱出し、安定させるための万歳！ ：tada：

タイムマシンを考えると、範囲タイプはどれも:Iteratorではなく、 :IntoIteratorであると主張します。 しかし、今のように、範囲とのChainして、「まあ、内部反復の方が速い場合があります」バケットに入れることができます。

未解決で、反復に関連するもう1つのこと：反復が完了したら、RangeInclusiveの特定の表現にコミットしますか？ 今のところ1..=0になりますが、

このケースをChainで「まあ、内部反復が時々もっと速くなることがわかった」バケットに入れることができます。

排他的な範囲以上のパフォーマンスを得るには、本当に修正する必要があると思います。 それが存在する根本的な理由はありません。

それが存在する_基本的な_理由はありません。

それは、どの不変条件を強制できるかによって異なります。 状態のビットが追加された以前の2つの定式化では、反復が完了したときにそのビットが実際に設定されたことを強制するものは何もありませんでした（実際、 100..=0ようなリテラルには設定されていませんRangeInclusive: !Iteratorを作成する、またはこれらの種類のループを最適化するためにLLVMを改善することを意味するように、完全に修正します。

そうは言っても、私はRangeInclusive::nextを書くためのいくつかの異なる方法を試しましたが、 Option<Ordering>に一致するという私の過去の自己の選択は、LLVMを非常に悲しくしているようです-代わりに比較演算子をそこに置くだけではるかに優れたアセンブリ。 PRを編集します： https ：

タイムマシンを考えると、Rangeタイプはどれも：Iteratorではなく、単に：IntoIteratorであると主張します。 しかし、今のように、範囲との一貫性が最良の選択肢だと思います。 このケースをChainで「まあ、内部反復が時々もっと速くなることがわかった」バケットに入れることができます。

私は基本的にこれに同意します。

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

@rfcbotfcpキャンセル

@withoutboatsと@KodrAusはチェックボックスを

@cramertjの提案はキャンセルされました。

@rfcbotfcpマージ

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

チームメンバーの@cramertjは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

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

現在リストされている懸念はありません。

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

@rfcbotfcpの懸念範囲パターンにはオペレーターの優先順位の問題があります：//github.com/rust-lang/rust/issues/48501。

（ @petrochenkov構文は<strong i="6">@rfcbot</strong> concern KEYWORD 、 fcpはありません。ただし、懸念事項を登録できるのはタグ付けされたチームメンバーだけだと思います。）

これで最終コメント期間が終了しました。

＃48501が安定化をブロックするのに十分である場合、＃48500がマージ（および安定化）するのを待つ必要があると思いますか？ うーん、もっと速い道を見つけられるといいのですが。 この機能は非常に長い間使用されており、現在は不安定な状態にあり、エラーメッセージによって構文が不安定になっています。

@durka
この安定化には、 https：//github.com/rust-lang/rust/pull/48500の安定化を待つ必要はないと思い
パターンに...がまだ存在し、古い優先度が残っているため、パターンに&BEGIN ... ENDがある場合（これは非常にまれなことだと思います）、常に..=変更しないオプションがあります。しばらくの間

＃48500をかなり早く安定させることができると思います

個人的には「不安定」に着陸しても大丈夫です

inclusive rangeは、＃47813プルリクエストがマージされたため安定しましたが、1.25リリースには含まれていません。なぜですか？ プルリクエストは3月16日にマージされましたが

@mominul機能は、マスターブランチにマージされた後にのみ使用できるため、 ..=は1.25ではなく1.26から使用できます。

そうすれば、ベータ版と毎晩、安定化する前にテストできます。

@kennytmと@clarcharrの入力に感謝します！ Rust 1.26のリリースは、少なくとも私にとっては間違いなく退屈ではありません。 ：笑顔：

この議論に参加するには遅すぎることは知っていますが、 ..構文を完全に省略して、代わりに単語を使用してみませんか？

Scalaには、 1 to 4を生成する[1, 2, 3, 4] 、 1 until 4を生成する[1, 2, 3] 、およびステップサイズを示すオプションのbyキーワードがあります。 ： 1 to 10 by 2 = [1, 3, 5, 7, 9] 。

これにより、意図がより明確になり、誰もが心配しているように見える「オフバイワン」エラーが回避されます。

確かに、元の構文がサポートされていない場合、これは既存のすべてのコードを壊します。

錆びた範囲の@ElectricCoffeeは、数字だけでなく、すべてのタイプをサポートします。 それをサポートするために、キーワードとしてtoとuntilを導入する必要があると思います。それは、はるかに大きな大きな変化になるでしょう。

Scalaではうまく機能しますが、Rustのデザインの選択は大きく異なります。

@ElectricCoffeeその気持ちはいいのですが、キーワードを追加するのは望ましくないと思います。

組み込みの言語キーワードは、関数名や変数名と衝突する可能性があるため、最小限に抑える必要があると思います。

toとuntilはstd使用されている単語ではありませんが（私が知る限り）、他の箱で使用されている一般的な単語であると確信しています。プロジェクト。

@daborossは実際には私が考慮しなかった公正な点ですが、そうは言っても、 a .. bは、 aとbに関係なく、ある意味でa to b意味しますb実際にそうです。

そして、ええ、 @ timvisee彼らはおそらくそうです。

@ElectricCoffeeしかし、 toが..=を意味し、 untilが..を意味する場合、 a to bではなくa until bを記述する必要があります。 a to b a .. b a to b代わりにa .. b 。 ご覧のとおり、これらの単語を演算子よりも「直感的に」使用することはできません。ただし、 ..が使用されるすべての場所にuntilを記述する方が、より一般的であるため、より冗長になります。 ..= （したがって、単語が使用された場合は、 ..に短い単語を割り当てる必要があります）。

そして、あなたはその@Boscopについて絶対に正しいです、しかしそれは言葉がどのように行われることができるかの単なる例でした。

一部の言語でも、排他的なto uptoと包括的な
それはすべてアイデアとして意図されていました。

Scalaでは、包括的範囲は排他的範囲よりも使用されるため、短い単語が与えられます。

@timvisee Oneはa.to(b)とa.until(b)を使用するだけで、追加のキーワードは必要ありません（構文がそれほど不器用になることはありません）。

@ hyst329私もそれについて考えていませんでした。 私は言わなければなりません、私はその考えが本当に好きです！ あなたは確かに正しいです。

これが現在の（/新しい）構文の適切な完全な置き換えになるとは思いませんが。 しかし、それは素晴らしい追加になるでしょう。

直感性に関するBoscopのコメントに同意する必要があります。 「含む」や「除く」などの単語を除けば、日常の英語では、包括的範囲と排他的範囲を明確に区別していないため、既成のショートカットがあります。

「AからB」も使用される文脈で使用されない限り、「AからB」がここカナダのオンタリオ州南部での日常のスピーチの包括的または排他的な範囲を意味するかどうかはあいまいであり、「まで」が関連付けられていますこの緩いの意味で使用する場合、それは不明だ、と強く十分な時間を持つかどうかを「イベント」という「我々はXが表示されるまで」または「我々はXの処理が完了するまで」されると仲間「になるまで」。

@ hyst329ただし、メソッドとしてそれらを使用すると、範囲が数値タイプに制限されます。 数値の範囲用に1つの構文を使用したり、他の範囲用に別の構文を使用したりする必要はありません。

範囲を作成するためのプレリュードに新しいキャッチオール特性を追加できると思いますが、それでも実際のto untilメソッドと

私は告白します、私はキーワードの提案がエイプリルフールの冗談だと思いました。
.. =構文が安定しました。

13:53の木、2018年4月5日には、デビッド・ロスの[email protected]は書きました：

@ hyst329https ：//github.com/hyst329メソッドとしてそれらを使用すると制限されます
ただし、範囲は数値タイプです。 私は本当に1つの構文を持っていたくない
数の範囲と他のものの範囲のための別のもの。

作成するためのプレリュードに新しいキャッチオール特性を追加できると思います
範囲がありますが、それはまだ持っているもののための破壊的な変化に向かっています
実際のメソッドとまでのメソッド。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/28237#issuecomment-379021814 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3nwBj-b985q1Ez0OHDEHkG6DWV_5nks5tlloZgaJpZM4F4LbW
。

ええ、この問題について300以上のコメントがあり、最初のコメントには次のように書かれています。

このスレッドでは、これ以上構文について説明する必要はありません。 ここで既存のコメントとその理論的根拠をすべて読んだ後、排他的範囲構文のさまざまな提案をユーザーのフォーラムまたは内部フォーラムで行う必要があります。 特に、下位互換性を破ることは初心者ではありません。

とりあえずこの問題をロックします。つま先を踏んでいる場合は申し訳ありません。

この問題でカバーされていることはすべて完了していると思います。 他に問題がある場合は、問題の元のメッセージのチェックリストを再度開いて更新してください。