Rust: Проблема отслеживания для зажима RFC

Обратите внимание: это сломало Servo и Pathfinder.

cc @ rust-lang / libs, это случай, аналогичный min / max , когда экосистема уже использовала имя clamp , и, следовательно, его добавление вызвало двусмысленность . Это разрешено в соответствии с политикой semver, но, тем не менее, вызывает боль ниже по потоку.

Выдвижение кандидатов на сортировочное собрание во вторник.

Есть какие-нибудь мысли тем временем?

Я как бы поддерживаю @bluss в этом

restrict
clamp_to_range
min_max (Потому что это похоже на объединение минимума и максимума.)
Это может сработать. Можем ли мы использовать кратер, чтобы определить, насколько сильно на самом деле удар clamp ? clamp хорошо распознается на нескольких языках и в библиотеках.

Если мы думаем, что нам может потребоваться переименование, вероятно, лучше немедленно вернуть PR, а затем более тщательно протестировать кратер и т. Д. @Xaeroxe , для этого?

Конечно. Раньше я никогда не использовал кратер, но могу научиться.

@Xaeroxe ах, извини, я имел в виду как можно скорее получить обратный PR. (Я сегодня в отпуске, поэтому вам может понадобиться кто-нибудь еще из библиотек , например @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 месяцев работаю над добавлением 4-строчной функции в библиотеку std. Я измучился. Та же функция была объединена в num за 2 дня, и для меня этого достаточно. Если кто-то еще действительно хочет этого в библиотеке 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 будет отменен, фактическое правило будет таким: «Вы в принципе не можете добавлять новые методы к чертам в std, за исключением, может быть, Iterator ».

Вы также не можете добавить новые методы к реальным типам. Рассмотрим ситуацию, когда у кого-то была «характеристика расширения» для типа в 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 все типы, которые используются в существующем трейте.

С приходом специализации мы ничего не теряем, помещая методы расширения в свойство extension.

Одна неприятная часть заключается в том, что если новый метод std нарушит ваш код: он появится задолго до того, как вы действительно сможете его использовать, поскольку он нестабилен. В остальном это не так уж плохо, если конфликт связан с методом, имеющим то же значение.

Я думаю, что дать этой функции другое имя, чтобы избежать поломки, - плохое решение. Несмотря на то, что он работает, он оптимизирует, не ломая несколько ящиков (все из которых выбирают ночной режим), вместо оптимизации для будущей читаемости любого кода, использующего эту функцию.

У меня есть несколько проблем, о которых я не беспокоюсь.

• имя и тень не идеальны, но работают
• для числовых векторов и матриц я думаю, что max / min / clamp не идеальны, но это решается, если вообще не использовать Ord. Ndarray хотел бы выполнять поэлементные и универсальные ограничения аргументов (скалярных или массивных), но Ord не используется нами или аналогичными библиотеками. Так что не беспокойтесь.
• Существующие составные типы, которые не являются числовыми: BtreeMap получит ограничение метода с этим изменением. Это вообще имеет смысл? Может ли он реализовать разумное значение для него помимо значения по умолчанию?
• режим вызова по значению подходит не для каждой реализации. Опять же, BtreeMap. Следует ли clip потреблять 3 карты и возвращать одну из них?

составные типы

Я думаю, что это имеет такой же смысл, как и 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, например, низкоприоритетные черты или использование расширений в более удобной манере. Однако мы не хотим блокировать это в подобных достижениях.

Произошел ли кратер для этого объекта?

Я планирую возродить метод clamp() после слияния # 48552. Тем не менее, 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 позволяет упростить частичный зажим. Вы можете использовать value.clamp(min..) или value.clamp(..=max) без необходимости использования специальных методов clamp_to_start или clamp_to_end .

@egilburg : у нас уже есть эти специальные методы: clamp_to_start is max и clamp_to_end is min : wink:

Хотя консистенция хороша.

@egilburg Rust не поддерживает прямую перегрузку. Чтобы вариант 2 работал с вашим предложением, нам понадобится новая черта, реализованная для RangeInclusive , RangeToInclusive и RangeFrom , которые кажутся довольно тяжелыми.

Я считаю, что вариант 3 - лучший вариант.

1 или 2 наименее удивительны. Я бы остановился на 1, так как большому количеству кода было бы меньше дел, чтобы заменить локальную реализацию на стандартную.

Я думаю, нам следует либо планировать использовать _все_ типы диапазона *, либо _не_ ни один из них.

Конечно, для таких вещей, как Range сложнее, чем для RangeInclusive . Но есть что-то приятное в (0.0..1.0).clamp(2.0_f32) => 0.99999994_f32 .

@kennytm Итак, если бы я открыл
Или что вы думаете о том, как действовать дальше?

@EdorianDark Для этого нам нужно спросить @ rust-lang / libs 😃

Мне лично нравится вариант 2, только с RangeInclusive . Как уже упоминалось, «частичное закрепление» уже существует с min и max .

Я согласен с @SimonSapin , хотя меня бы тоже @kennytm рассмотрел ранее , 5 из 7 (все, кроме Swift и Qt) сначала имеют значение, а затем диапазон.

Зажим снова в мастерской!

Я доволен, хотя все еще пытаюсь понять, что изменило, что сделало это приемлемым сейчас, тогда как его не было в # 44097

Теперь у нас есть период предупреждения из-за # 48552, вместо мгновенного прерывания вывода даже до стабилизации.

Отличные новости, спасибо!

@kennytm Я просто хочу поблагодарить вас за беготню, которую вы проделали, чтобы сделать # 48552, и @EdorianDark благодарит за ваш интерес к этому и за то, как он реализован. Приятно видеть, что это наконец слилось.

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 ing a NAN должен сохранять этот NAN , чего не делает maxmined , потому что max / min сохраняет _non_- NAN .

Было бы здорово найти реализацию, которая соответствует ожиданиям NAN и короче. И было бы хорошо, если бы в документах была продемонстрирована обработка 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 не имели никакого эффекта, как в методах max и min.

NAN для min или max в зажиме, вероятно, указывает на ошибку программирования, и мы решили, что лучше паниковать раньше, чем, возможно, передавать незафиксированные данные в IO. Если вам не нужна верхняя или нижняя граница, эта функция не для вас.

Вы всегда можете использовать INF и -INF, если вам не нужна верхняя или нижняя граница, верно? Что также имеет математический смысл, в отличие от NaN. Но в большинстве случаев для этого лучше использовать max и min .

@Xaeroxe Спасибо за реализацию.

Может быть, это можно будет сделать в следующей редакции, если это нарушит стабильный код?

Одна вещь, которую ИМО стоит рассмотреть более подробно, - это одностороннее закрепление 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, который я считаю вполне разумным. , или вариант 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 для согласованности. Похоже, что в любом случае не было твердого мнения о том, предпочитать ли два аргумента или один аргумент RangeInclusive для Ord::clamp .

Если это уже решенный вопрос, не стесняйтесь отклонить мой комментарий. Я просто хотел поднять эти вещи, потому что не видел их в предыдущем обсуждении.

Сортировка: приведенные ниже API в настоящее время нестабильны и указывают сюда. Есть ли вопросы, которые следует учитывать, кроме обработки NaN? Стоит ли сначала стабилизировать Ord::clamp не блокируя его при обработке NaN?

ржавчина
pub trait Ord: Eq + PartialOrd{
//…
fn clamp (self, min: Self, max: Self) -> Self, где Self: размер {…}
}
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] @Amanieu
• [] @Kimundi
• [x] @SimonSapin
• [x] @alexcrichton
• [x] @dtolnay
• [] @sfackler
• [] @withoutboats

