Rust: クランプRFCの追跡の問題

注意：これはサーボとパスファインダーを壊しました。

cc @ rust-lang / libs、これはmin / maxに似たケースで、エコシステムはすでにclamp名前を使用していたため、追加するとあいまいさが生じます。 。 これは、semverポリシーごとに許可されている破損ですが、それでもダウンストリームの痛みを引き起こしています。

火曜日のトリアージ会議にノミネート。

それまでの間、何か考えはありますか？

繰り返さないほうがいいという点で、私はこれについて使っています。 「クランプ」はおそらく素晴らしい名前ですが、別の名前を選択することでこれを回避できますか？

restrict
clamp_to_range
min_max （最小値と最大値を組み合わせるようなものだから）
これらは機能する可能性があります。 クレーターを使用して、 clampの影響が実際にどれほど悪いかを判断できますか？ clampは、いくつかの言語とライブラリでよく認識されています。

名前を変更する必要があると思われる場合は、PRをすぐに元に戻してから、クレーターなどでより慎重にテストすることをお勧めします。

もちろん。 私はこれまで火口を使ったことがありませんが、学ぶことはできます。

@Xaeroxeああ、すみません、私はすぐに元に戻すPRを取得することを意味しました。 （私は今日休暇中なので、着陸を手伝うために、 @ BurntSushiや@alexcrichtonなどのlibsの他の誰かが必要になる場合があります）。

現在PRの準備をしています。 あなたの休暇を楽しんでください！

PR対応https://github.com/rust-lang/rust/pull/44438

clamp_to_range(min, max)はclamp_to_min(min)とclamp_to_max(max) （ min <= maxという追加のアサーションを使用）、これらの関数を個別に呼び出すこともできますか？

私はその考えがRFCを義務付けていると思います。

私は4行の関数をstdライブラリに取り込む作業を6か月間行っていますが、言わざるを得ません。 ちょっと疲れました。 同じ関数が2日でnumにマージされ、

@aturonの以前のノミネートが引き続き表示されるように、これを再開します。

これは書面で行うか、将来の人々の時間を無駄にしないように、どのような変更を加えることができるかについてのガイダンスを更新する必要があると思います。

これが破損の原因となる可能性があることは、早い段階から非常に明白でした。 個人的に、私はそれをord_max_minと比較しました。

• https://github.com/rust-lang/rust/pull/42496
• https://github.com/bluss/petgraph/issues/153
• https://github.com/rust-lang/rust/issues/43667
• https://github.com/rust-lang/rust/issues/43657
• https://github.com/rust-lang/rust/issues/43665
• https://github.com/rust-lang/rust/issues/43682
• https://github.com/rust-lang/rust/issues/43680
• https://github.com/apasel422/tree/issues/23
• https://github.com/dche/glm-rs/pull/21
• （おそらくもっと多いですが、それらは追跡の問題に関連していました）

そして、それに対する応答は、「関数Ord::minが追加されました[...] libsチームは、これが破損として受け入れられると本日決定しました」でした。 そして、それはより一般的な名前のTMTOWTDI機能でしたが、 clampは別の形式でstdにまだ存在していません

主観的には、このRFCが元に戻された場合、実際のルールは「基本的に、 Iteratorを除いて、stdのトレイトに新しいメソッドを配置することはできません」と感じます。

また、実際の型に新しいメソッドを実際に配置することもできません。 誰かがstdのタイプの「拡張特性」を持っていた状況を考えてみましょう。 stdは、このタイプの実際のメソッドとして提供される拡張特性のメソッドを実装するようになりました。 その後、これは安定しますが、この新しいメソッドはまだ機能フラグの背後にあります。 コンパイラは、メソッドが機能フラグの背後にあり、安定したツールチェーンでは使用できないと文句を言います。コンパイラが以前のように拡張トレイトのメソッドを選択して、安定したコンパイラで破損を引き起こす代わりに。

また、注目に値します。これは、標準ライブラリの問題だけではありません。 メソッド呼び出しの構文により、エコシステムのほぼどこにでも重大な変更が導入されるのを回避することが非常に困難になります。

（メタ）ここにirloで

＃44438が正当化されることに同意する場合、

1. のような保証型推論の破損が本当にXIBとして無視できるかどうかを再考する必要があるかもしれません。

   現在、型推論の変更は、RFC 1105および1122で許容できると見なされています。これは、UFCSまたはその他の方法を使用して型を強制することができるためです。 しかし、コミュニティは＃42496（ Ord::{min, max} ）によって引き起こされた破損を本当に好きではありません。 さらに、＃41336（ T += &T最初の試行）は、8つの型推論の回帰のために「ちょうど」閉じられました。

2. メソッドを追加するときはいつでも、名前がまだ存在していないことを確認するためにクレーターを実行する必要があります。

   固有のメソッドを追加すると、推論の失敗も発生する可能性があることに注意してください—＃41793は、固有のメソッド{f32, f64}::from_bits追加したために発生しました。これは、ダウンストリームトレイトのメソッドieee754::Ieee754::from_bitsと競合します。

