Rust: 클램프 RFC에 대한 추적 문제

참고: 이것은 서보와 패스파인더를 망가뜨렸습니다.

cc @rust-lang/libs, 이것은 min / max 와 유사한 경우입니다. 여기서 생태계는 이미 clamp 이름을 사용하고 있으므로 추가하면 모호함이 발생합니다. . 이것은 semver 정책에 따라 허용되는 파손이지만 그럼에도 불구하고 다운스트림 통증을 유발합니다.

화요일 분류 회의를 위해 지명합니다.

그동안 어떤 생각이 드셨나요?

나는 이것을 반복하지 않는 것이 좋다는 점 에서

restrict
clamp_to_range
min_max (최소와 최대를 결합하는 것과 같기 때문입니다.)
이것들은 효과가 있을 수 있습니다. clamp 의 영향이 실제로 얼마나 나쁜지 결정하기 위해 분화구를 사용할 수 있습니까? clamp 는 여러 언어와 라이브러리에서 잘 인식됩니다.

이름을 바꿀 필요가 있다고 생각되면 즉시 PR을 되돌린 다음 분화구 등을 사용하여 더 신중하게 테스트하는 것이 가장 좋습니다. @Xaeroxe ,

확신하는. 나는 전에 분화구를 사용한 적이 없지만 배울 수 있습니다.

@Xaeroxe 아 죄송합니다. 빨리 되돌리기 PR을 받고 중이므로 @BurntSushi 또는 @alexcrichton 과 같은 라이브러리에 다른 사람이 필요할 수 있습니다.)

지금 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를 요구한다고 가정합니다.

지금 6개월 동안 std 라이브러리에 4줄 기능을 추가하는 작업을 해왔습니다. 난 좀 지쳤어. 동일한 기능이 2일 만에 num 에 병합되었으며 나에게 충분합니다. 다른 사람이 std 라이브러리에서 이것을 정말로 원하면 계속 진행하십시오. 그러나 나는 이것의 또 다른 6개월을 위한 준비가 되지 않았습니다.

@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로 무시될 수 있는지 재고해야 할 수도 있습니다.

   현재 유형 추론 변경은 항상 UFCS 또는 다른 방법을 사용하여 유형을 강제할 수 있으므로 RFC 1105 및 1122에서 허용되는 것으로 간주됩니다. 그러나 커뮤니티 는 #42496( Ord::{min, max} )으로 인한 파손을 별로 좋아하지 않습니다 . 또한 #41336( T += &T 의 첫 번째 시도)은 8가지 유형의 추론 회귀로 인해 "단지" 닫혔습니다.

2. 메서드를 추가할 때마다 이름이 이미 존재하지 않는지 확인하기 위해 분화구가 있어야 합니다.

   고유 메소드를 추가하면 추론 실패도 발생할 수 있습니다. — #41793은 다운스트림 트레잇의 ieee754::Ieee754::from_bits 메소드와 충돌하는 고유 메소드 {f32, f64}::from_bits 추가로 인해 발생했습니다.

3. 다운스트림 크레이트가 #![feature(clamp)] 지정하지 않은 경우 후보 Ord::clamp 는 이것이 고유한 솔루션이 아닌 한 고려되어서는 안 됩니다(미래와 호환되는 경고가 계속 발행될 수 있음). 이렇게 하면 "insta-breaking"이 아닌 새로운 특성 방법을 도입할 수 있지만 안정화되면 문제가 다시 발생합니다.

사람들이 확장 특성을 정의하기에 충분하기를 원하는 메소드가 표준 라이브러리에 추가될 수 없다면 우리는 매우 나쁜 위치에 있는 것 같습니다.

최대/최소는 공통 특성에 공통 메소드 이름을 사용하는 것과 관련하여 특히 나쁜 점에 도달했습니다. 클램프에도 동일하게 적용할 필요가 없습니다.

나는 여전히 그렇다고 말하고 싶지만 @sfackler 우리는 정말 일반적으로 다양한 유형으로 구현되는