В настоящее время не перечислено никаких проблем.

После того, как большинство рецензентов одобрит (и не более двух утверждений остаются нерешенными), наступит последний период для комментариев. Если вы заметили серьезную проблему, которая не поднималась ни на одном этапе этого процесса, сообщите об этом!

См. Этот документ для получения информации о том, какие команды могут дать мне члены команды, отмеченные тегами.

Было ли принято решение относительно 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, а также https://github.com/rust-lang/rust/pull/ 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://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

РЕДАКТИРОВАТЬ @Xaeroxe победить меня :)

время и общее использование изменили ваше мнение

Пока что нет, но диапазоны - это то, что я довольно редко использую в своем ежедневном кодировании. Я открыт для того, чтобы меня убедили примеры кода и существующие API с поддержкой частичного диапазона. Однако, даже если мы решим этот вопрос, есть еще несколько замечательных моментов, которые scottmcm поднимает в комментарии RFC, которые необходимо рассмотреть. Например, Step не реализован для такого количества типов, как Ord , стоит ли это незначительное синтаксическое изменение потерять эти типы? Кроме того, есть ли вариант использования ограничителей диапазона? Насколько я могу судить, ни один другой язык или фреймворк не чувствовал необходимости поддерживать ограничение исключительного диапазона, так какая же польза от этого мы получаем? Диапазоны было гораздо труднее реализовать удовлетворительным образом, и они имели множество недостатков и мало преимуществ.