3. ダウンストリームクレートが#![feature(clamp)]指定しなかった場合、これが独自の解決策でない限り、候補Ord::clampは決して考慮されるべきではありません（将来互換性のある警告が発行される可能性があります）。 これにより、「インスタブレイク」ではない新しい特性メソッドの導入が可能になりますが、安定化すると問題は再発します。

拡張特性を定義するのに十分な方法を人々が望んでいたメソッドを標準ライブラリに追加できない場合、私たちはかなり悪い場所にいるようです。

最大/最小は、共通の特性で共通のメソッド名を使用することに関して特に悪い点にぶつかりました。 同じことをクランプに適用する必要はありません。

私はまだ「はい」と言いたいのですが、 @ sfacklerは、さまざまなタイプによって非常に一般的に実装されているトレイトにメソッドを本当に追加する必要がありますか？ 既存のトレイトにバイインしたすべてのタイプのAPIに追加するときは、注意する必要があります。

スペシャライゼーションが来ると、拡張メソッドを拡張トレイトに配置しても何も失われません。

厄介な部分の1つは、新しいstdメソッドがコードを壊した場合、不安定であるため、実際に使用できるようになるずっと前に表示されることです。 それ以外は、同じ意味のメソッドとの競合であればそれほど悪くはありません。

破損を避けるためにこの関数に別の名前を付けるのは悪い解決策だと思います。 それは機能しますが、この機能を使用してコードの将来の可読性を最適化するのではなく、いくつかのクレート（すべてが毎晩オプトインしている）を壊さないように最適化します。

私にはいくつかの懸念がありますが、そのうちのいくつかは心配する必要はありません。

• 名前とシャドウイングは理想的ではありませんが、機能します
• 数値ベクトルと行列の場合、最大/最小/クランプは理想的ではないと思いますが、これはOrdをまったく使用しないことで解決されます。 Ndarrayは、要素ごとの汎用引数（スカラーまたは配列）クランプを実行したいと考えていますが、Ordは私たちや同様のライブラリでは使用されていません。 だから心配しないでください。
• 数値ではない既存の複合タイプ：BtreeMapは、この変更でメソッドクランプを取得します。 それは一般的に意味がありますか？ デフォルトとは別に、合理的な意味を実装できますか？
• 値によるモードの呼び出しは、すべての実装に適合するわけではありません。 繰り返しますが、BtreeMap。 クランプは3つのマップを消費し、そのうちの1つを返す必要がありますか？

化合物タイプ

BtreeSet<BtreeSet<impl Ord>>::rangeと同じくらい理にかなっていると思います。 ただし、 Vec<char>ように、役立つ可能性がある特定のケースもあります。

値による呼び出しモード

これがRFCで取り上げられたとき、答えは単にCowを使用することでした。

もちろん、ストレージを再利用することは、次のようなものである可能性があります。

    fn clamp<T>(mut self, low: &T, high: &T) -> Self
        where T: ?Sized + ToOwned<Owned=Self> + Ord, Self : Borrow<T>
    {
        assert!(low <= high);
        if self.borrow() < &low {
            low.clone_into(&mut self);
        } else if self.borrow() >= &high {
            high.clone_into(&mut self);
        }
        self
    }

どのhttps://github.com/rust-lang/rfcs/pull/2111を呼び出すと人間工学的になる可能性があり

libsチームは、数日前のトリアージ中にこれについて話し合いました。結論として、この変更のエコシステム全体での障害が何であるかを確認するために、クレーターを実行する必要があります。 その結果は、まさにこの問題に対してどのような行動を取るべきかを決定するでしょう。

優先度の低いトレイトや、より風味豊かな方法での拡張トレイトの使用など、このようなAPIを簡単に追加するために追加できる可能性のある将来の言語機能がいくつかあります。 ただし、このような進歩で必ずしもこれをブロックしたくはありません。

この機能でクレーターランが発生したことはありますか？

＃48552がマージされた後、 clamp()メソッドを復活させる予定です。 ただし、 RangeInclusiveはその前に安定化される予定です。つまり、範囲ベースの代替案を検討できるようになりました（これは実際には元の提案ですが、 ..=が非常に不安定だったため撤回されました😄）：

// Current
trait Ord {
    fn clamp(self, min: Self, max: Self) -> Self { ... }
}
assert_eq!(9.clamp(6, 7), 7);


// Alternative
trait Ord {
    fn clamp(self, range: RangeInclusive<Self>) -> Self { ... }
}
assert_eq!(9.clamp(6..=7), 7);

安定したRangeInclusiveは、物事をひっくり返すなど、他の可能性も開きます（これにより、autorefでいくつかの興味深い可能性が可能になり、名前の衝突が完全に回避されます）。

impl<T: Ord + Clone> RangeInclusive<T> {
    fn clamp(&self, mut x: T) -> T {
        if x < self.start { x.clone_from(&self.start); }
        else if x > self.end { x.clone_from(&self.end); }
        x
    } 
} 

    assert_eq!((1..=10).clamp(11), 10);

    let strings = String::from("aa")..=String::from("b");
    assert_eq!(strings.clamp(String::from("a")), "aa");
    assert_eq!(strings.clamp(String::from("aaa")), "aaa");