전문화가 오면 확장 특성에 확장 메서드를 넣어도 아무 것도 잃지 않습니다.

한 가지 성가신 부분은 새로운 std 메서드가 코드를 깨뜨리면 불안정하기 때문에 실제로 사용할 수 있기 훨씬 전에 나타날 것입니다. 그 외에는 같은 의미의 메소드와의 충돌이라면 나쁘지 않습니다.

파손을 피하기 위해 이 함수에 다른 이름을 지정하는 것은 나쁜 해결책이라고 생각합니다. 작동하는 동안 이 기능을 사용하는 모든 코드의 향후 가독성을 최적화하는 대신 몇 개의 크레이트(모두 야간에 선택)를 깨지 않도록 최적화하고 있습니다.

몇 가지 걱정거리가 있는데 몇 가지는 걱정할 필요가 없습니다.

• 이름과 그림자는 이상적이지 않지만 작동합니다.
• 수치 벡터 및 행렬의 경우 최대/최소/클램프가 이상적이지 않다고 생각하지만 Ord를 전혀 사용하지 않으면 해결됩니다. Ndarray는 요소별 및 일반 인수(스칼라 또는 배열) 클램프를 수행하고 싶지만 Ord는 당사 또는 유사한 라이브러리에서 사용되지 않습니다. 걱정하지 마세요.
• 숫자가 아닌 기존 복합 유형: BtreeMap은 이 변경으로 메소드 클램프를 얻습니다. 일반적으로 말이 되나요? 기본값과 별도로 합리적인 의미를 구현할 수 있습니까?
• 값으로 모드를 호출하는 것은 모든 구현에 적합하지 않습니다. 다시, BtreeMap. 클램프가 3개의 맵을 소비하고 그 중 하나를 반환해야 합니까?

복합 유형

BtreeSet<BtreeSet<impl Ord>>::range 만큼 의미가 있다고 생각합니다. 그러나 Vec<char> 와 같이 도움이 될 수도 있는 특정 경우가 있습니다.

값에 의한 호출 모드

이것이 RFC에 나왔을 때 대답은 그냥 use 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 는 뒤집기와 같은 다른 가능성도 열어줍니다.

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 .

그래도 꾸준함이 좋습니다.

@egilburg Rust는 직접 오버로딩을 지원하지 않습니다. 옵션 2가 귀하의 제안과 함께 작동하려면 RangeInclusive , RangeToInclusive 및 RangeFrom 대해 구현된 새로운 특성이 필요하며, 이는 상당히 무거운 느낌입니다.

저는 3번이 가장 좋은 선택이라고 생각합니다.

1 또는 2가 가장 덜 놀랍습니다. 많은 코드가 로컬 구현을 표준 구현으로 대체하기 위해 할 일이 적기 때문에 1을 유지합니다.

나는 우리가 _all_ range* 유형을 사용하거나 _none_ 그 중 하나를 사용하도록 계획해야 한다고 생각합니다.

같은 것들에 대한 더 어렵 물론,의 Range 보다 RangeInclusive . 하지만 (0.0..1.0).clamp(2.0_f32) => 0.99999994_f32 대해 좋은 점이 있습니다.

@kennytm 그래서 옵션 3으로 풀 리퀘스트를 열면 병합될 것
또는 앞으로 어떻게 진행해야 한다고 생각하십니까?

@EdorianDark 이를 위해 @rust-lang/libs에 문의해야 합니다 😃

저는 개인적으로 RangeInclusive 만 있는 옵션 2를 좋아합니다. 언급한 바와 같이 min 및 max "부분 클램핑"이 이미 존재합니다.

나는 @SimonSapin에 동의하지만 옵션 1도 괜찮을 것입니다. 옵션 3을 사용하면 거꾸로 보이기 때문에 기능을 사용하지 않을 것입니다. @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.)
}

하나의 명령어를 덜 사용합니다.

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

이것이 클램프 구현에 내재된 것입니까, 아니면 LLVM 최적화의 기이한 것입니까?