Если бы я реализовал это с помощью диапазонов, это выглядело бы так.

Так что есть несколько причин, по которым, я думаю, нам не следует придерживаться этого подхода.

1. Выбор необходимых диапазонов достаточно нов, чтобы потребовать нового признака и, в частности, исключает наиболее распространенный диапазон, Range .

2. Мы уже так далеко продвинулись в процессе RFC, и единственное, что от этого получает std, - это еще один способ записи .max() или .min() . Я действительно не хочу откладывать RFC в начало процесса, чтобы реализовать то, что мы уже можем сделать в Rust.

3. Он удваивает количество ветвлений, происходящих в функции, чтобы учесть вариант использования, в существовании которого мы еще не уверены. Я не могу показать это в тестах.

Необходимость односторонних зажимных операций

... единственное, что от этого получает std, - это еще один способ написать .max() или .min() .

Основная мысль, которую я пытался сделать, заключается в том, что я видел эту очевидную эквивалентность между .min() / .max() и односторонними зажимами, которые неоднократно возникали в обсуждении, но операции не эквивалентны для чисел с плавающей запятой так, как они должны обрабатывать NAN .

Например, рассмотрите input.max(0.) как выражение для ограничения отрицательных чисел до нуля. Если input отличен от NAN , он работает нормально. Однако, когда input равно NAN , он оценивается как 0. . Это почти никогда не бывает желаемым поведением; односторонний зажим должен сохранять значения NAN . (См. Этот комментарий и этот комментарий .) В заключение, .max() хорошо подходит для взятия большего из двух чисел, но не подходит для одностороннего зажима.

Итак, нам нужны односторонние операции зажима (отдельно от .min() / .max() ) для чисел с плавающей запятой. Другие приводили веские аргументы в пользу полезности односторонних операций ограничения и для типов, не являющихся числами с плавающей запятой. Следующий вопрос - как мы хотим выразить эти операции.

Как выразить односторонние операции зажима

.clamp() с INFINITY

Другими словами, не добавляйте операцию одностороннего зажима; просто скажите пользователям использовать .clamp() с границами INFINITY или NEG_INFINITY . Например, попросите пользователей написать input.clamp(0., std::f64::INFINITY) .

Это очень подробный текст, который заставит пользователей использовать неправильный .min() / .max() если они не знают нюансов обработки NAN . Кроме того, это не помогает для T: Ord , и ИМО это менее понятно, чем альтернативы.

.clamp_min() и .clamp_max()

Один из разумных вариантов - добавить методы .clamp_min() и .clamp_max() , которые не потребуют каких-либо изменений в предлагаемой на данный момент реализации. Я считаю, что это разумный подход; Я просто хотел убедиться, что мы знали, что нам придется использовать этот подход, если мы стабилизируем предлагаемую в настоящее время реализацию clamp .

Аргумент диапазона