https://play.rust-lang.org/?gist=38def79ba2f3f8380197918377dc66f5&version=nightly

でも、それがいいと思うかどうかは決めていません...

範囲メソッドとして使用する場合は、別の名前を使用します。

形に関係なく、きっと早くこの機能を楽しんでいただけると思います。

現在の状況はどうですか？
RangeInclusiveにクランプを追加する方が良い選択肢かもしれないというコンセンサスがあるように私には思えます。
それで誰かがRFCを書かなければなりませんか？

現時点では、完全なRFCはおそらく必要ありません。 どのスペルを選択するかを決定するだけです。

1. value.clamp(min, max) （RFCをそのままフォロー）
2. value.clamp(min..=max)
3. (min..=max).clamp(value)

オプション2または3を使用すると、部分的なクランプが簡単になります。 特別なclamp_to_startまたはclamp_to_endメソッドを必要とせずに、 value.clamp(min..)またはvalue.clamp(..=max)を実行できます。

@egilburg ：すでにこれらの特別なメソッドがあります： clamp_to_startはmax 、 clamp_to_endはminです：wink：

しかし、一貫性は素晴らしいです。

@egilburgRustは直接オーバーロードをサポートしていません。 オプション2を提案で機能させるには、 RangeInclusive 、 RangeToInclusive 、およびRangeFromに実装された新しい特性が必要です。これらは、かなり重いと感じます。

そのオプション3が最良のオプションだと思います。

1または2は最も驚くべきことではありません。 ローカル実装を標準実装に置き換えるために多くのコードを実行する必要が少ないため、1のままにしておきます。

_すべて_範囲*タイプを使用するか、それらの_なし_を使用することを計画する必要があると思います。

もちろん、それは困難のようなもののためだRangeのためのよりRangeInclusive 。 しかし、 (0.0..1.0).clamp(2.0_f32) => 0.99999994_f32何かいいことがあります。

@kennytmでは、オプション3でプルリクエストを開くと、マージされると思いますか？
または、次に進む方法についてどう思いますか？

@EdorianDarkこれについては、@ rust-lang / libsに質問する必要があります😃

私は個人的にオプション2が好きで、 RangeInclusiveだけです。 前述のように、「部分クランプ」はminとmaxすでに存在します。

@SimonSapinに同意し@kennytmが以前に

クランプが再びマスターになりました！

＃44097にはなかったのに、今でもこれを受け入れられるようにした変更点を理解しようとしていますが、私は満足しています。

安定する前でも即座に推論を破るのではなく、＃48552による警告期間があります。

それは素晴らしいニュースです、ありがとう！

@ kennytm ＃48552を実現するために行ったレッグワークに感謝します。また、

https://rust.godbolt.org/z/JmLWJi

pub fn clamped(a: f32) -> f32 {
   a.clamp(0.,255.)
}

コンパイル先：

  vxorps xmm1, xmm1, xmm1
  vmaxss xmm0, xmm1, xmm0
  vmovss xmm1, dword ptr [rip + .LCPI0_0]
  vminss xmm0, xmm1, xmm0

これはそれほど悪くはありませんが（ vmaxssとvminssが使用されます）、次のようになります。

pub fn maxmined(a: f32) -> f32 {
   (0f32).max(a).min(255.)
}

使用する命令が1つ少なくなります。

  vxorps xmm1, xmm1, xmm1
  vmaxss xmm0, xmm0, xmm1
  vminss xmm0, xmm0, dword ptr [rip + .LCPI1_0]

それはクランプの実装に固有のものですか、それともLLVM最適化の癖ですか？

@kornelski clamp ing NANは、そのNANを保持することになっていますが、 max / minであるため、 maxminedは保持しません。 minは_non_- NANます。

NANの期待に応え、より短い実装を見つけるのは素晴らしいことです。 そして、doctestsがNANの取り扱いを紹介するのは良いことです。 元のPRにはいくつかあったようです：

https://github.com/rust-lang/rust/blob/b762283e57ff71f6763effb9cfc7fc0c7967b6b0/src/libstd/f32.rs#L1089 -L1094

@scottmcmhttps ：//github.com/rust-lang/rust/pull/59327完了

最小または最大がNaNの場合、クランプフロートがパニックになるのはなぜですか？ アサーションをassert!(min <= max)からassert!(!(min > max))に変更して、maxおよびminメソッドの場合と同様に、NaNの最小値または最大値が影響を与えないようにします。

クランプ内のminまたはmax NANは、プログラミングエラーを示している可能性があり、クランプされていないデータをIOにフィードするよりも、早くパニックに陥る方がよいと考えました。 上限または下限が必要ない場合、この関数は適していません。

上限または下限が必要ない場合は、いつでもINFと-INFを使用できますよね？ NaNとは異なり、これも数学的に意味があります。 ただし、ほとんどの場合、 maxとminを使用することをお勧めします。