@kornelski clamp NAN 를 사용하면 NAN 을 보존해야 하며 max / min 때문에 max maxmined 는 보존하지 않습니다 min 는 _non_- NAN 보존합니다.

NAN 기대치를 충족하고 더 짧은 구현을 찾는 것이 좋습니다. 그리고 doctest가 NAN 처리를 보여주는 것이 좋을 것입니다. 원래 PR에 다음과 같은 내용이 있었던 것 같습니다.

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

@scottmcm https://github.com/rust-lang/rust/pull/59327 완료

min 또는 max가 NaN인 경우 클램핑이 패닉을 일으키는 이유는 무엇입니까? 나는 어설션을 assert!(min <= max) 에서 assert!(!(min > max)) 로 변경하여 최대 및 최소 방법과 마찬가지로 NaN 최소값 또는 최대값이 영향을 미치지 않도록 합니다.

클램프의 min 또는 max 에 대한 NAN은 프로그래밍 오류를 나타내는 것일 수 있으며, 클램프되지 않은 데이터를 IO에 제공하는 것보다 더 빨리 패닉에 빠지는 것이 낫다고 생각했습니다. 상한 또는 하한을 원하지 않는다면 이 기능은 적합하지 않습니다.

상한 또는 하한을 원하지 않으면 항상 INF 및 -INF를 사용할 수 있습니다. NaN과 달리 수학적으로도 의미가 있습니다. 그러나 대부분의 경우 max 및 min 를 사용하는 것이 좋습니다.

@Xaerox 구현해주셔서 감사합니다.

이것이 안정적인 코드를 깨뜨릴 경우 다음 버전에 적용될 수 있습니까?

IMO가 더 자세히 고려할 가치가 있는 한 가지는 f32 / f64 일방적 클램핑입니다. 토론은 이 주제에 대해 간략하게 다룬 것 같지만 실제로는 자세히 고려하지 않았습니다.