Другой вариант - заставить clamp принимать аргумент диапазона. @Xaeroxe показал один способ реализовать это, но, как он упомянул, эта реализация имеет несколько недостатков. Альтернативный способ написания реализации аналогичен текущему способу нарезки (признак SliceIndex ). Это снимает все возражения, которые я видел в обсуждении, за исключением озабоченности по поводу предоставления реализаций для подмножества типов диапазонов и дополнительной сложности. Я согласен, что это добавляет некоторую сложность, но ИМО это не намного хуже, чем добавление .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)
    }
  }
  

• При желании мы могли бы реализовать Clamp для эксклюзивных диапазонов с f32 / f64 позже. ( @scottmcm прокомментировал, что это std намеренно не имеет операций-предшественников f32 / f64 . Я не уверен, почему std не имеет этих операций; может быть, проблемы с ненормальными числами? Тем не менее, это можно было бы решить позже.)

  Даже если мы не добавим реализации Clamp для эксклюзивных диапазонов с f32 / f64 , я не согласен, что это было бы слишком удивительно. Как указывает @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() в будущем (без добавления дополнительных методов). Например, мы не можем поддерживать ограничение значения u32 u8 границами запрошенной функцией из обсуждения RFC . Этот конкретный пример может быть лучше обработан с помощью функции .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 будет оптимизировать дополнительную ветку?

На одностороннем зажиме

Поскольку зажим осуществляется с обеих сторон, можно просто указать минимальное / максимальное значение слева / справа, чтобы получить режим одностороннего зажима. Я думаю, что это вполне приемлемо и, возможно, лучше, чем .clamp((Bound::Unbounded, Inclusive(3.2))) где нет подходящего типа Range* :

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, теперь у нас есть возможность добавить больше ограничений для определенных типов Range* , таких как Ord + Step , чтобы правильно возвращать значения для эксклюзивных диапазонов. Таким образом, даже несмотря на то, что исключительный ограничитель диапазона часто действительно не нужен, мы фактически можем принять здесь весь диапазон диапазонов без ущерба для интерфейса диапазонов, которые не имеют этих технических ограничений.

• Мы можем просто использовать Infinity / Min / Max для одностороннего зажима.

  • Это правда, и большая часть того, почему это изменение, на мой взгляд, не является серьезным требованием. На самом деле у меня есть только один ответ на этот вопрос: синтаксис Range* включает в себя меньше символов и меньше импорта для этого варианта использования.

Теперь, когда мы опровергли причины не делать этого, в этом комментарии отсутствует какая-либо мотивация для внесения изменений, поскольку варианты кажутся эквивалентными. Давайте найдем мотивацию для внесения изменений. У меня есть только одна причина: общее мнение в этом потоке, похоже, состоит в том, что подход, основанный на диапазоне, улучшает семантику языка. Не только для включающего двустороннего ограничения диапазона, но и для таких функций, как .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 , было бы здорово иметь фиксатор PartialOrd вместо Ord, чтобы его также можно было использовать с плавающими точками.

У нас уже есть специальные 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

Что это за гарантии?

Довольно естественным ожиданием является то, что если и только если 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.

Это слитно и нестабильно вот уже около полутора лет. Как мы относимся к стабилизации этого положения?

Я бы хотел это стабилизировать!

Если конфликт имен методов 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, но оно застряло, потому что остался один флажок.

В таком случае, я думаю, что примерно раз в год получать пинг по какой-либо проблеме довольно терпимо.

@Kimundi
@sfackler
@withoutboats

https://github.com/rust-lang/rust/issues/44095#issuecomment -544393395 все еще ждет вашего внимания

Команда libs немного изменилась с момента запуска FCP. Что вы все думаете о создании нового FCP в стабилизационном PR? Похоже, это не займет больше времени, чем дождаться оставшихся флажков здесь.

@LukasKalbertodt меня устраивает, не возражаешь?

Отмена FCP здесь, потому что этот FCP теперь произошел на PR стабилизации: https://github.com/rust-lang/rust/pull/77872#issuecomment -722982535

@fcpbot отменить

Эм-м-м

@rfcbot отменить

Предложение @ m-ou-se отменено.