@Xaeroxe実装していただきありがとうございます。

もしそれが安定したコードを壊すなら、多分これは次の版に行くかもしれませんか？

IMOがより詳細に検討する価値のあることの1つは、 f32 / f64片側クランプです。 議論はこのトピックに簡単に触れたようですが、実際には詳細には考慮されていません。

ほとんどの場合、片側クランプへの入力がNANの場合、結果がクランプ境界になるよりも、結果がNANである方が便利です。 したがって、既存のf32::min f64::max関数と

私がこれを取り上げる理由は、両面クランプと片面クランプが一貫したインターフェースを持っているとよいので、両面clampの設計に影響を与えるためです。 いくつかのオプションは次のとおりです。

1. input.clamp(min, max) 、 input.clamp_min(min) 、およびinput.clamp_max(max)
2. input.clamp(min..=max) 、 input.clamp(min..) 、 input.clamp(..=max)
3. input.clamp(min, max) 、 input.clamp(min, std::f64::INFINITY) 、 input.clamp(std::f64::NEG_INFINITY, max)

現在の実装（ minとmaxを別々のf32 / f64パラメーターとして）では、オプション1を選択する必要があります。これは完全に合理的だと思います。 、またはオプション3。IMOは冗長すぎます。 犠牲は、別々のclamp_min clamp_max関数と

私たちが提供できることも注目に値します

impl f32 {
    pub fn clamp<T>(self, bounds: T) -> f32
    where
        T: RangeBounds<f32>,
    {
         // ...
    }
}

// and for f64

f32 / f64場合、一般的なOrdとは異なり、排他的境界を処理する方法を実際に知っています。 もちろん、一貫性を保つためにOrd::clampを変更してRangeInclusive引数を取るようにしたいでしょう。 Ord::clampに対して2つの引数を優先するか、1つのRangeInclusive引数を優先するかについて、どちらの方法でも強い意見はなかったようです。

これがすでに解決された問題である場合は、私のコメントを遠慮なく却下してください。 以前の議論でそれらを見なかったので、私はこれらのものを持ち出したかっただけです。

トリアージ：以下のAPIは現在不安定であり、ここを指します。 NaNの取り扱い以外に考慮すべき問題はありますか？ NaN処理でブロックせずに、最初にOrd::clamp安定させる価値はありますか？