대부분의 경우 단측 클램프에 대한 입력이 NAN이면 결과가 클램핑 경계가 되는 것보다 결과가 NAN인 것이 더 유용합니다. 따라서 기존 f32::min 및 f64::max 함수는 이 사용 사례에서 제대로 작동하지 않습니다. 편측 클램핑을 위한 별도의 기능이 필요합니다. (rust-num/num-traits#122 참조)

내가 이것을 제기하는 이유는 양면 클램프와 단면 클램프가 일관된 인터페이스를 갖는 것이 좋을 것이기 때문에 양면 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을 선택해야 하며, 이는 완벽하게 합리적이라고 생각합니다. 또는 IMO가 너무 장황한 옵션 3입니다. 우리는 희생이 별도의 clamp_min 및 clamp_max 함수를 추가하거나 사용자가 양수/음수 무한대를 작성하도록 요구한다는 것을 알고 있어야 합니다.

제공할 수 있다는 점도 주목할 가치가 있습니다.

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

// and for f64

f32 / f64 경우 일반 Ord 와 달리 배타적 범위를 처리하는 방법을 실제로 알고 있기 때문입니다. 물론 일관성을 위해 RangeInclusive 인수를 사용하도록 Ord::clamp 를 변경하고 싶을 것입니다. Ord::clamp 대해 두 개의 인수 또는 단일 RangeInclusive 인수를 선호할지 여부에 대해 어느 쪽이든 강력한 의견이 없었던 것 같습니다.

이 문제가 이미 해결된 경우 언제든지 내 의견을 무시하십시오. 나는 이전 토론에서 그것들을 보지 못했기 때문에 이러한 것들을 꺼내고 싶었습니다.

분류: 아래 API는 현재 불안정하며 여기를 가리킵니다. NaN 처리 외에 고려해야 할 문제가 있습니까? NaN 처리에서 차단하지 않고 먼저 Ord::clamp 안정화할 가치가 있습니까?

```녹
펍 특성 Ord: Eq + PartialOrd{
// …
fn clamp(self, min: Self, max: Self) -> Self where Self: Size {…}
}
impl f32 {
pub fn clamp(self, min: f32, max: f32) -> f32 {…}
}
impl f64 {
pub fn clamp(self, min: f64, max: f64) -> f64 {…}
}

@SimonSapin 개인적으로 모든 것을 안정화시켜 기쁩니다.

+1, 이것은 전체 RFC를 거쳤으며 그 이후로 나온 자료가 없다고 생각합니다. 예를 들어 NaN 처리는 IRLO 및 RFC 토론 에서 자세히 설명 되었습니다 .

좋아, 충분히 공평하게 들린다.

@rfcbot fcp 병합

팀원 @SimonSapin 이 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀원이 검토하는 것입니다.

• [x] @아마니유
• [ ] @키문디
• [x] @SimonSapin
• [x] @alexcrichton
• [x] @dtolnay
• [ ] @sfackler
• [ ] @보트 없이

현재 나열된 우려 사항이 없습니다.

과반수의 검토자가 승인하면(최대 2개의 승인이 남아 있음) 최종 의견 수렴 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

x.clamp(7..=13) vs 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#pullrequest리뷰 -207529970.

.min 및 .max .min(...) 를 사용하여 상한을 지정하고 .max(...) 를 사용하여 상한을 지정할 때 버그가 자주 발생하므로 이는 상당히 불행한 해결이라고 말하고 싶습니다. 하한. 이것은 믿을 수 없을 정도로 혼란스럽고 나는 이것으로 많은 버그를 보았습니다. .clamp(..1.0) 및 .clamp(0.0..) 가 훨씬 더 명확합니다.

@CryZe 는 매우 좋은 지적을 합니다. min = upper bound, max = lower bound 로 실수를 하지 않더라도 어떤 것을 사용해야 하는지 기억하기 위해 여전히 정신 체조를 해야 합니다. 이 인지 부하는 해결하려는 문제에 더 잘 사용됩니다.

x.clamp(y, z) 가 더 기대된다는 것을 알고 있지만 아마도 이것이 혁신의 기회일 것입니다 ;)

나는 초기 단계에서 범위를 꽤 많이 실험했고 포괄적인 범위를 실험할 수 있도록 RFC를 몇 개월 지연시키기까지 했습니다. (이것은 안정화되기 전에 시작되었습니다)

부동 소수점 숫자에 대한 독점 범위에 대한 클램프를 구현할 수 없다는 것을 발견했습니다. 일부 범위 유형만 지원하고 다른 유형은 지원하지 않는 것은 너무 놀라운 결과였습니다. 그래서 RFC를 이러한 방식으로 실험하기 위해 몇 달을 연기했지만 궁극적으로 범위가 솔루션이 아니라고 결정했습니다.

@m-ou-se #44095(댓글) 및 #58710(리뷰)에서 시작하는 토론을 참조하세요.

편집: 아래에서 지적한 바와 같이 풀 리퀘스트(#58710)의 논의에는 추적 문제보다 설계 결정에 대한 더 많은 논의가 포함되어 있습니다. 이것이 일반적으로 디자인 토론이 이루어지는 곳인 여기에서 전달되지 않은 것이 유감이지만 토론되었습니다.

일부 범위 유형만 지원하고 다른 유형은 지원하지 않는 결과가 너무 놀랍습니다.

Rust는 이미 일부 범위를 다른 범위와 다르게 취급하므로(예: 반복을 위해 사용) 일부 범위만 clamp 인수로 허용하는 것은 나에게 전혀 놀라운 일이 아닙니다.

가장 유용한 분석은 다음과 같습니다. https://github.com/rust-lang/rfcs/pull/1961#issuecomment -302600351

@Xaeroxe 일부 범위 유형만 지원하고 다른 유형은 지원하지 않는 결과가 너무 놀랍습니다.

안정화되기 전에 이것을 생각하고 있었다면 시간과 일반적인 사용으로 인해 의견이 바뀌었습니까? 아니면 여전히 그렇다고 생각하십니까?

나는 배타적 범위가 정수에 대해 다른 동작을 갖기 때문에 어쨌든 부동 소수점에 대해 구현되어서는 안된다고 주장합니다(범위 0..10 에는 하한이 포함되고 상한은 제외되므로 가상 범위 0.0...10.0 둘 다 제외?). 적어도 나에게는 놀라운 일이 아니라고 생각합니다.

@varkor 그러나 이것은 추적 문제에 대한 논의 없이 검토에서 단일 의견 후에 변경되었습니다.

이것은 지나치게 대립적인 것처럼 보일 수 있습니다. "대화를 살펴보았을 때 범위를 사용하지 말아야 하는 이유에 대한 설득력 있는 주장을 찾지 못했습니다. 누군가 저를 지적해 주실 수 있나요?"와 같이 시도해 보십시오.

나는 당신이 찾고있는 인수가 여기에 있다고 생각합니다 : https://github.com/rust-lang/rfcs/pull/1961#issuecomment -302600351

@Xaerox를 수정했습니다. :)

시간과 일반적인 사용법이 귀하의 의견을 바꾸었습니다

지금까지는 그렇지 않았지만 범위는 일상적인 코딩에서 거의 사용하지 않는 것입니다. 코드 예제와 부분 범위 지원이 포함된 기존 API를 통해 설득할 수 있습니다. 그러나 우리가 그 질문을 해결하더라도 scottmcm이 RFC 주석에서 해결해야 할 몇 가지 다른 우수한 점이 여전히 있습니다. 예를 들어, Step 는 Ord 만큼 많은 유형에서 구현되지 않습니다. 이 사소한 구문 변경이 해당 유형을 잃을 가치가 있습니까? 또한 비포함 범위 클램프에 대한 사용 사례가 있습니까? 내가 말할 수 있는 한, 다른 언어나 프레임워크는 배타적 범위 클램프를 지원할 필요를 느끼지 않았습니다. 그러면 우리가 얻을 수 있는 이점은 무엇입니까? 범위는 만족스러운 방식으로 구현하기가 훨씬 더 어려웠으며 많은 단점과 적은 이점이 있었습니다.

범위를 사용하여 이것을 구현 한다면 다음과 같이 보일 것입니다.

따라서 이 접근 방식을 사용해서는 안 된다고 생각하는 몇 가지 이유가 있습니다.

1. 필요한 범위 선택은 새로운 특성이 필요할 만큼 충분히 참신하며 특히 가장 일반적인 범위인 Range 제외합니다.

2. 우리는 이미 RFC 프로세스에서 여기까지 왔고 이것으로부터 표준이 얻는 유일한 것은 .max() 또는 .min() 를 작성하는 또 다른 방법입니다. 나는 우리가 이미 Rust에서 할 수 있는 것을 구현하기 위해 RFC를 프로세스의 시작 부분으로 되돌리고 싶지 않습니다.

3. 아직 존재하는지 확실하지 않은 사용 사례를 수용하기 위해 함수에서 발생하는 분기의 양을 두 배로 늘립니다. 이것을 벤치마크에 표시할 수 없습니다.

편측 클램핑 작업의 필요성

... 이것에서 표준이 얻는 유일한 것은 .max() 또는 .min() 를 쓰는 또 다른 방법입니다.

내가 말하려고 했던 주요 요점은 토론에서 .min() / .max() 과 일방적 클램프가 여러 번 나타나는 명백한 동등성을 보았지만 작업은 동일하지 않다는 것입니다. 부동 소수점 숫자의 경우 NAN 처리해야 합니다.

예를 들어 음수를 0으로 고정하는 표현식으로 input.max(0.) 를 고려하십시오. input 가 NAN 이 아닌 경우 제대로 작동합니다. 그러나 input 가 NAN 이면 0. 평가됩니다. 이것은 거의 원하는 동작이 아닙니다. 한쪽 클램핑은 NAN 값을 유지해야 합니다. ( 이 주석 및 이 주석을 참조하십시오.) 결론적으로 .max() 는 두 숫자 중 더 큰 숫자를 취하는 데는 잘 작동하지만 단측 클램핑에는 잘 작동하지 않습니다.

따라서 부동 소수점 숫자에 대해 단측 클램핑 작업( .min() / .max() 와 별도)이 필요합니다. 다른 사람들은 부동 소수점이 아닌 유형에 대한 단측 클램핑 작업의 유용성에 대해서도 좋은 주장 을 했습니다. 다음 질문은 이러한 작업을 표현하는 방법입니다.

편측 클램핑 작업을 표현하는 방법

.clamp() 와 INFINITY

즉, 일방적인 클램핑 작업을 추가하지 마십시오. 사용자에게 INFINITY 또는 NEG_INFINITY 경계와 함께 .clamp() 를 사용하도록 지시하세요. 예를 들어, 사용자에게 input.clamp(0., std::f64::INFINITY) 를 작성하도록 지시하십시오.

이것은 매우 장황하여 사용자가 NAN 처리의 뉘앙스를 알지 못하는 경우 잘못된 .min() / .max() 합니다. 또한 T: Ord 에는 도움이 되지 않으며 IMO는 대안보다 명확하지 않습니다.

.clamp_min() 및 .clamp_max()

한 가지 합리적인 옵션은 현재 제안된 구현을 변경할 필요가 없는 .clamp_min() 및 .clamp_max() 메서드를 추가하는 것입니다. 나는 이것이 합리적인 접근이라고 생각합니다. 현재 제안된 clamp 구현을 안정화하려면 이 접근 방식을 사용해야 한다는 사실을 알고 싶었습니다.

범위 인수

또 다른 옵션은 clamp 가 범위 인수를 사용하도록 하는 것입니다. @Xaeroxe 는 이것을 구현하는 한 가지 방법을 보여 주었지만 그가 언급한 것처럼 구현에는 몇 가지 단점이 있습니다. 구현을 작성하는 다른 방법은 현재 슬라이싱이 구현된 방식과 유사합니다( 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 인 배타적 범위에 대한 구현을 추가할 수 있습니다.
• 우리는 유지할 수있는 Clamp 특성 야간 전용의 유사 SliceIndex 특성.

• 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 의 사마귀지만 범위 유형이 다르게 처리되는 경우가 하나 이상 있습니다.) 또한 누군가가 단독 범위를 사용하려고 하면 오류 메시지를 이해하기 쉬울 것입니다( "특성 경계 std::ops::Range<f32>: Clamp<f32> 가 충족되지 않습니다.").

• 앞으로 더 많은 구현을 추가할 수 있도록 유연성을 최대화하기 위해 Output 관련 유형을 만들었지만 꼭 필요한 것은 아닙니다.

기본적으로 이 접근 방식은 특성 경계와 관련하여 원하는 만큼의 유연성을 제공합니다. 또한 최소한의 유용한 Clamp 구현 세트로 시작하여 변경 사항을 중단하지 않고 나중에 구현을 추가할 수 있습니다.

옵션 비교

"사용 .clamp() 와 INFINITY "위에서 언급 한 바와 같이 접근 방식은 상당한 단점이있다.

"기존 .clamp " + .clamp_min() + .clamp_max() 접근 방식에는 다음과 같은 단점이 있습니다.

• 더 장황합니다(예: input.clamp_min(0) 대신 input.clamp(0..) .
• 배타적 범위를 지원하지 않습니다.
• 우리는 앞으로 .clamp() 구현을 더 추가할 수 없습니다(아직 더 많은 메소드를 추가하지 않고). 예를 들어, 우리는 RFC 토론에서 요청된 기능인 u8 경계로 u32 값을 고정하는 것을 지원할 수 없습니다. 그 특정 예는 .saturating_into() 함수로 더 잘 처리될 수 있지만 더 많은 클램핑 구현이 유용한 다른 예가 있을 수 있습니다.
• 누군가는 편측 클램핑의 경우 .min() , .max() , .clamp_min() , .clamp_max() 사이에서 혼동될 수 있습니다. ( .clamp_min() 로 고정하는 것은 .max() 를 사용하는 것과 유사하고 .clamp_max() 것은 .min() 를 사용하는 것과 유사합니다.) 클램핑 동작을 일방적 .clamp_lower() / .clamp_upper() 또는 .clamp_to_start() / .clamp_to_end() 대신 .clamp_min() / .clamp_max() 그 비록 훨씬 더 장황합니다( input.clamp_lower(0) 대 input.clamp(0..) ).

범위 인수 접근 방식에는 다음과 같은 단점이 있습니다.

• 구현은 .clamp_min() / .clamp_max() 추가하는 것보다 더 복잡합니다.
• 배타적 범위 유형에 대해 Clamp 를 구현하지 않거나 구현하지 않기로 결정했다면 이는 놀라운 결과일 수 있습니다.

나는 "기존 .clamp " + .clamp_min() + .clamp_max() 접근 방식과 범위 인수 접근 방식에 대해 강한 의견이 없습니다. 절충안입니다.

@Xaeroxe 아직 확실하지 않은 사용 사례를 수용하기 위해 함수에서 발생하는 분기의 양을 두 배로 늘립니다. 이것을 벤치마크에 표시할 수 없습니다.

추가 분기가 LLVM에 의해 최적화될 수 있습니까?

한쪽 클램핑 시

클램핑은 양쪽 모두를 포함하기 때문에 왼쪽/오른쪽에 최소/최대를 지정하면 한쪽만 클램핑 동작을 얻을 수 있습니다. 나는 그것이 완벽하게 수용 가능하고 Range* 유형이 어쨌든 맞는 .clamp((Bound::Unbounded, Inclusive(3.2))) 보다 틀림없이 더 낫다고 생각합니다.

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

LLVM은 죽은 면을 최소화할 수 있으므로 성능 손실이 없습니다. https://rust.godbolt.org/z/l_uBLO

범위 구문은 멋지지만 clamp 는 기본적으로 두 개의 개별 인수가 훌륭하고 이해하기 쉽습니다.

min / max NaN 처리는 자체적으로 수정될 수 있습니다. 예를 들어 f32 의 고유한 메소드 구현을 변경하면 될까요? 또는 PartialOrd::min/max 전문화 ? (Rust가 libstd에서 항목을 토글하는 방법을 찾을 수 있다고 가정하면 에디션 플래그를 사용하여).

@scottmcm 당신은 체크 아웃해야 RangeToInclusive을 .

이것을 좀 더 생각한 후에 안정은 영원하다는 생각이 들었습니다. 그래서 우리는 "RFC 프로세스 재설정"을 변경하지 않는 이유로 간주해서는 안됩니다.

이를 위해 저는 이것을 구현할 때의 마인드로 돌아가고 싶습니다. Clamp는 개념적으로 범위에 대해 작동하므로 범위를 표현하기 위해 Rust가 이미 사용하고 있는 어휘를 사용하는 것이 좋습니다. 내 무릎 경련 반응이었고, 다른 많은 사람들의 반응인 것 같다. 그래서 이런 식으로 하지 않는 것에 대한 주장을 다시 반복하고 우리가 그것들을 논박할 수 있는지 봅시다.

• 필요한 범위 선택은 새로운 특성이 필요할 만큼 충분히 참신하며 특히 가장 일반적인 범위인 Range 제외합니다.

  • @jturner314에서 제공하는 새로운 구현을 사용하여 이제 배타적 범위에 대한 값을 올바르게 반환하기 위해 Ord + Step 와 같은 특정 Range* 유형에 대한 제한을 더 추가할 수 있습니다. 따라서 배타적 범위 클램프가 실제로 필요하지 않은 경우가 많지만 이러한 기술적 제한이 없는 범위의 인터페이스를 손상시키지 않으면서 여기에서 전체 범위를 실제로 수용할 수 있습니다.

• 단면 클램핑에 Infinity/Min/Max를 사용할 수 있습니다.

  • 그것은 사실이며, 내 생각에 이 변경이 실제로 강력한 권한이 아닌 이유의 큰 부분입니다. 나는 이것에 대한 단 하나의 대답을 얻었고, 그것은 Range* 구문이 이 사용 사례에 대해 더 적은 수의 문자와 더 적은 수의 가져오기를 포함한다는 것입니다.

이렇게 하지 않는 이유를 반박했으므로 이 의견에는 옵션이 동일해 보이기 때문에 변경하려는 동기가 전혀 없습니다. 변화의 동기를 찾아봅시다. 내가 가진 이유는 단 하나입니다. 이 스레드의 일반적인 의견은 범위 기반 접근 방식이 언어의 의미 체계를 개선한다는 것입니다. 포괄적인 이중 종료 범위 클램프뿐만 아니라 .min() 및 .max() 와 같은 함수에도 적용됩니다.

이 생각이 RFC를 있는 그대로 안정화하는 데 찬성하는 다른 사람들에게 어떤 견인력이 있는지 궁금합니다.

이제 다른 언어와 매우 유사하기 때문에 Clamp를 현재 형태로 두는 것이 더 좋을 것이라고 생각합니다.
pull request #58710 작업을 할 때 Range 기반 구현을 사용하려고 했습니다.
그러나 rust-lang/rfcs#1961 (comment) ) 표준 형식이 더 낫다고 확신했습니다.

Rust 숫자가 어떻게 작동하는지 익숙하지 않은 사람들을 혼동하지 않도록 함수에 #[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] 속성이 최근 에 추가
@ Xaerox 범위 기반 클램프에 대해 생각해 낸 것이 있습니까?
지금 이대로의 함수가 녹의 다른 수치함수에 가장 잘 맞는다고 생각하고 다시 안정화를 시작하고 싶습니다.

현재로서는 범위 기반 클램프를 사용할 이유가 없습니다. 예, 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 전용 특성이 아닙니다. float 전용 메서드를 사용하면 사용자 정의 PartialOrd 유형에 클램프를 사용할 수 없습니다.

현재 구현에는 Eq 가 필요하지만 사용하지 않습니다.

PartialOrd 의 주요 관심사는 더 약한 보증을 제공하여 클램프의 보증을 약화시킨다는 것입니다. 이것이 PartialOrd 에 있기를 원하는 사용자는 내가 작성한 다른 기능에 관심이 있을 수 있습니다. https://docs.rs/num/0.2.1/num/fn.clamp.html

이러한 보증은 무엇입니까?

상당히 자연스러운 기대는 iff x.clamp(a, b) == x then a <= x && x <= b 입니다. x 가 a 또는 b 와 비교할 수 없는 PartialCmp 에서는 보장되지 않습니다.

오늘은 어렴풋이 기억나는 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"라는 이름이 이 함수에 적합하다고 생각합니다.

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가 과부하되어 FC가 없는 것들을 따라잡을 수 없는 것 같습니다.

알겠습니다. https://github.com/rust-lang/rust/pull/77872

@matklad는 실제로 FCP 제안이 이미 작년에 https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395에서 시작되었지만 남은 확인란이 하나 있기 때문에 중단되었습니다.

그런 경우 1년에 한 번 정도 문제에 대해 핑을 받는 것은 꽤 견딜만하다고 생각합니다.

@키문디
@sfackler
@withoutboats

https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395가 여전히 여러분의 관심을 기다리고 있습니다.

libs 팀은 FCP가 시작된 이후로 꽤 많이 바뀌었습니다. 안정화 PR에서 새로운 FCP를 시작하는 것에 대해 모두 어떻게 생각하십니까? 여기에서 나머지 확인란을 기다리는 것보다 더 오래 걸리지 않아야 할 것 같습니다.

@LukasKalbertodd 괜찮습니다. 시작하시겠습니까?

FCP가 이제 안정화 PR에서 발생했기 때문에 여기에서 FCP를 취소합니다. https://github.com/rust-lang/rust/pull/77872#issuecomment -722982535

@fcpbot 취소

음

@rfcbot 취소

@m-ou-se 제안이 취소되었습니다.