`` `錆
パブトレイトOrd：Eq + PartialOrd{{
//…
fnクランプ（自己、最小：自己、最大：自己）->自己ここで自己：サイズ設定{…}
}
impl f32 {
pub fnクランプ（自己、最小：f32、最大：f32）-> f32 {…}
}
impl f64 {
pub fnクランプ（自己、最小：f64、最大：f64）-> f64 {…}
}

@SimonSapin個人的に全体を安定させたいです

+1、これは完全なRFCを通過し、それ以降に出てくる資料はないと思います。 たとえば、NaN処理は、IRLOおよびRFCの議論で詳細に取り上げられました。

了解しました。それで十分です。

@rfcbotfcpマージ

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

• [x] @Amanieu
• [] @Kimundi
• [x] @SimonSapin
• [x] @alexcrichton
• [x] @dtolnay
• [] @sfackler
• [] @withoutboats

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

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

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

x.clamp(7..=13)とx.clamp(7, 13)についての決定はありましたか？ https://github.com/rust-lang/rust/issues/44095#issuecomment -533764997は、潜在的な将来のf64::clampとの一貫性を保つために、最初のものの方が優れている可能性があると述べています。

@ m-ou-se https://github.com/rust-lang/rust/issues/44095#issuecomment-411457313およびください。 58710＃pullrequestreview- 207529970。

.minと.maxは、 .min(...)を使用して上限を指定し、 .max(...)を使用して上限を指定すると、バグが頻繁に発生するため、これは非常に残念な解決策だと思います。下限。 これは非常に紛らわしく、これには非常に多くのバグがあります。 .clamp(..1.0)と.clamp(0.0..)は非常に明確です。

@CryZeは非常に良い点を。min =上限、max =下限を間違えたことがない場合でも、どちらを使用するかを覚えておくために精神体操を行う必要があります。 この認知的負荷は、あなたが解決しようとしているどんな問題にも費やしたほうがよいでしょう。

x.clamp(y, z)がもっと期待されていることは知っていますが、おそらくこれは革新の機会です;）

私は初期の段階で範囲をかなり実験し、RFCを数か月遅らせて、包括的範囲を実験できるようにしました。 （これは安定する前に開始されました）

浮動小数点数の排他範囲にクランプを実装できないことを発見しました。 一部の範囲タイプのみをサポートし、他のタイプはサポートしないという結果は驚くべきものでした。そのため、RFCを数か月遅らせてこの方法で実験したにもかかわらず、最終的に範囲は解決策ではないと判断しました。

@ m-ou-se＃44095（コメント）および＃58710（レビュー）から始まるディスカッションを参照してください。

編集：以下で指摘するように、プルリクエスト（＃58710）のディスカッションには、追跡の問題よりも設計上の決定に関するディスカッションが多く含まれています。 これがここで伝えられなかったのは残念です。ここでは通常、設計の議論が行われますが、議論されました。

一部の範囲タイプのみをサポートし、他の範囲タイプはサポートしないことは、結果に驚きすぎました

Rustはすでにいくつかの範囲を他の範囲とは異なる方法で処理しているため（たとえば、反復に使用するなど）、一部の範囲のみをclamp引数として許可することは、私にはまったく驚くことではありません。

これが最も役立つ分析です： https ：

@Xaeroxe一部の範囲タイプのみをサポートし、他の範囲タイプはサポートしていませんでした。

彼らが安定する前にこれについて考えていた場合、時間と一般的な使用法はあなたの意見を変えましたか、それともまだそうだと思いますか？

排他的範囲は整数とは異なる動作をするため、フロートには絶対に実装しないでください（範囲0..10は下限を含み、上限を除外します。したがって、仮想範囲0.0...10.0必要なのはなぜですか。

@varkorしかし、これは、追跡の問題についての議論なしに、レビューでの1つのコメントの後に変更されました。

これは過度に対立的なものとして出くわすかもしれません。「会話を調べたときに、範囲を使用すべきでない理由について説得力のある議論が見つかりませんでした。誰かが私にそれを指摘できますか？」のようなものを試してください。

あなたが探している議論はここにあると思います： https ：

編集@Xaeroxeはそれに私を打ち負かしました:)

時間と一般的な使用法があなたの意見を変えました

これまでのところそうではありませんが、範囲は私が日常のコーディングで使用することはほとんどありません。 私は、コード例と部分的な範囲をサポートする既存のAPIに説得されることを受け入れています。 ただし、その質問を解決したとしても、scottmcmがRFCコメントで提起する他のいくつかの優れた点に対処する必要があります。 たとえば、 StepはOrdほど多くのタイプに実装されていませんが、このマイナーな構文上の変更はそれらのタイプを失う価値がありますか？ さらに、非包括的範囲クランプの使用例はありますか？ 私の知る限り、排他的な範囲クランプをサポートする必要性を感じた言語やフレームワークは他にありませんでした。それで、どのようなメリットが得られるでしょうか。 範囲を満足のいく方法で実装することははるかに困難であり、多くの欠点とわずかな利点がありました。

範囲を使用してこれを実装すると、次の

したがって、このアプローチを採用すべきではないと思う理由がいくつかあります。

1. 必要な範囲の選択は、新しい特性を必要とするほど斬新であり、特に最も一般的な範囲であるRange除外します。

2. 私たちはすでにRFCプロセスでこれまでのところ進んでおり、これからstdが得る唯一のことは、 .max()または.min()を記述するさらに別の方法です。 Rustですでに実行できることを実装するために、RFCをプロセスの最初に戻したくはありません。

3. まだ存在するかどうかわからないユースケースに対応するために、関数で発生する分岐の量が2倍になります。 これをベンチマークに表示させることはできません。

片側クランプ操作の必要性

... stdがこれから得られる唯一のことは、 .max()または.min()を記述するさらに別の方法です。

私が言いたかった主なポイントは、 .min() / .max()と片側クランプの間のこの明らかな同等性が議論の中で何度も出てくるのを見たということですが、操作は同等ではありNANを処理する方法での浮動小数点数の場合。

たとえば、 input.max(0.)を、負の数をゼロにクランプする式と見なします。 inputがNAN以外の場合、正常に機能します。 ただし、 inputがNAN場合、 0.と評価されます。 これが望ましい動作になることはほとんどありません。 片側クランプはNAN値を保持する必要があります。 （このコメントとこのコメントを参照してください。）結論として、 .max()は、2つの数値のうち大きい方をとるにはうまく機能しますが、片側クランプにはうまく機能しません。

したがって、浮動小数点数には片側クランプ操作（ .min() / .max() ）が必要です。 他の人は、非浮動小数点型の片側クランプ操作の有用性についても良い議論をしました。 次の質問は、それらの操作をどのように表現したいかです。

片側クランプ操作の表現方法

.clamp()とINFINITY

つまり、片側クランプ操作を追加しないでください。 INFINITYまたはNEG_INFINITY境界で.clamp()を使用するようにユーザーに指示するだけです。 たとえば、ユーザーにinput.clamp(0., std::f64::INFINITY)と書くように伝えます。

これは非常に冗長であり、 NAN処理の微妙な違いに気付いていない場合、ユーザーは誤った.min() / .max()するようになります。 さらに、 T: Ord場合は役に立ちません。また、IMOは他の方法よりも明確ではありません。

.clamp_min()および.clamp_max()

妥当なオプションの1つは、 .clamp_min() .clamp_max()メソッドとclamp実装を安定させるには、このアプローチを使用する必要があることを認識していることを確認したかっただけです。

範囲引数

別のオプションは、 clampに範囲引数を取るようにすることです。 @Xaeroxeはこれを実装する1つの方法を示しましたが、彼が述べたように、その実装にはいくつかの欠点があります。 実装を作成する別の方法は、スライスが現在実装されている方法（ SliceIndexトレイト）に似ています。 これにより、範囲タイプのサブセットの実装の提供と追加の複雑さに関する懸念を除いて、ディスカッションで見たすべての異論が解決されます。 多少複雑になることに同意しますが、IMOは.clamp_min() / .clamp_max()追加するよりもそれほど悪くはありません。 Ord場合、次のようなものを提案します。

pub trait Ord: Eq + PartialOrd<Self> {
    // ...

    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
}

pub trait Clamp<T> {
    type Output;
    fn clamp(self, input: T) -> Self::Output;
}

impl<T> Clamp<T> for RangeFull {
    type Output = T;
    fn clamp(self, input: T) -> T {
        input
    }
}

impl<T: Ord> Clamp<T> for RangeFrom<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        if input < self.start {
            self.start
        } else {
            input
        }
    }
}

impl<T: Ord> Clamp<T> for RangeToInclusive<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        if input > self.end {
            self.end
        } else {
            input
        }
    }
}

impl<T: Ord> Clamp<T> for RangeInclusive<T> {
    type Output = T;
    fn clamp(self, input: T) -> T {
        assert!(self.start <= self.end);
        let mut x = input;
        if x < self.start { x = self.start; }
        if x > self.end { x = self.end; }
        x
    }
}

これに関するいくつかの考え：

• T: Ord + Step排他範囲の実装を追加できます。
• SliceIndexトレイトと同様に、 Clampトレイトを夜間のみ保持できます。

• f32 / f64をサポートするために、

  1. 実装をT: PartialOrdます。 現在の実装でなぜ（私はわからないclamp上ですOrdの代わりにPartialOrdたぶん私はそれはのように思える？議論で何かを逃した。 PartialOrdで十分です。）

  2. または、 f32およびf64専用の実装を記述します。 （必要に応じて、後で変更を加えることなく、いつでもオプションiに切り替えることができます。）

  次に追加します

  impl f32 {
    // ...
    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
  }
  
  impl f64 {
    // ...
    fn clamp<B>(self, bounds: B) -> B::Output
    where
        B: Clamp<Self>,
    {
        bounds.clamp(self)
    }
  }
  

• 必要に応じて、後でf32 / f64 、排他範囲にClampを実装できます。 （ @scottmcmは、 std意図的にf32 / f64先行操作がないため、これは簡単ではないとコメントしました。なぜstdかわかりません。これらの操作はありません。非正規化数の問題である可能性がありますか？それでも、後で対処できます。）

  f32 / f64排他的範囲にClamp実装を追加しなくても、これがあまりにも驚くべきことであることに同意しません。 @varkorが指摘しているように、RustはCopyとIterator / IntoIteratorの目的で、さまざまな範囲タイプをすでに異なる方法で処理しています。 （IMO、これはstd疣贅ですが、範囲タイプが異なる方法で処理される少なくとも1つのインスタンスです。）さらに、誰かが排他的範囲を使用しようとした場合、エラーメッセージは理解しやすいでしょう（ 「特性境界std::ops::Range<f32>: Clamp<f32>が満たされていません」）。

• Outputを関連付けられたタイプにして、将来実装を追加するための柔軟性を最大限に高めましたが、これは必ずしも必要ではありません。

基本的に、このアプローチにより、トレイトの境界に関して必要なだけの柔軟性が得られます。 また、最小限の有用なClamp実装のセットから始めて、変更を壊すことなく後で実装を追加することもできます。

オプションの比較

「 .clamp()をINFINITY 」アプローチには、前述のようにかなりの欠点があります。

「既存の.clamp 」+ .clamp_min() + .clamp_max()アプローチには、次の欠点があります。

• これはより冗長です。たとえば、 input.clamp_min(0)ではなくinput.clamp(0..)です。
• 排他範囲はサポートしていません。
• 将来的に.clamp()実装を追加することはできません（さらにメソッドを追加しない限り）。 たとえば、 u32値をu8境界でクランプすることはサポートできません。これは、RFCディスカッションから要求された機能です。 その特定の例は.saturating_into()関数でより適切に処理される可能性がありますが、より多くのクランプ実装が役立つ他の例があるかもしれません。
• 片側クランプの場合、 .min() 、 .max() 、 .clamp_min() 、および.clamp_max()間で混乱する可能性があります。 （とクランプ.clamp_min()使用するのと同様である.max() 、そしてとクランプ.clamp_max()使用するのと同様である.min() 。）私たちは、主に命名することで、この問題を回避することができ片側クランプ操作.clamp_lower() .clamp_min() / .clamp_max()代わりに.clamp_lower() / .clamp_upper()または.clamp_to_start() / .clamp_to_end()さらに冗長（ input.clamp_lower(0)対input.clamp(0..) ）。

範囲引数アプローチには、次の欠点があります。

• 実装は、 .clamp_min() / .clamp_max()追加するよりも複雑です。
• 排他的範囲タイプにClampを実装しない、または実装できないと判断した場合、これは驚くべきことかもしれません。

「既存の.clamp 」+ .clamp_min() + .clamp_max()アプローチと範囲引数アプローチについては強い意見はありません。 これはトレードオフです。

@Xaeroxeまだ存在するかどうかわからないユースケースに対応するために、関数で発生する分岐の量を2倍にします。 これをベンチマークに表示させることはできません。

たぶん、余分なブランチはLLVMによって最適化されますか？

片側クランプについて

クランプは両側で包括的であるため、片側のみのクランプ動作を取得するには、左/右で最小/最大を指定するだけです。 それは完全に受け入れられ、とにかく適合するRange*タイプがない.clamp((Bound::Unbounded, Inclusive(3.2)))よりも間違いなく良いと思います。

x.clamp(i32::MIN, 10);
x.clamp(-f32::INFINITY, 10.0);

LLVMはデッドサイドを簡単に最適化できるため、パフォーマンスの低下はありません： https ：

範囲構文はかっこいいですが、 clampは十分に基本的であるため、2つの別々の引数で問題なく理解できます。

たぶんmin / max NaN処理は、たとえばf32の固有のメソッドの実装を変更することによって、それ自体で修正できますか？ またはPartialOrd::min/max専門にしますか？ （Rustがlibstdで物事を切り替える方法を見つけることができたと仮定すると、エディションフラグ付き）。

@scottmcmRangeToInclusiveをチェックする必要があります。

これをもう少し考えた後、安定は永遠であることに気づきました。したがって、「RFCプロセスのリセット」を変更しない理由と見なすべきではありません。

そのために、これを実装したときの考え方に戻りたいと思います。 クランプは概念的に範囲全体で動作するため、範囲を表現するためにRustがすでに用意している語彙を使用することは理にかなっています。 それは私のひざのけいれん反応でした、そしてそれは他の多くの人々にとっての反応のようです。 それでは、このようにしないことについての議論を繰り返し、それらに反論できるかどうかを見てみましょう。

• 必要な範囲の選択は、新しい特性を必要とするほど斬新であり、特に最も一般的な範囲であるRange除外します。

  • @ jturner314によって提供される新しい実装を使用して、排他範囲の値を正しく返すために、 Ord + Stepなどの特定のRange*タイプにさらに制限を追加できるようになりました。 したがって、排他的な範囲クランプは実際には必要ないことがよくありますが、これらの技術的制限がない範囲のインターフェイスを損なうことなく、ここで範囲の全範囲を実際に受け入れることができます。

• 片側クランプには、Infinity / Min / Maxを使用できます。

  • それは真実であり、この変更が私の意見では本当に強力な義務ではない理由の大部分です。 これに対する答えは1つしかありません。つまり、 Range*構文では、このユースケースの文字数とインポート数が少なくなります。

これを行わない理由に反論したので、オプションは同等に見えるため、このコメントには変更を加える動機がありません。 変更を加える動機を見つけましょう。 私には1つの理由しかありません。それは、このスレッドの一般的な意見は、範囲ベースのアプローチが言語のセマンティクスを改善するということであるように思われるということです。 包括的ダブルエンドレンジクランプだけでなく、 .min()や.max()などの機能にも使用できます。

この考え方が、RFCをそのまま安定させることに賛成している他の人々と何らかの牽引力を持っているかどうか私は興味があります。

Clampは他の言語と非常に似ているため、現在の形式のままにしておく方がよいと思います。
プルリクエスト＃58710に取り組んだとき、範囲ベースの実装を使用しようとしました。
しかし、 rust-lang / rfcs＃1961（コメント） ）は、標準形式の方が優れていると私に確信させました。

さびの数値がどのように機能するかに慣れていない人々を混乱させないために、関数に#[must_use]属性を設定することは論理的だと思います。 つまり、誰かが次の（誤った）コードを書いていることが簡単にわかります。

let mut x: f64 = some_number_source();
x.clamp(0.0, 1.0);
//Proceeds to assume that 0.0 <= x <= 1.0

一般に、rustは数値に対して(number).method()アプローチを取ります（他の言語はMath.Method(number)使用します）が、これを念頭に置いたとしても、これがnumber変更する可能性があることは論理的な仮定です。

[must_use]属性が最近追加され
@ Xaeroxe範囲ベースのクランプ用の何かを思いついたのですか？
今の機能は他のさびの数値関数に一番合うと思いますので、また安定させたいと思います。

現時点では、レンジベースのクランプを使用する理由はありません。 はい、must_use属性を追加して、安定化に取り組みましょう。

@SimonSapin @scottmcm安定化プロセスを再開できますか？

@ jturner314が言ったように、Ordの代わりにPartialOrdにクランプを設定すると、フロートにも使用できるので便利です。

この号には、すでに専門のf32::clampとf64::clampがあります。

これが私がやろうとしていることです：

use num_traits::float::FloatCore;

struct Foo<T> (T);

impl<T: FloatCore> Foo<T> {
    fn foo(&self) -> T {
        self.0.clamp(1, 10)
    }
}

fn main() {
    let foo = Foo(15.3);
    println!("{}", foo.foo())
}

遊び場へのリンク。

PartialOrdはフロートのみの特性ではありません。 float固有のメソッドを使用しても、カスタムPartialOrdタイプでクランプを使用できるようにはなりません。

現在の実装では、使用していなくてもEqが必要です。

PartialOrdの主な懸念は、保証が弱くなり、クランプの保証が弱くなることでした。 これをPartialOrdたいユーザーは、私が書いた別の関数に興味があるかもしれませんhttps://docs.rs/num/0.2.1/num/fn.clamp.html

これらの保証は何ですか？

かなり自然な期待があることIFF x.clamp(a, b) == xその後、 a <= x && x <= b 。 これはPartialCmpでは保証されません。 xはaまたはbと比較できない場合があります。

漠然と覚えているclamp()を探して今日ここに来て、興味を持って議論を読んだ。

任意の範囲を許可することと、いくつかの名前付き関数を使用することの間の妥協案として、「オプショントリック」を使用することをお勧めします。 これは一部の人には人気がないことは知っていますが、ここでは目的のセマンティクスをうまく捉えているようです。

#![allow(unstable_name_collisions)]

pub trait Clamp: Sized {
    fn clamp<L, U>(self, lower: L, upper: U) -> Self
    where
        L: Into<Option<Self>>,
        U: Into<Option<Self>>;
}

impl Clamp for f32 {
    fn clamp<L, U>(self, lower: L, upper: U) -> Self
    where
        L: Into<Option<Self>>,
        U: Into<Option<Self>>,
    {
        let below = match lower.into() {
            None => self,
            Some(lower) => self.max(lower),
        };
        match upper.into() {
            None => below,
            Some(upper) => below.min(upper),
        }
    }
}

#[test]
fn test_clamp() {
    assert_eq!(1.0, f32::clamp(2.0, -1.0, 1.0));
    assert_eq!(-1.0, f32::clamp(-2.0, -1.0, 1.0));
    assert_eq!(1.0, f32::clamp(2.0, None, 1.0));
    assert_eq!(-1.0, f32::clamp(-2.0, -1.0, None));
    assert_eq!(2.0, f32::clamp(2.0, -1.0, None));
    assert_eq!(-2.0, f32::clamp(-2.0, None, 1.0));
}

これがstd含まれている場合、包括的実装もT: Ordに含めることができます。これは、一般的なPartialOrd実装に関して提起された懸念をカバーします。

ユーザーコードでclamp()関数を定義すると、現在、デフォルトで不安定な名前の衝突に関するコンパイラ警告が生成されることを考えると、この関数には「クランプ」という名前で問題ないと思います。

clamp(a,b,c)はmin(max(a,b), c)と同じように動作するはずだと思います。
以来maxとminために実装されていませんPartialOrdでもないはずですclamp 。
NaN問題についてはすでに

@EdorianDark同意します。 min、maxもPartialOrdのみを必要とします。

@noonien minとmaxはRust 1.0以降で定義されており、 Ordが必要で、 f32とf64定義があります。
これは、これらの機能について議論するのに適切な場所ではありません。
ここでは、 min 、 max 、およびclampが同等に動作し、驚くことではないことに注意する必要があります。
編集： PartialOrdの状況は気に入らず、 float Ord実装してもらいたいのですが、1.0以降は変更できません。

これは統合され、約1年半の間不安定になっています。 これを安定させることについてどう思いますか？

これを安定させたいです！

clampメソッド名の競合が問題のように思われる場合は、 https： //github.com/rust-lang/rust/pull/66852#issuecomment-561667812のある時点で名前解決を変更することをお勧めし

@Xaeroxeプロセスは、安定化PRを提出し、それについてlibsチームのコンセンサスを求めることだと思います。 t-libsが過負荷になっていて、fcped以外のものに追いついていないようです。

さて、それはhttps://github.com/rust-lang/rust/pull/77872でしたか

@matkladは、実際にはFCPの提案が昨年https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395ですでに開始されてい

その場合、問題について年に1回程度pingを実行することはかなり許容できると思います。

@キムンディ
@sfackler
@withoutboats

https://github.com/rust-lang/rust/issues/44095#issuecomment-544393395はまだあなたの注意を待っています

FCPが開始されてから、libsチームはかなり変化しました。 安定化PRで新しいFCPを開始することについて、皆さんはどう思いますか？ ここで残りのチェックボックスを待つよりも長くはかからないように感じます。

@LukasKalbertodt元気です、キックオフしてもよろしいですか？

FCPが安定化PRで発生したため、ここでFCPをキャンセルします： //github.com/rust-lang/rust/pull/77872#issuecomment -722982535

@fcpbotキャンセル

ええと

@rfcbotキャンセル

@ m-ou-seの提案はキャンセルされました。