Rust: Проблема отслеживания специализации (RFC 1210)

Некоторые дополнительные открытые вопросы:

• Следует ли нам пересмотреть правила для сирот в свете специализации? Есть ли способы сделать вещи более гибкими?
• Должны ли мы расширить «цепное правило» в RFC на что-то более выразительное, например, так называемое «правило решетки»?
• В связи с обоими вышеперечисленными, как негативные доводы вписываются в историю? Можем ли мы восстановить нужные нам негативные рассуждения с помощью достаточно умного использования правил специализации / сиротства или должны сделать их более первоклассными?

Я не уверен, что специализация меняет правила сиротства:

• «Связывающие» сиротские правила должны оставаться неизменными, потому что в противном случае у вас не будет безопасного связывания.
• Я не думаю, что правила сиротской «совместимости в будущем» должны измениться. Добавление неспециализированного имплантата под вас все равно будет серьезным изменением.

Хуже того, сиротские правила "будущей совместимости" держат межкрейтную специализацию под довольно жестким контролем. Без них default-impls, оставляя свои методы открытыми, становится намного хуже.

Мне никогда не нравились явные отрицательные аргументы. Я думаю, что специализация на тотальную отрицательную аргументацию является хорошим компромиссом.

Следует ли допустить это при внедрении специализации? Или я что-то упускаю?
http://is.gd/3Ul0pe

То же самое с этим, можно было бы ожидать, что он скомпилируется: http://is.gd/RyFIEl

Похоже, есть некоторые причуды в определении перекрытия, когда задействованы связанные типы. Это компилирует: http://is.gd/JBPzIX , в то время как этот фактически идентичный код не компилируется: http://is.gd/0ksLPX

Вот фрагмент кода, который я ожидал скомпилировать со специализацией:

http://is.gd/3BNbfK

#![feature(specialization)]

use std::str::FromStr;

struct Error;

trait Simple<'a> {
    fn do_something(s: &'a str) -> Result<Self, Error>;
}

impl<'a> Simple<'a> for &'a str {
     fn do_something(s: &'a str) -> Result<Self, Error> {
        Ok(s)
    }
}

impl<'a, T: FromStr> Simple<'a> for T {
    fn do_something(s: &'a str) -> Result<Self, Error> {
        T::from_str(s).map_err(|_| Error)
    }
}

fn main() {
    // Do nothing. Just type check.
}

Компиляция завершается неудачно, поскольку компилятор ссылается на конфликты реализации. Обратите внимание, что &str не реализует FromStr , поэтому конфликта быть не должно.

@sgrif

У меня было время посмотреть на первые два примера. Вот мои заметки.

Пример 1

В первом случае у вас есть:

• FromSqlRow<ST, DB> for T where T: FromSql<ST, DB>
• FromSqlRow<(ST, SU), DB> for (T, U) where T: FromSqlRow<ST, DB>, U: FromSqlRow<SU, DB>,

Проблема в том, что эти подразумеваются частично, но ни один из них не является более конкретным, чем другой:

• Потенциально у вас может быть T: FromSql<ST, DB> где T не является парой (поэтому он соответствует первому impl, но не второму).
• У вас потенциально может быть (T, U) где:
  
  
  
  • T: FromSqlRow<ST, DB> ,
  
  
  • U: FromSqlRow<SU, DB> , но _не_
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  
  • (так что второй имп соответствует, но не первый)
  
  
• Эти два имплиента перекрываются, потому что у вас может быть (T, U) такое что:
  
  
  
  • T: FromSqlRow<ST, DB>
  
  
  • U: FromSqlRow<SU, DB>
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  

Это та ситуация, которую разрешила бы решетка impls - вам нужно было бы написать третий impl для перекрывающегося случая и сказать, что он должен делать. В качестве альтернативы, отрицательные признаки могут дать вам возможность исключить совпадение или иным образом настроить возможные совпадения.

Пример 2

У вас есть:

• Queryable<ST, DB> for T where T: FromSqlRow<ST, DB>
• Queryable<Nullable<ST>, DB> for Option<T> where T: Queryable<ST, DB>

Они перекрываются, потому что у вас может быть Option<T> где:

• T: Queryable<ST, DB>
• Option<T>: FromSqlRow<Nullable<ST>, DB>

Но ни один impl не является более конкретным:

• У вас может быть T такое что T: FromSqlRow<ST, DB> но T не является Option<U> (соответствует первому имплизу, но не второму)
• У вас может быть Option<T> такое, что T: Queryable<ST, DB> но не Option<T>: FromSqlRow<Nullable<ST>, DB>

@SergioBenitez

Компиляция завершается неудачно, поскольку компилятор ссылается на конфликты реализации. Обратите внимание, что &str не реализует FromStr , поэтому конфликта быть не должно.

Проблема в том, что компилятор консервативно предполагает, что &str может появиться для реализации FromStr в будущем. Это может показаться глупым для данного примера, но в целом мы постоянно добавляем новые имплименты, и мы хотим защитить исходящий код от взлома, когда мы добавляем эти импы.

Это консервативный выбор, и со временем мы, возможно, захотим расслабиться. Вы можете получить предысторию здесь:

• http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/
• https://github.com/rust-lang/rfcs/pull/1023
• https://github.com/rust-lang/rfcs/issues/1053
• https://github.com/rust-lang/rfcs/pull/1148

Спасибо за прояснение этих двух случаев. Теперь это имеет смысл

Во вторник, 22 марта 2016 г., 18:34 Аарон Турон [email protected] написал:

@SergioBenitez https://github.com/SergioBenitez

Компиляция завершается неудачно, поскольку компилятор ссылается на конфликты реализации. Запись
что & str не реализует FromStr, поэтому конфликта быть не должно.

Проблема в том, что компилятор консервативно предполагает, что & str
может появиться реализация FromStr в будущем. Это может показаться глупым для
в этом примере, но в целом мы все время добавляем новые импы, и мы хотим
защитить код нижестоящего от взлома, когда мы добавляем эти имп.

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

-
http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/

• ржавчина-lang / rfcs # 1023 https://github.com/rust-lang/rfcs/pull/1023
• ржавчина / rfcs # 1053 https://github.com/rust-lang/rfcs/issues/1053
• ржавчина-lang / rfcs # 1148 https://github.com/rust-lang/rfcs/pull/1148

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/rust-lang/rust/issues/31844#issuecomment -200093757

@aturon

Проблема в том, что компилятор консервативно предполагает, что & str может в будущем реализовать FromStr. Это может показаться глупым для данного примера, но в целом мы постоянно добавляем новые имплименты, и мы хотим защитить исходящий код от взлома, когда мы добавляем эти импы.

Разве это не то, чем занимается специализация? Что касается специализации, я бы ожидал, что даже если в будущем будет добавлена ​​реализация FromStr для &str , прямая реализация трейта Simple для &str будет иметь приоритет.

@SergioBenitez вам нужно поместить default fn в более общий элемент impl. Твой
пример не является специализированным.

22 марта 2016 г., 18:54 Серхио Бенитес [email protected]
написал:

@aturon https://github.com/aturon

Проблема в том, что компилятор консервативно предполагает, что & str
может появиться реализация FromStr в будущем. Это может показаться глупым для этого
пример, но в целом мы добавляем новые импы все время, и мы хотим
защитить код нижестоящего от взлома, когда мы добавляем эти имп.

Разве это не то, чем занимается специализация? С участием
специализации, я бы ожидал, что даже если реализация FromStr
for & str были добавлены в будущем, прямая реализация для
trait для & str будет иметь приоритет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/rust-lang/rust/issues/31844#issuecomment -200097995

Я думаю, что "стандартные" черты, которые автоматически считаются default звучат сбивающе с толку. Вам может понадобиться как параметричность для трейта, как в Haskell, и т. Д., Так и ослабление impl s. Также вы не можете легко grep для них, как вы можете за default . Нетрудно одновременно ввести ключевое слово default и указать реализацию по умолчанию, но их нельзя разделить как есть. Кроме того, если кто-то хочет уточнить язык, то эти "стандартные" признаки можно переименовать в "предлагаемые признаки" в документации.

Примечание от # 32999 (комментарий) : если мы будем следовать правилу решетки (или разрешить отрицательные ограничения), трюк «использовать промежуточный признак» для предотвращения дальнейшей специализации чего-либо больше не будет работать.

@Stebalien

Почему не работает? Хитрость ограничивает специализацию частной чертой. Вы не можете специализировать личную черту, если не можете получить к ней доступ.

@ arielb1 А. Хорошая точка зрения. В моем случае это не личная черта.

Я не думаю, что аргументация «внешние элементы не могут специализироваться, потому что рассуждения о несуществующей прямой совместимости + правило согласованности» особенно интересны или полезны. Особенно, когда мы не придерживаемся наших конкретных правил согласованности.

Есть ли способ получить доступ к переопределенному default impl ? Если так, это может помочь в построении тестов. См. Раздел « Дизайн по контракту» и библиотека .

Разрешение проецирования связанных по умолчанию типов во время проверки типов позволит обеспечить неравенство типов во время компиляции: https://gist.github.com/7c081574958d22f89d434a97b626b1e4

#![feature(specialization)]

pub trait NotSame {}

pub struct True;
pub struct False;

pub trait Sameness {
    type Same;
}

mod internal {
    pub trait PrivSameness {
        type Same;
    }
}

use internal::PrivSameness;

impl<A, B> Sameness for (A, B) {
    type Same = <Self as PrivSameness>::Same;
}

impl<A, B> PrivSameness for (A, B) {
    default type Same = False;
}
impl<A> PrivSameness for (A, A) {
    type Same = True;
}

impl<A, B> NotSame for (A, B) where (A, B): Sameness<Same=False> {}

fn not_same<A, B>() where (A, B): NotSame {}

fn main() {
    // would compile
    not_same::<i32, f32>();

    // would not compile
    // not_same::<i32, i32>();
}

отредактировано за комментарий @burdges

Просто fyi @rphmeier, вероятно, следует избегать is.gd, потому что он не разрешается для пользователей Tor из-за использования CloudFlare. GitHub отлично работает с полными URL-адресами. И play.rust-lang.org отлично работает через Tor.

Сам @burdges FWIW play.rust-lang.org использует is.gd для кнопки «Сократить».

Однако его, вероятно, можно изменить: https://github.com/rust-lang/rust-playpen/blob/9777ef59b/static/web.js#L333

используйте это так (https://is.gd/Ux6FNs):

#![feature(specialization)]
pub trait Foo {}
pub trait Bar: Foo {}
pub trait Baz: Foo {}

pub trait Trait {
    type Item;
}

struct Staff<T> { }

impl<T: Foo> Trait for Staff<T> {
    default type Item = i32;
}

impl<T: Foo + Bar> Trait for Staff<T> {
    type Item = i64;
}

impl<T: Foo + Baz> Trait for Staff<T> {
    type Item = f64;
}

fn main() {
    let _ = Staff { };
}

Ошибка :

error: conflicting implementations of trait `Trait` for type `Staff<_>`: [--explain E0119]
  --> <anon>:20:1
20 |> impl<T: Foo + Baz> Trait for Staff<T> {
   |> ^
note: conflicting implementation is here:
  --> <anon>:16:1
16 |> impl<T: Foo + Bar> Trait for Staff<T> {
   |> ^

error: aborting due to previous error

Поддерживает ли это feture specialization и есть ли в настоящее время какие-либо другие реализации?

@zitsen

Эти имплименты не допускаются текущим дизайном специализации, потому что ни T: Foo + Bar ни T: Foo + Baz являются более специализированными, чем другие. То есть, если у вас есть T: Foo + Bar + Baz , непонятно, какой имплт должен "выиграть".

У нас есть некоторые мысли о более выразительной системе, которая позволила бы вам _также_ дать импл для T: Foo + Bar + Baz и, таким образом, устранить неоднозначность, но это еще не было полностью предложено.

Если отрицательная характеристика ограничивает когда-либо приземление trait Baz: !Bar , это также можно использовать со специализацией, чтобы доказать, что наборы типов, реализующие Bar, и те, которые реализуют Baz, различны и индивидуально специализированы.

Кажется, что ответ T: Foo + Bar + Baz также поможет.

Просто проигнорируйте это, у меня все еще есть какое-то отношение к моему делу, и я всегда восхищаюсь приземлением specialization и других функций.

Спасибо @aturon @rphmeier .

В последнее время я играл со специализацией и наткнулся на странный случай:

#![feature(specialization)]

trait Marker {
    type Mark;
}

trait Foo { fn foo(&self); }

struct Fizz;

impl Marker for Fizz {
    type Mark = ();
}

impl Foo for Fizz {
    fn foo(&self) { println!("Fizz!"); }
}

impl<T> Foo for T
    where T: Marker, T::Mark: Foo
{
    default fn foo(&self) { println!("Has Foo marker!"); }
}

struct Buzz;

impl Marker for Buzz {
    type Mark = Fizz;
}

fn main() {
    Fizz.foo();
    Buzz.foo();
}

Вывод компилятора:

error: conflicting implementations of trait `Foo` for type `Fizz`: [--explain E0119]
  --> <anon>:19:1
19 |> impl<T> Foo for T
   |> ^
note: conflicting implementation is here:
  --> <anon>:15:1
15 |> impl Foo for Fizz {
   |> ^

детский манеж

Я считаю, что вышеуказанный _должен_ компилироваться, и есть два интересных варианта, которые действительно работают как задумано:

1) Удаление привязки where T::Mark: Fizz :

impl<T> Foo for T
    where T: Marker //, T::Mark: Fizz
{
    // ...
}

детский манеж

2) Добавление «псевдонима, связанного с характеристикой»:

trait FooMarker { }
impl<T> FooMarker for T where T: Marker, T::Mark: Foo { }

impl<T> Foo for T where T: FooMarker {
    // ...
}

детский манеж

(Что _не_ работает, если Marker определено в отдельном ящике (!), См. Этот пример репозитория )

Я также считаю, что эта проблема может быть как-то связана с №20400.

РЕДАКТИРОВАТЬ : Я открыл проблему по этому поводу: # 36587

У меня проблема со специализацией. Не уверен, проблема ли это в реализации или в способе указания специализации.

use std::vec::IntoIter as VecIntoIter;

pub trait ClonableIterator: Iterator {
    type ClonableIter;

    fn clonable(self) -> Self::ClonableIter;
}

impl<T> ClonableIterator for T where T: Iterator {
    default type ClonableIter = VecIntoIter<T::Item>;

    default fn clonable(self) -> VecIntoIter<T::Item> {
        self.collect::<Vec<_>>().into_iter()
    }
}

impl<T> ClonableIterator for T where T: Iterator + Clone {
    type ClonableIter = T;

    #[inline]
    fn clonable(self) -> T {
        self
    }
}

( манеж )
(кстати, было бы неплохо, если бы этот код однажды попал в stdlib)

Этот код не работает с:

error: method `clonable` has an incompatible type for trait:
 expected associated type,
    found struct `std::vec::IntoIter` [--explain E0053]
  --> <anon>:14:5
   |>
14 |>     default fn clonable(self) -> VecIntoIter<T::Item> {
   |>     ^

Изменение возвращаемого значения на Self::ClonableIter дает следующую ошибку:

error: mismatched types [--explain E0308]
  --> <anon>:15:9
   |>
15 |>         self.collect::<Vec<_>>().into_iter()
   |>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found struct `std::vec::IntoIter`
note: expected type `<T as ClonableIterator>::ClonableIter`
note:    found type `std::vec::IntoIter<<T as std::iter::Iterator>::Item>`

По-видимому, вы не можете ссылаться на конкретный тип ассоциированного типа по умолчанию, который я считаю весьма ограничивающим.

@tomaka должно работать, в тексте RFC есть следующее:

impl<T> Example for T {
    default type Output = Box<T>;
    default fn generate(self) -> Box<T> { Box::new(self) }
}

impl Example for bool {
    type Output = bool;
    fn generate(self) -> bool { self }
}

(https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md#the-default-keyword)

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

@aatch этот пример, похоже, не компилируется с интуитивно понятным определением признака примера: https://play.rust-lang.org/?gist=97ff3c2f7f3e50bd3aef000dbfa2ca4e&version=nightly&backtrace=0

код специализации явно запрещает это - см. # 33481, что я изначально думал, что это ошибка, но оказалось проблемой диагностики. Мои PR по улучшению диагностики остались незамеченными, и я довольно долго не доводил их до последней версии.

@rphmeier текст RFC предполагает, что это должно быть разрешено, хотя этот пример скопирован из него.

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

Если бы мы выбрали default для impl а также для отдельных элементов, могли бы мы добиться, чтобы если какой-либо элемент был переопределен, то должны были быть все они? Это позволило бы нам рассуждать, основываясь на точном типе ассоциативного типа по умолчанию (например) в других элементах, что кажется полезным повышением выразительности.

Следует ли разрешить следующее? Я хочу специализировать тип так, чтобы ArrayVec был Copy когда его тип элемента - Copy, и чтобы он в противном случае имел деструктор. Я пытаюсь добиться этого, используя внутреннее поле, замененное на специализацию.

Я надеялся, что это будет скомпилировано, т.е. что он выводит возможность копирования полей ArrayVec<A> из типов полей, которые выбираются связью A: Copy + Array (компилируемый фрагмент на игровой площадке) .

impl<A: Copy + Array> Copy for ArrayVec<A>
    //where <A as Repr>::Data: Copy
{ }

Закомментированное предложение where не требуется, поскольку оно предоставляет частный тип Repr в общедоступном интерфейсе. (Во всяком случае, это тоже ДВС).

Изменить: я забыл, что уже сообщал об этом о проблеме № 33162, извините.

Следуйте за моим комментарием, моим фактическим вариантом использования:

// Ideal version

trait Scannable {}

impl<T: FromStr> Scannable for T {}
impl<T: FromStr> Scannable for Result<T, ()> {}

// But this doesn't follow from the specialisation rules because Result: !FromStr
// Lattice rule would allow filling in that gap or negative reasoning would allow specifying it.

// Second attempt

trait FromResult {
    type Ok;
    fn from(r: Result<Self::Ok, ()>) -> Self;
}

impl<T> Scannable for T {
    default type Ok = T;
    default fn from(r: Result<T, ()>) -> Self {...} // error can't assume Ok == T, could do this if we had `default impl`
}

impl<T> Scannable for Result<T, ()> {
    type Ok = T;
    default fn from(r: Result<T, ()>) -> Self { r }
}

fn scan_from_str<T: FromResult>(x: &str) -> T
    where <T as FromResult>::Ok: FromStr  // Doesn't hold for T: FromStr because of the default on T::Ok
{ ... }

// Can also add the FromStr bound to FromResult::Ok, but doesn't help

// Third attempt
trait FromResult<Ok> {
    fn from(r: Result<Ok, ()>) -> Self;
}

impl<T> FromResult<T> for T {
    default fn from(r: Result<Self, ()>) -> Self { ... }
}

impl<T> FromResult<T> for Result<T, ()> {
    fn from(r: Result<T, ())>) -> Self { r }
}


fn scan_from_str<U: FromStr, T: FromResult<U>>(x: &str) -> T { ... }

// Error because we can't infer that U == String
let mut x: Result<String, ()> = scan_from_str("dsfsf");

@tomaka @Aatch

Проблема в том, что вам не разрешено полагаться на значения других элементов по умолчанию. Итак, когда у вас есть это:

impl<T> ClonableIterator for T where T: Iterator {
    default type ClonableIter = VecIntoIter<T::Item>;

    default fn clonable(self) -> VecIntoIter<T::Item> {
    //                           ^^^^^^^^^^^^^^^^^^^^
        self.collect::<Vec<_>>().into_iter()
    }
}

В том месте, где я выделил, clonable полагается на Self::ClonableIter , но поскольку CloneableIter объявлен по умолчанию, вы не можете этого сделать. Беспокоит то, что кто-то может специализироваться и переопределить CloneableIter но _не_ clonable .

Здесь мы говорили о некоторых возможных ответах. Один из них заключался в том, чтобы позволить вам использовать default для группировки элементов, где, если вы переопределите один, вы должны переопределить все:

impl<T> ClonableIterator for T where T: Iterator {
    default {
        type ClonableIter = VecIntoIter<T::Item>;
        fn clonable(self) -> VecIntoIter<T::Item> { ... }
    }
}

Это нормально, но немного "подталкивает вправо". default также выглядит как область именования, но это не так. Может быть какой-то более простой вариант, который просто позволяет вам переключаться между «переопределить любой» (как сегодня) и «переопределить все» (что вам нужно).

Мы также надеялись, что сможем обойтись, используя impl Trait . Идея состоит в том, что это чаще всего возникает, как в данном случае, когда вы хотите настроить тип возвращаемого значения методов. Так что, возможно, если бы вы могли переписать трейт, чтобы использовать impl Trait :

pub trait ClonableIterator: Iterator {
    fn clonable(self) -> impl Iterator;
}

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

PS, извините за долгую задержку с ответом на ваши сообщения, я вижу дату от _July_.

Хотя impl Trait действительно помогает, не существует RFC, который был принят или реализован, который позволяет использовать его с телами признаков в любой форме, поэтому искать его для этого RFC кажется немного странным.

Меня интересует реализация функции default impl (где все элементы - default ).
Вы бы приняли участие в этом?

@giannicic Определенно! Я был бы рад также помочь наставником в работе.

Есть ли в настоящее время заключение о том, должны ли ассоциированные типы быть специализированными?

Ниже приводится упрощение моего варианта использования, демонстрирующее потребность в специализированных связанных типах.
У меня есть общая структура данных, скажем Foo , которая координирует коллекцию объектов-признаков контейнера ( &trait::Property ). Признак trait::Property реализуется как Property<T> (при поддержке Vec<T> ), так и PropertyBits (при поддержке BitVec , битового вектора).
В общих методах для Foo я хотел бы иметь возможность определять правильную базовую структуру данных для T через связанные типы, но для этого требуется специализация, чтобы иметь общее представление для не особых случаев, как следует.

trait ContainerFor {
    type P: trait::Property;
}

impl<T> ContainerFor for T {
    default type P = Property<T>; // default to the `Vec`-based version
}

impl ContainerFor for bool {
    type P = PropertyBits; // specialize to optimize for space
}

impl Foo {
    fn add<T>(&mut self, name: &str) {
        self.add_trait_obj(name, Box::new(<T as ContainerFor>::P::new())));
    }
    fn get<T>(&mut self, name: &str) -> Option<&<T as ContainerFor>::P> {
        self.get_trait_obj(name).and_then(|prop| prop.downcast::<_>());
    }
}

Спасибо @aturon !
В основном я делаю эту работу, добавляя новый атрибут «defaultness» в структуру ast::ItemKind::Impl (а затем использую новый атрибут вместе с атрибутом «defaultness» элемента impl), но есть также быстрый и простой
возможность, состоящая в установке по умолчанию для всех имплементов default impl во время синтаксического анализа.
Для меня это не «полное» решение, поскольку мы потеряли информацию о том, что «дефолтность» связана с имплементацией, а не с каждым элементом имплементации,
кроме того, если есть план ввести partial impl первое решение уже будет предоставлять атрибут, который можно использовать для хранения default а также partial . Но на всякий случай и
не теряя времени, о чем вы думаете?

@giannicic @aturon, могу я предложить создать конкретную проблему для обсуждения default impl ?

Неважно, я его создал: https://github.com/rust-lang/rust/issues/37653

Позволит ли мне правило решетки, учитывая:

trait Foo {}

trait A {}
trait B {}
trait C {}
// ...

добавить реализации Foo для подмножества типов, которые реализуют некоторую комбинацию A , B , C , ...:

impl Foo for T where T: A { ... }
impl Foo for T where T: B { ... }
impl Foo for T where T: A + B { ... }
impl Foo for T where T: B + C { ... }
// ...

и позвольте мне "запретить" некоторые комбинации, например, что A + C никогда не должно происходить:

impl Foo for T where T: A + C = delete;

?

Контекст: я захотел этого при реализации трейта ApproxEqual(Shape, Shape) для различных типов фигур (точек, кубов, многоугольников и т. Д.), Где все это черты. Мне пришлось обойти это путем рефакторинга в разные свойства, например, ApproxEqualPoint(Point, Point) , чтобы избежать конфликтующих реализаций.

@gnzlbg

и позвольте мне "запретить" некоторые комбинации, например, что A + C никогда не должно происходить:

Нет, это не то, что разрешает правило решетки. Это было бы больше областью «негативных рассуждений» в той или иной форме.

Контекст: я захотел этого при реализации трейта ApproxEqual (Shape, Shape) для разных типов фигур (точек, кубов, многоугольников ...), где все это черты. Мне пришлось обойти это, реорганизовав это в разные черты, например, ApproxEqualPoint (Point, Point), чтобы избежать конфликтующих реализаций.

Итак, @withoutboats продвигает идею «групп исключения», где вы можете объявить, что определенный набор характеристик является взаимоисключающим (т.

@nikomatsakis :

Итак, @withoutboats продвигает идею «групп исключения», где вы можете объявить, что определенный набор характеристик является взаимоисключающим (т.

Я думал о группах исключений, когда писал это (вы упомянули об этом на форуме на днях), но я не думаю, что они могут работать, поскольку в этом конкретном примере не все реализации трейтов являются эксклюзивными. Самый тривиальный пример - это черты Point и Float : Float _ может быть 1D точкой, поэтому ApproxEqualPoint(Point, Point) и ApproxEqualFloat(Float, Float) не могут быть эксклюзивный. Есть и другие примеры, например Square и Polygon или Box | Cube и AABB (ограничивающая рамка, выровненная по оси), где «иерархия признаков» действительно требует более сложных ограничений.

Нет, это не то, что разрешает правило решетки. Это было бы больше областью «негативных рассуждений» в той или иной форме.

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

Специализация решетки cry :.

Идея «групп исключения» на самом деле является просто отрицательными границами суперсемейта. Одна вещь, которую мы не исследовали слишком тщательно, - это понятие специализации обратной полярности, позволяющее вам написать специализированный имплант с обратной полярностью для его менее специализированного имплантата. Например, в этом случае вы просто напишите:

impl<T> !Foo for T where T: A + C { }

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

При всем этом обсуждении негативных рассуждений и негативных импликаций я чувствую себя обязанным снова вспомнить старую идею Haskell о «цепочках экземпляров» ( бумага , бумага , система отслеживания проблем GHC , предварительный RFC Rust ) как потенциальный источник вдохновения еще.

По сути, идея состоит в том, что везде, где вы можете написать trait impl, вы также можете написать любое количество «else if clauses», указав другое impl которое должно применяться в случае, если предыдущие не сделал, с необязательным заключительным предложением else, указывающим отрицательное impl (то есть, если ни одно из предложений для Trait применяется, то применяется !Trait ).

@withoutboats

Идея «групп исключения» на самом деле является просто отрицательными границами суперсемейта.

Думаю, этого было бы достаточно для моих вариантов использования.

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

Я не знаю, можно ли их распутать. Я хочу иметь:

• полиморфизм: единый признак, который абстрагирует разные реализации операции для множества разных типов,
• повторное использование кода: вместо реализации операции для каждого типа я хочу реализовать их для групп типов, реализующих некоторые черты,
• производительность: иметь возможность переопределить уже существующую реализацию для определенного типа или подмножества типов, которые имеют более конкретный набор ограничений, чем уже существующие реализации,
• продуктивность: иметь возможность писать и тестировать мою программу постепенно, вместо того, чтобы добавлять много impl s для ее компиляции.

Охватить все случаи сложно, но если компилятор заставит меня охватить все случаи:

trait Foo {}
trait A {}
trait B {}

impl<T> Foo for T where T: A { ... }
impl<T> Foo for T where T: B { ... }
// impl<T> Foo for T where T: A + B { ... }  //< compiler: need to add this impl!

а также дает мне отрицательные выводы:

impl<T> !Foo for T where T: A + B { }
impl<T> !Foo for T where T: _ { } // _ => all cases not explicitly covered yet

Я мог бы постепенно добавлять impls по мере необходимости, а также получать хорошие ошибки компилятора, когда пытаюсь использовать трейт с типом, для которого нет impl.

Я не совсем уверен, каковы последствия этого разрешения.

Нико упомянул, что есть проблемы с отрицательной аргументацией. FWIW единственное, для чего в приведенном выше примере используется отрицательная аргументация, - это указать, что пользователь знает, что для конкретного случая требуется impl, но явно решил не предоставлять для него реализацию.

Я только что нажал # 33017 и еще не вижу здесь ссылки. Он отмечен как дыра для надежности, поэтому было бы неплохо отследить здесь.

Для https://github.com/dtolnay/quote/issues/7 мне нужно что-то похожее на этот пример из RFC, который еще не работает. cc @tomaka @Aatch @rphmeier, который ранее прокомментировал это.

trait Example {
    type Output;
    fn generate(self) -> Self::Output;
}

impl<T> Example for T {
    default type Output = Box<T>;
    default fn generate(self) -> Box<T> { Box::new(self) }
}

impl Example for bool {
    type Output = bool;
    fn generate(self) -> bool { self }
}

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

#![feature(specialization)]

use std::fmt::{self, Debug};

///////////////////////////////////////////////////////////////////////////////

trait Example: Output {
    fn generate(self) -> Self::Output;
}

/// In its own trait for reasons, presumably.
trait Output {
    type Output: Debug + Valid<Self>;
}

fn main() {
    // true
    println!("{:?}", Example::generate(true));

    // box("s")
    println!("{:?}", Example::generate("s"));
}

///////////////////////////////////////////////////////////////////////////////

/// Instead of `Box<T>` just so the "{:?}" in main() clearly shows the type.
struct MyBox<T: ?Sized>(Box<T>);

impl<T: ?Sized> Debug for MyBox<T>
    where T: Debug
{
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "box({:?})", self.0)
    }
}

///////////////////////////////////////////////////////////////////////////////

/// Return type of the impl containing `default fn`.
type DefaultOutput<T> = MyBox<T>;

impl Output for bool {
    type Output = bool;
}

impl<T> Example for T where T: Pass {
    default fn generate(self) -> Self::Output {
        T::pass({
            // This is the impl you wish you could write
            MyBox(Box::new(self))
        })
    }
}

impl Example for bool {
    fn generate(self) -> Self::Output {
        self
    }
}

///////////////////////////////////////////////////////////////////////////////
// Magic? Soundness exploit? Who knows?

impl<T: ?Sized> Output for T where T: Debug {
    default type Output = DefaultOutput<T>;
}

trait Valid<T: ?Sized> {
    fn valid(DefaultOutput<T>) -> Self;
}

impl<T: ?Sized> Valid<T> for DefaultOutput<T> {
    fn valid(ret: DefaultOutput<T>) -> Self {
        ret
    }
}

impl<T> Valid<T> for T {
    fn valid(_: DefaultOutput<T>) -> Self {
        unreachable!()
    }
}

trait Pass: Debug {
    fn pass(DefaultOutput<Self>) -> <Self as Output>::Output;
}

impl<T: ?Sized> Pass for T where T: Debug, <T as Output>::Output: Valid<T> {
    fn pass(ret: DefaultOutput<T>) -> <T as Output>::Output {
        <T as Output>::Output::valid(ret)
    }
}

Я все еще работаю над https://github.com/dtolnay/quote/issues/7, и мне нужен был ромбовидный узор. Вот мое решение. cc @zitsen, который спрашивал об этом ранее, и @aturon и @rphmeier, которые ответили.

#![feature(specialization)]

/// Can't have these impls directly:
///
///  - impl<T> Trait for T
///  - impl<T> Trait for T where T: Clone
///  - impl<T> Trait for T where T: Default
///  - impl<T> Trait for T where T: Clone + Default
trait Trait {
    fn print(&self);
}

fn main() {
    struct A;
    A.print(); // "neither"

    #[derive(Clone)]
    struct B;
    B.print(); // "clone"

    #[derive(Default)]
    struct C;
    C.print(); // "default"

    #[derive(Clone, Default)]
    struct D;
    D.print(); // "clone + default"
}

trait IfClone: Clone { fn if_clone(&self); }
trait IfNotClone { fn if_not_clone(&self); }

impl<T> Trait for T {
    default fn print(&self) {
        self.if_not_clone();
    }
}

impl<T> Trait for T where T: Clone {
    fn print(&self) {
        self.if_clone();
    }
}

impl<T> IfClone for T where T: Clone {
    default fn if_clone(&self) {
        self.clone();
        println!("clone");
    }
}

impl<T> IfClone for T where T: Clone + Default {
    fn if_clone(&self) {
        self.clone();
        Self::default();
        println!("clone + default");
    }
}

impl<T> IfNotClone for T {
    default fn if_not_clone(&self) {
        println!("neither");
    }
}

impl<T> IfNotClone for T where T: Default {
    fn if_not_clone(&self) {
        Self::default();
        println!("default");
    }
}

Удалите ошибку (или, по крайней мере, неожиданное поведение с моей точки зрения) с помощью специализации и вывода типа: # 38167

Следует ожидать, что эти два импликации будут действительны со специализацией, верно? Вроде не удачно подбирает.

impl<T, ST, DB> ToSql<Nullable<ST>, DB> for T where
    T: ToSql<ST, DB>,
    DB: Backend + HasSqlType<ST>,
    ST: NotNull,
{
    ...
}

impl<T, ST, DB> ToSql<Nullable<ST>, DB> for Option<T> where
    T: ToSql<ST, DB>,
    DB: Backend + HasSqlType<ST>,
    ST: NotNull,
{
    ...
}

Я подал https://github.com/rust-lang/rust/issues/38516 на предмет неожиданного поведения, с которым столкнулся, работая над созданием специализации в Serde. Подобно https://github.com/rust-lang/rust/issues/38167 , это случай, когда программа компилируется без специализированного impl, а при его добавлении возникает ошибка типа. cc @bluss , которого ранее беспокоила эта ситуация.

Что, если бы мы разрешили специализацию без ключевого слова default в одном ящике, аналогично тому, как мы разрешаем отрицательные аргументы в одном ящике?

Мое главное оправдание таково: «шаблон итераторов и векторов». Иногда пользователи хотят реализовать что-то для всех итераторов и векторов:

impl<I> Foo for I where I: Iterator<Item = u32> { ... }
impl Foo for Vec<u32> { ... }

(Это относится к другим ситуациям, кроме итераторов и векторов, конечно, это только один пример.)

Сегодня это не компилируется, есть цурис и скрежет зубов. Специализация решает эту проблему:

default impl<I> Foo for I where I: Iterator<Item = u32> { ... }
impl Foo for Vec<u32> { ... }

Но, решая эту проблему, вы добавили в свой ящик публичный контракт: можно переопределить итератор impl Foo . Возможно, мы не хотим заставлять вас это делать - следовательно, локальная специализация без default .

Я полагаю, вопрос в том, в чем именно заключается роль default . Требование default было, я думаю, изначально жестом в сторону ясности и самодокументирования кода. Так же, как код Rust по умолчанию неизменяемый, закрытый по умолчанию, безопасный по умолчанию, он также должен быть окончательным по умолчанию. Однако, поскольку «нефинальность» - это глобальное свойство, я не могу специализировать элемент, если не позволю вам специализировать элемент.

Требование default было, я думаю, изначально жестом в сторону ясности и самодокументирования кода. Однако [..] я не могу специализировать предмет, если я не позволю вам специализировать предмет.

Неужели это так плохо? Если вы хотите специализироваться на имплантологе, то, возможно, другие люди тоже захотят.

Я волнуюсь, потому что одна мысль об этом RFC уже дает мне воспоминания о посттравматическом стрессе о работе с кодовыми базами C ++, которые используют неприличное количество перегрузки и наследования и не имеют представления о том, что wtf происходит в любой строке кода, в которой есть вызов метода. Я действительно ценю то, на что пошел @aturon , чтобы сделать специализацию явной и самодокументированной.

Неужели это так плохо? Если вы хотите специализироваться на имплантологе, то, возможно, другие люди тоже захотят.

Если другие люди только «может быть» тоже хотят специализироваться на этом, и если есть хорошие случаи, когда мы бы этого не хотели, мы не должны делать невозможным это указать. (немного похоже на инкапсуляцию: вы хотите получить доступ к некоторым данным, а может быть, и другие люди тоже захотят - поэтому вы явно помечаете _this data_ общедоступными, вместо того, чтобы по умолчанию все данные были общедоступными.)

Я волнуюсь, потому что одна мысль об этом RFC уже вызывает у меня воспоминания о посттравматическом стрессе ...

Но как запретить эту спецификацию предотвратить такие вещи?

если есть хорошие случаи, когда мы бы не хотели, чтобы они это делали, мы не должны делать невозможным указание этого.

Необязательно давать пользователям возможности, когда они могут быть полезны. Нет, если это также позволяет пользователям писать запутанный код.

Но как запретить эту спецификацию предотвратить такие вещи?

Допустим, вы видите foo.bar() и хотите посмотреть, что делает bar() . Прямо сейчас, если вы обнаружите, что метод реализован на подходящем типе и он не помечен как default вы знаете, что это определение метода, которое вы ищете. С предложением @withoutboats это больше не будет правдой - вместо этого вы никогда не узнаете наверняка, действительно ли вы смотрите на код, который выполняется.

вместо этого вы никогда не узнаете наверняка, действительно ли вы смотрите на код, который выполняется.

Это явное преувеличение эффекта разрешения специализации имплицитов, отличных от значений по умолчанию, для локальных типов. Если вы смотрите на конкретный имплант, вы знаете, что смотрите на правильный импл. И у вас есть доступ ко всему источнику этого ящика; Вы можете определить, является ли этот имплант специализированным или нет, раньше, чем "никогда".

Между тем, даже с default проблема остается, даже если импл не был завершен. Если правильный impl на самом деле является default impl, вы находитесь в той же ситуации, когда не уверены, что это правильный impl. И, конечно, если используется специализация, это будет довольно часто (например, это так сегодня почти для каждого импликации ToString ).

На самом деле я считаю, что это довольно серьезная проблема, но не уверен, что default решает ее. Нам нужны более совершенные инструменты навигации по коду. В настоящее время rustdoc применяет подход «максимальных усилий», когда дело доходит до имплиментов трейтов - он не ссылается на их источник и даже не перечисляет имплименты, предоставляемые blanket impls.

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

Необязательно давать пользователям возможности, когда они могут быть полезны. Нет, если это также позволяет пользователям писать запутанный код.

Совершенно верно. Я думаю, что я говорю здесь о другом «пользователе», который является пользователем ящиков, которые вы пишете. Вы же не хотите, чтобы они свободно специализировали черты в вашем ящике (возможно, хакерским образом влияя на поведение вашего ящика). С другой стороны, мы дадим больше возможностей «пользователю», о котором вы говорите, а именно автору ящика, но даже без предложения @withoutboats вам придется использовать «по умолчанию» и столкнуться с той же проблемой. .

Я думаю, что default помогает в том смысле, что если вы хотите упростить чтение кода, вы можете попросить, чтобы никто не использовал default или установил строгие правила документации для его использования. В этот момент вам нужно только беспокоиться о default s из std , которые, по-видимому, люди лучше поймут.

Я вспоминаю идею о том, что правила документации могут быть наложены на использование специализации, способствовавшее утверждению RFC специализации.

@withoutboats. Правильно ли я прочитал вашу мотивацию к ослаблению default поскольку вам нужна ограниченная форма default что означает "переопределение, но только в этом ящике" (т.е. pub(crate) но для default )? Однако для простоты вы предлагаете изменить семантику исключения default вместо добавления градаций default -ness?

Верный. Выполнение чего-то вроде default(crate) кажется излишним.

Априори, я бы предположил, что это можно смоделировать через то, что экспортирует ящик, не так ли? Существуют ли ситуации, когда вы не могли бы просто ввести личную вспомогательную черту с помощью методов default и вызвать ее из своего собственного финального impl s? Вы хотите, чтобы пользователь использовал ваши default s, но не предоставлял свои собственные?

Верный. Выполнение чего-то вроде default (crate) кажется излишним.

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

@nikomatsakis У меня та же мотивация, я предлагаю просто удалить стандартное требование специализироваться на одном ящике, а не добавлять больше рычагов. :-)

Если случайно это неэкспортированное значение по умолчанию может быть более распространенным, тогда функцию #[default_export] будет легче запомнить по аналогии с #[macro_export] . Промежуточным вариантом может быть разрешение этой функции экспорта для строк pub use или pub mod .

Было бы лучше использовать ключевое слово pub , поскольку макросы 2.0 будут поддерживать макросы как обычные элементы и использовать pub вместо #[macro_use] . Использование pub для обозначения видимости по всем направлениям было бы большим выигрышем для его согласованности.

@withoutboats в любом случае, я думаю, иногда вам захочется специализироваться на местном уровне, но не обязательно открывать двери для всех

Было бы лучше использовать ключевое слово pub

Наличие pub default fn означает «публично экспортировать дефолтность fn», а не влиять на видимость самой функции, будет очень запутать новичков.

@jimmycuadra - это то, что вы имели в виду, используя ключевое слово pub ? Я согласен с @sgrif, что это кажется более запутанным, и если мы собираемся разрешить вам явно определять область действия по умолчанию, тот же синтаксис, который мы выбрали для определения области видимости, кажется правильным путем.

Вероятно, не совсем pub default fn , потому что это неоднозначно, как вы оба упомянули. Я просто сказал, что есть смысл в том, чтобы pub универсально означало «раскрыть что-то, что в остальном частное, извне». Вероятно, существует некоторая формулировка синтаксиса, включающая pub , которая будет визуально отличаться, чтобы ее не путали с открытием самой функции.

Хотя это немного синтаксис, я бы не стал возражать против того, чтобы default(foo) работала как pub(foo) - симметрия между ними незначительно перевешивает для меня непостоянство синтаксиса.

Предупреждение Bikeshed: рассматривали ли мы возможность назвать его overridable вместо default ? Это более буквально описательно, и overridable(foo) для меня читается лучше, чем default(foo) - последний предполагает, что "это значение по умолчанию в рамках foo , но что-то другое может быть по умолчанию в другом месте ", в то время как в первом говорится, что" это можно переопределить в рамках foo ", что правильно.

Я думаю, что первые два вопроса на самом деле таковы: действительно ли экспорт или не экспорт default значительно более распространенным? Не следует ли экспортировать default ness по умолчанию?

Да, случай: вы можете максимизировать сходство с экспортом в другом месте, что диктует что-то вроде pub mod mymodule default; и pub use mymodule::MyTrait default; , или, возможно, с overridable . При необходимости вы можете экспортировать default только для некоторых методов с pub use MyModule::MyTrait::{methoda,methodb} default;

Ни в коем случае: вам нужно выражать конфиденциальность, а не публичность, которая в любом случае значительно отличается от всего остального в Rust, поэтому теперь default(crate) становится нормальным способом контролировать этот экспорт.

Кроме того, если экспорт и не экспорт default являются сравнительно обычным явлением, то вы, ребята, вероятно, можете произвольно выбрать вариант «да» или «нет», так что снова просто выбор pub use MyModule::MyTrait::{methoda,methodb} default; работает нормально.

Все эти обозначения в любом случае выглядят совместимыми. Другим вариантом может быть какой-то специальный impl который перекрывает default s, но это звучит сложно и странно.

@burdges Есть ли у вас ярлыки «да, случай» и «нет» наоборот, или я неправильно понимаю, что вы говорите?

Ага, ой! Исправлена!

У нас есть impl<T> Borrow<T> for T where T: ?Sized так что привязка Borrow<T> может обрабатывать собственные значения, как если бы они были заимствованы.

Я полагаю, мы могли бы использовать специализацию для оптимизации удаленных вызовов на clone от Borrow<T> , да?

pub trait CloneOrTake<T> {
    fn clone_or_take(self) -> T;
}

impl<B,T> CloneOrTake<T> for B where B: Borrow<T>, T: Clone {
    #[inline]
    default fn clone_or_take(b: B) -> T { b.clone() }
}
impl<T> CloneOrTake<T> for T {
    #[inline]
    fn clone_or_take(b: T) -> T { b };
}

Я думаю, что это может сделать Borrow<T> пригодным для использования в других ситуациях. Я сбросил привязку T: ?Sized потому что предположительно требуется Sized при возврате T .

Другой подход может быть

pub trait ToOwnedFinal : ToOwned {
    fn to_owned_final(self) -> Self::Owned;
}

impl<B> ToOwnedFinal for B where B: ToOwned {
    #[inline]
    default fn to_owned_final(b: B) -> Self::Owned { b.to_owned() }
}
impl<T> ToOwnedFinal for T {
    #[inline]
    fn to_owned_final(b: T) -> T { b };
}

Сегодня мы сделали несколько, возможно, тревожных открытий, вы можете прочитать логи IRC здесь: https://botbot.me/mozilla/rust-lang/

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

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

ящик parent v 1.0.0

trait A { }
trait B { }
trait C {
    fn foo(&self);
}

impl<T> C for T where T: B {
    // No default, not specializable!
    fn foo(&self) { panic!() }
}

ящик client (зависит от parent )

extern crate parent;

struct Local;

impl parent::A for Local { }
impl parent::C for Local {
    fn foo(&self) { }
}

Local реализует A и C но не B . Если бы local реализовал B , его импликация C будет конфликтовать с неспециализированным имплантированным бланкетом C for T where T: B .

ящик parent v 1.1.0

// Same code as before, but add:
default impl<T> B for T where T: A { }

Этот impl был добавлен и является полностью специализированным, поэтому мы сказали, что это нерушимое изменение. Однако это создает транзитивную импликацию - у нас уже есть «все B impl C (не специализированный)», добавив «all A impl B (специализированный)», мы неявно добавили оператор «all A impl C (не специализированный) ". Теперь детский ящик нельзя обновить.

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

Таким образом , ее неопределенный мне , если «impls является неразрывной» гарантия спасти , , но он уверен , что она не совместима с явным контролем над осущий завершенностью.

Есть ли какой-нибудь план по этому поводу?

struct Foo;

trait Bar {
    fn bar<T: Read>(stream: &T);
}

impl Bar for Foo {
    fn bar<T: Read>(stream: &T) {
        let stream = BufReader::new(stream);

        // Work with stream
    }

    fn bar<T: BufRead>(stream: &T) {
        // Work with stream
    }
}

Таким образом, по сути, это специализация для функции шаблона, которая имеет параметр типа с привязкой к A где специализированная версия имеет привязку к B (что требует A ).

@torkleyy в настоящее время нет, но вы можете сделать это тайно, создав трейт, который реализован как для T: Read и для T: BufRead и содержит части вашего кода, которые вы хотите специализировать на имплиентах этого признака. Его даже не нужно видеть в общедоступном API.

Что касается проблемы обратной совместимости, я думаю, что благодаря сиротским правилам мы можем обойтись без следующих правил:

_An impl обратно совместим для добавления, если : _

• _Проявленная черта является автоматической чертой.
• _Приемник - это параметр типа, и каждая черта в impl существовала ранее.

То есть, я думаю, что во всех проблемных примерах добавленный impl - это бланкетный impl. Мы хотели сказать, что полностью стандартные имплементы для бланкетов тоже допустимы, но я думаю, мы просто должны сказать, что добавление существующих имплементов для бланкетов может стать серьезным изменением.

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

@withoutboats

Что касается проблемы обратной совместимости, я думаю, что благодаря сиротским правилам мы можем обойтись без следующих правил:

_An impl обратно совместим для добавления, если : _

• _Проявленная черта является автоматической чертой.
• _Приемник - это параметр типа, и каждая черта в impl существовала ранее.

То есть, я думаю, что во всех проблемных примерах добавленный impl - это бланкетный impl. Мы хотели сказать, что полностью стандартные имплементы для бланкетов тоже допустимы, но я думаю, мы просто должны сказать, что добавление существующих имплементов для бланкетов может стать серьезным изменением.

Спустя неделю и много обсуждений это, к сожалению, оказалось не так .

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

В какой-то момент я действительно подумал, что мы могли бы ослабить правила для сирот, чтобы вы могли реализовать черты для таких типов, как Vec<MyType> , но если бы мы это сделали, эта ситуация тогда разыгралась бы точно так же:

//crate A

trait Foo { }

// new impl
// impl<T> Foo for Vec<T> { }

// crate B
extern crate A;

use A::Foo;

trait Bar {
    type Assoc;
}

// Sadly, this impl is not an orphan
impl<T> Bar for Vec<T> where Vec<T>: Foo {
    type Assoc = ();
}

// crate C

struct Baz;

// Therefore, this impl must remain an orphan
impl Bar for Vec<Baz> {
    type Assoc = bool;
}

@withoutboats А, я понял ваш список из двух маркеров как или, а не как и , что, кажется, вы имели в виду?

@aturon Да, я имел в виду «или» - это два случая, когда это критическое изменение. Любая автоматическая характеристика имплантата, независимо от того, насколько она конкретна, является критическим изменением, поскольку мы позволяем распространять негативные рассуждения о них: https://is.gd/k4Xtlp

То есть, если он не содержит новых имен. AFAIK, имплант, содержащий новое имя, никогда не ломается.

@withoutboats Мне интересно, можем ли мы / должны ли мы ограничивать людей, полагающихся на негативную логику в отношении авто-черт характера. То есть, если мы сказали, что добавление новых имплиментов автоматических черт является нарушением закона, мы могли бы предупредить о имплиентах, которые могут быть нарушены добавлением вышестоящего ящика Send . Лучше всего это сработало бы, если бы у нас было:

1. стабильная специализация, предупреждения можно обойти, добавив default в стратегических местах (большую часть времени);
2. некоторая форма явных отрицательных имплиций, чтобы такие типы, как Rc могли заявить о своем намерении никогда не быть Send - но тогда у нас есть такие для автоматических черт, чтобы мы могли их учитывать.

Не знаю, думаю, это зависит от сильной мотивации. Особенно маловероятно, что вы поймете, что у типа может быть unsafe impl Send/Sync после того, как вы его уже выпустили; Я думаю, что в большинстве случаев это будет безопасно, если вы напишете тип с предвидением, что он будет безопасным (потому что в этом суть типа).

Я все время добавляю unsafe impl Send/Sync постфактум. Иногда потому, что я делаю его потокобезопасным, иногда потому, что я понимаю, что API C, с которым я взаимодействую, можно использовать в потоках, а иногда просто потому, что должно ли что-то быть Send / Sync isn Это не то, о чем я думаю, когда представляю шрифт.

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

Одна вещь, которая мне не нравится в том, как работает специализация связанных черт прямо сейчас, - этот шаблон не работает:

trait Buffer: Read {
    type Buffered: BufRead;
    fn buffer(self) -> impl BufRead;
}

impl<T: Read> Buffer for T {
    default type Buffered = BufReader<T>;
    default fn buffer(self) -> BufReader<T> {
        BufReader::new(self)
    }
}

impl<T: BufRead> Buffer for T {
    type Buffered = Self;
    fn buffer(self) -> T {
        self
    }
}

Это связано с тем, что текущая система требует, чтобы это имплементация была действительной:

impl Buffer for SomeRead {
    type Buffered = SomeBufRead;
    // no overriding of fn buffer, it no longer returns Self::Buffered
}

impl Trait in traits высвободило бы большое желание для такого рода шаблонов, но мне интересно, нет ли лучшего решения, где общий impl действителен, но эта специализация не работает, потому что она вводит ошибку типа ?

@withoutboats Да, это один из основных нерешенных вопросов по дизайну (который я забыл

@aturon Является ли текущее решение наиболее консервативным (прямая совместимость со всем, что мы хотим сделать) или это решение, которое мы должны принять перед стабилизацией?

Я лично считаю, что единственное реальное решение этой проблемы, которую поднимает default . Это своего рода решение «лучше - значит лучше», но мне кажется, что вариант «хуже - да лучше» (переопределение любых средств переопределения всего) намного хуже. (Но на самом деле @withoutboats способ, которым вы написали этот код, сбивает с толку. Я думаю, что вместо использования impl BufRead в качестве возвращаемого типа Buffer , вы имели в виду Self::BufReader , верно?)

В этом случае будет разрешено следующее:

trait Buffer: Read {
    type Buffered: BufRead;
    fn buffer(self) -> impl BufRead;
}

impl<T: Read> Buffer for T {
    default {
        type Buffered = BufReader<T>;
        fn buffer(self) -> BufReader<T> {
            BufReader::new(self)
        }
    }
}

impl<T: BufRead> Buffer for T {
    type Buffered = Self;
    fn buffer(self) -> T {
        self
    }
}

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

Но на самом деле @withoutboats способ написания этого кода сбивает с толку. Я думаю, что вместо использования impl BufRead в качестве возвращаемого типа Buffer вы имели в виду Self :: BufReader, верно?

Да, я изменил решение на имплицит на основе трейта, а затем переключился обратно, но пропустил возвращаемый тип в трейте.

Возможно, что-то вроде системы типов этого языка также может быть интересным, поскольку он похож на Rusts, но с некоторыми особенностями, которые могут решить текущие проблемы.
( A <: B в Rust будет истинным, если A является структурой и реализует черту B , или когда A является чертой, и общие реализации для объектов эта черта есть, думаю)

Похоже, есть проблема с признаком Display для специализации.
Например, этот пример не компилируется:

use std::fmt::Display;

pub trait Print {
    fn print(&self);
}

impl<T: Display> Print for T {
    default fn print(&self) {
        println!("Value: {}", self);
    }
}

impl Print for () {
    fn print(&self) {
        println!("No value");
    }
}

fn main() {
    "Hello, world!".print();
    ().print();
}

со следующей ошибкой:

error[E0119]: conflicting implementations of trait `Print` for type `()`:
  --> src/main.rs:41:1
   |
35 |   impl<T: Display> Print for T {
   |  _- starting here...
36 | |     default fn print(&self) {
37 | |         println!("Value: {}", self);
38 | |     }
39 | | }
   | |_- ...ending here: first implementation here
40 | 
41 |   impl Print for () {
   |  _^ starting here...
42 | |     fn print(&self) {
43 | |         println!("No value");
44 | |     }
45 | | }
   | |_^ ...ending here: conflicting implementation for `()`

пока это компилируется:

pub trait Print {
    fn print(&self);
}

impl<T: Default> Print for T {
    default fn print(&self) {
    }
}

impl Print for () {
    fn print(&self) {
        println!("No value");
    }
}

fn main() {
    "Hello, world!".print();
    ().print();
}

Спасибо за решение этой проблемы.

@antoyo , вы уверены, что это потому, что Display является особенным, или может быть потому, что Display не реализован для кортежей, а Default -?

@shepmaster
Я не знаю, относится ли это к Display , но следующее работает с чертой Custom не реализованной для кортежей:

pub trait Custom { }

impl<'a> Custom for &'a str { }

pub trait Print {
    fn print(&self);
}

impl<T: Custom> Print for T {
    default fn print(&self) {
    }
}

impl Print for () {
    fn print(&self) {
        println!("No value");
    }
}

fn main() {
    "Hello, world!".print();
    ().print();
}

Кстати, вот реальная вещь, которой я хочу добиться со специализацией:

pub trait Emit<C, R> {
    fn emit(callback: C, value: Self) -> R;
}

impl<C: Fn(Self) -> R, R, T> Emit<C, R> for T {
    default fn emit(callback: C, value: Self) -> R {
        callback(value)
    }
}

impl<C> Emit<C, C> for () {
    fn emit(callback: C, _value: Self) -> C {
        callback
    }
}

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

Изменить: я думаю, что понял, почему он не компилируется:
T в for T является более общим, чем () в for () поэтому первый impl не может быть специализацией.
А C является более общим, чем C: Fn(Self) -> R поэтому второй impl не может быть специализацией.
Скажите, пожалуйста, если я ошибаюсь.
Но я до сих пор не понимаю, почему это не работает с первым примером с Display .

В настоящее время это правильное поведение.

В примере Custom эти импликации не перекрываются из-за особых локальных отрицательных аргументов . Поскольку черта взята из этого ящика, мы можем сделать вывод, что () , который не имеет импликации Custom , не перекрывается с T: Custom . Специализация не требуется.

Однако мы не используем это отрицательное рассуждение для черт, не входящих в ваш ящик. Стандартная библиотека может добавить Display for () в следующем выпуске, и мы не хотим, чтобы это было критическим изменением. Мы хотим, чтобы библиотеки имели свободу вносить такие изменения. Поэтому, хотя () не подразумевает Display, мы не можем использовать эту информацию при проверке перекрытия.

Но также, поскольку () не подразумевает Display, он не более конкретен, чем T: Display . Вот почему специализация не работает, тогда как в случае по умолчанию (): Default , следовательно, impl является более конкретным, чем T: Default .

Подобные имплы находятся в каком-то «подвешенном состоянии», и мы не можем предположить, что они совпадают или нет. Мы пытаемся найти принципиальный способ заставить эту работу работать, но это не первая реализация специализации, это расширение с обратной совместимостью для этой функции, которое появится позже.

Я подал № 40582, чтобы отследить проблему надежности, связанную со сроком службы.

У меня возникла проблема при попытке использовать специализацию, я не думаю, что она такая же, как у @antoyo , я подал ее как отдельную проблему # 41140, при необходимости я могу привести здесь пример кода

@ afonso360 Нет, можно отдельный вопрос.

В общем, на данный момент дальнейшая работа по специализации заблокирована для работы над Chalk , что должно позволить нам решить проблемы надежности, а также, вероятно, устранить проблемы с ICE, которые сегодня поражены.

Может кто-нибудь уточнить, баг это или что-то намеренно запрещенное? https://is.gd/pBvefi

@sgrif Я считаю, что проблема здесь в том, что проецирование типов, связанных по умолчанию, запрещено. Хотя диагностика могла бы быть лучше: https://github.com/rust-lang/rust/issues/33481

Не могли бы вы пояснить, почему это должно быть запрещено? Мы знаем, что нельзя добавить какой-либо конкретный импл, поскольку это нарушит правила для сирот.

Этот комментарий указывает на то, что в некоторых случаях это необходимо для обеспечения надежности (хотя я не знаю почему), а в других - для того, чтобы заставить потребителей интерфейса рассматривать его как абстрактный тип: https://github.com/rust- lang / rust / blob / e5e664f / src / librustc / traits / project.rs # L41

Кто-нибудь когда-нибудь мог посмотреть https://github.com/rust-lang/rust/issues/31844#issuecomment -266221638? Насколько я могу судить, эти импы должны быть действительны со специализацией. Я считаю, что есть ошибка, которая их предотвращает.

@sgrif Я считаю, что проблема с вашим кодом может быть аналогична проблеме в https://github.com/rust-lang/rust/issues/31844#issuecomment -284235369, которую @withoutboats объяснил на https://github.com / rust-lang / rust / issues / 31844 # issuecomment -284268302. При этом, основываясь на комментарии @withoutboats , кажется, что нынешняя локальная аргументация должна позволить компилировать ваш пример, но, возможно, я ошибаюсь относительно того, что должно работать.

Кстати, я безуспешно пытался реализовать следующее:

trait Optional<T> {
    fn into_option(self) -> Option<T>;
}

impl<R, T: Into<R>> Optional<R> for T {
    default fn into_option(self) -> Option<R> {
        Some(self.into())
    }
}

impl<R> Optional<R> for Option<R> {
    fn into_option(self) -> Option<R> {
        self
    }
}

Я интуитивно ожидал, что Option<R> будет более конкретным, чем <R, T: Into<R>> T , но, конечно, ничто не помешает impl<R> Into<R> for Option<R> в будущем.

Однако я не уверен, почему это запрещено. Даже если в будущем будет добавлен impl<R> Into<R> for Option<R> , я все равно ожидаю, что Rust выберет реализацию, отличную от default , так что, насколько я могу видеть, разрешение этого кода не влияет на пересылку совместимость.

В целом, мне очень неприятно работать со специализацией. Практически все, что я ожидаю от работы, не работает. Единственные случаи, когда я добился успеха со специализацией, - это очень простые, например наличие двух impl s, включающих T where T: A и T where T: A + B . Мне трудно заставить другие вещи работать, и сообщения об ошибках не указывают, почему попытки специализироваться не работают. Конечно, впереди еще долгий путь, поэтому я не жду очень полезных сообщений об ошибках. Но, похоже, есть довольно много случаев, когда я действительно ожидаю, что что-то сработает (как указано выше), но это просто не так, и в настоящее время мне довольно сложно определить, это потому, что я неправильно понял, что разрешено (и, что более важно, почему), если что-то не так, или если что-то еще не реализовано. Хороший обзор того, что происходит с этой функцией в ее нынешнем виде, был бы очень полезен.

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

Следующий код (который адаптирован из RFC здесь ) не компилируется на каждую ночь:

#![feature(specialization)]

trait Example {
    type Output;
    fn generate(self) -> Self::Output;
}

default impl<T> Example for T {
    type Output = Box<T>;
    fn generate(self) -> Self::Output { Box::new(self) }
}

impl Example for bool {
    type Output = bool;
    fn generate(self) -> Self::Output { self }
}

На самом деле это не похоже на сбой, но больше похоже на проблему удобства использования - если бы гипотетический impl специализировал только связанный тип в приведенном выше примере, defaulti impl из generate не проверка типов.

Ссылка на ветку здесь

@ burns47 здесь есть запутанный, но полезный обходной путь: https://github.com/rust-lang/rust/issues/31844#issuecomment -263175793.

@dtolnay Не совсем удовлетворительно - что, если мы специализируемся на чертах, которыми мы не владеем (и не можем изменять)? Нам не нужно переписывать / рефакторировать определения признаков, чтобы сделать это IMO.

Может ли кто-нибудь прокомментировать, намеренно ли отклонен код в следующем выпуске? https://github.com/rust-lang/rust/issues/45542

Позволит ли специализация добавить в libcore что-то вроде следующего?

impl<T: Ord> Eq for T {}

impl<T: Ord> PartialEq for T {
    default fn eq(&self, other: &Self) -> bool {
        self.cmp(other) == Ordering::Equal
    }
}

impl<T: Ord> PartialOrd for T {
    default fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

Таким образом, вы можете реализовать Ord для своего пользовательского типа и автоматически реализовать Eq , PartialEq и PartialOrd .

Обратите внимание, что реализация Ord и одновременное получение PartialEq или PartialOrd опасно и может привести к очень тонким ошибкам! С этими имплисами по умолчанию у вас будет меньше соблазна получить эти черты, поэтому проблема будет несколько смягчена.

В качестве альтернативы мы модифицируем деривацию, чтобы воспользоваться преимуществами специализации. Например, если написать #[derive(PartialOrd)] выше struct Foo(String) может получиться следующий код:

impl PartialOrd for Foo {
    default fn partial_cmp(&self, other: &Foo) -> Option<Ordering> {
        self.0.partial_cmp(&other.0)
    }
}

impl PartialOrd for Foo where Foo: Ord {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

Таким образом, используется impl по умолчанию, если Ord не реализовано. Но если это так, то PartialOrd полагается на Ord . К сожалению, это не компилируется: error[E0119]: conflicting implementations of trait `std::cmp::PartialOrd` for type `Foo`

@stjepang Я, конечно, надеюсь, что такие одеяла можно будет добавить - тоже impl<T:Copy> Clone for T .

я думаю

impl<T: Ord> PartialEq for T

должно быть

impl<T, U> PartialEq<U> for T where T : PartialOrd<U>

потому что PartialOrd требует PartialEq и тоже может его предоставить.

Прямо сейчас невозможно использовать связанные типы для ограничения специализации, потому что их нельзя оставить неопределенными, и потому что они запускают ненужную рекурсию . См. Https://github.com/dhardy/rand/issues/18#issuecomment -358147645

В конце концов, мне бы хотелось увидеть то, что я называю группами специализации, с синтаксисом, предложенным @nikomatsakis здесь https://github.com/rust-lang/rust/issues/31844#issuecomment -249355377 и независимо от меня. Я хотел бы написать RFC по этому предложению позже, когда мы приблизимся к стабилизации специализации.

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

Поскольку закрытие копий уже было стабилизировано в бета-версии, у разработчиков теперь больше мотивации для стабилизации специализации. Причина в том, что Fn и FnOnce + Clone представляют два перекрывающихся набора замыканий, и во многих случаях нам нужно реализовать трейты для них обоих.

Просто выясните, что формулировка RFC 2132, похоже, подразумевает, что существует только 5 типов замыканий:

• FnOnce (закрытие move при котором все захваченные переменные не являются ни Copy ни Clone )
• FnOnce + Clone (закрытие move со всеми захваченными переменными Clone )
• FnOnce + Copy + Clone (закрытие move со всеми захваченными переменными Copy и поэтому Clone )
• FnMut + FnOnce (закрытие, отличное от move с измененными захваченными переменными)
• Fn + FnMut + FnOnce + Copy + Clone (закрытие, отличное от move без измененных захваченных переменных)

Так что, если спецификация недоступна в ближайшем будущем, возможно, нам следует обновить определение черт Fn чтобы Fn не перекрывался с FnOnce + Clone ?

Я понимаю, что кто-то, возможно, уже реализовал определенные типы, то есть Fn без Copy/Clone , но следует ли это исключить? Я думаю, что всегда есть лучший способ сделать то же самое.

Допускается ли следующее специализация (обратите внимание на отсутствие default ) или это ошибка?

#![feature(specialization)]
mod ab {
    pub trait A {
        fn foo_a(&self) { println!("a"); }
    }

    pub trait B {
        fn foo_b(&self) { println!("b"); }
    }

    impl<T: A> B for T {
        fn foo_b(&self) { println!("ab"); }
    }

    impl<T: B> A for T {
        fn foo_a(&self) { println!("ba"); }
    }
}

use ab::B;

struct Foo;

impl B for Foo {}

fn main() {
    Foo.foo_b();
}

без специализации это невозможно построить с помощью:

error[E0119]: conflicting implementations of trait `ab::B` for type `Foo`:
  --> src/main.rs:24:1
   |
11 |     impl<T: A> B for T {
   |     ------------------ first implementation here
...
24 | impl B for Foo {}
   | ^^^^^^^^^^^^^^ conflicting implementation for `Foo`

@glandium, что там творится? Хороший пример, вот ссылка на игровую площадку: https://play.rust-lang.org/?gist=fc7cf5145222c432e2bd8de1b0a425cd&version=nightly&mode=debug

@glandium, то есть https://github.com/rust-lang/rust/issues/48444

это? в моем примере нет пустого impl.

@glandium

 impl B for Foo {}

@MoSal, но это impl "не пусто", поскольку B добавляет метод с реализацией по умолчанию.

@gnzlbg По определению пусто. Ничего между скобками.

#![feature(specialization)]

use std::borrow::Borrow;

#[derive(Debug)]
struct Bla {
    bla: Vec<Option<i32>>
}

// Why is this a conflict ?
impl From<i32> for Bla {
    fn from(i: i32) -> Self {
        Bla { bla: vec![Some(i)] }
    }
}

impl<B: Borrow<[i32]>> From<B> for Bla {
    default fn from(b: B) -> Self {
        Bla { bla: b.borrow().iter().map(|&i| Some(i)).collect() }
    }
}

fn main() {
    let b : Bla = [1, 2, 3].into();
    println!("{:?}", b);
}

error[E0119]: conflicting implementations of trait `std::convert::From<i32>` for type `Bla`:
  --> src/main.rs:17:1
   |
11 | impl From<i32> for Bla {
   | ---------------------- first implementation here
...
17 | impl<B: Borrow<[i32]>> From<B> for Bla {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Bla`
   |
   = note: upstream crates may add new impl of trait `std::borrow::Borrow<[i32]>` for type `i32` in future versions

Разве специализация не предотвратит возможные конфликты в будущем?

Боже мой, это медленная функция! Похоже, никакого прогресса за более чем два года (конечно, согласно исходному посту). Команда lang отказалась от этого?

@alexreg см. http://aturon.github.io/2018/04/05/sound-specialization/ для получения последней информации о разработке.

@alexreg Оказывается, надежность _хард_. Я считаю, что в настоящее время ведется некоторая работа над идеей «всегда применимых подразумеваемых», так что прогресс есть. См. Https://github.com/rust-lang/rust/pull/49624. Кроме того, я считаю, что рабочая группа по мелу тоже работает над реализацией идеи «всегда применимые имплименты», но я не знаю, насколько далеко это зашло.

После небольшого спора кажется, что можно эффективно реализовать имплицит пересечения уже через взлом, используя specialization и overlapping_marker_traits .

https://play.rust-lang.org/?gist=cb7244f41c040db41fc447d491031263&version=nightly&mode=debug

cc https://github.com/rust-lang/rfcs/pull/2532

Я попытался написать рекурсивную специализированную функцию для реализации эквивалента этого кода C ++:

#include <cassert>
#include <vector>

template<typename T>
size_t count(T elem)
{
    return 1;
}

template<typename T>
size_t count(std::vector<T> vec)
{
    size_t n = 0;
    for (auto elem : vec)
    {
        n += count(elem);
    }
    return n;
}

int main()
{
    auto v1 = std::vector{1, 2, 3};
    assert(count(v1) == 3);

    auto v2 = std::vector{ std::vector{1, 2, 3}, std::vector{4, 5, 6} };
    assert(count(v2) == 6);

    return 0;
}

Я пробовал это:

#![feature(specialization)]

trait Count {
    fn count(self) -> usize;
}

default impl<T> Count for T {
    fn count(self) -> usize {
        1
    }
}

impl<T> Count for T
where
    T: IntoIterator,
    T::Item: Count,
{
    fn count(self) -> usize {
        let i = self.into_iter();

        i.map(|x| x.count()).sum()
    }
}

fn main() {
    let v = vec![1, 2, 3];
    assert_eq!(v.count(), 3);

    let v = vec![
        vec![1, 2, 3],
        vec![4, 5, 6],
    ];
    assert_eq!(v.count(), 6);
}

Но я получаю:

overflow evaluating the requirement `{integer}: Count`

Не думаю, что это должно происходить, потому что impl<T> Count for T where T::Item: Count не должно переполняться.

РЕДАКТИРОВАТЬ: извините, я только что увидел, что об этом уже упоминалось

@Boiethios Ваш

#![feature(specialization)]

trait Count {
    fn count(self) -> usize;
}

impl<T> Count for T {
    default fn count(self) -> usize {
        1
    }
}

impl<T> Count for T
where
    T: IntoIterator,
    T::Item: Count,
{
    fn count(self) -> usize {
        let i = self.into_iter();

        i.map(|x| x.count()).sum()
    }
}

fn main() {
    let v = vec![1, 2, 3];
    assert_eq!(v.count(), 3);

    let v = vec![vec![1, 2, 3], vec![4, 5, 6]];
    assert_eq!(v.count(), 6);
}

Отверстие для надежности еще не устранено?

@alexreg Я так не думаю. См. Http://smallcultfollowing.com/babysteps/blog/2018/02/09/maximally-minimal-specialization-always-applicable-impls/

Я предполагаю, что сейчас все сосредоточены на выпуске ...

Хорошо, спасибо ... похоже, что эта проблема затягивается вечно, но достаточно справедливо. Я знаю, это тяжело. И, к сожалению, сейчас внимание направлено в другое место.

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

@pythonesque Есть обсуждение на https://github.com/rust-lang/rust/pull/42411

Ах, я понимаю, если окажется, что проекция плохо взаимодействует со специализацией в целом. . И действительно, то, что я хочу, имеет привкус «негативных рассуждений» (хотя закрытых черт было бы недостаточно).

К сожалению, я не уверен, действительно ли есть способ делать то, что я хочу без такой функции: я хотел бы иметь связанный тип, который выводит «True», когда два переданных типа, реализующих конкретную черту, синтаксически равны, и «Ложь», когда они не совпадают (случай «Ложь» запускает более затратный поиск признаков, который может определить, равны ли они «семантически»). Единственная реальная альтернатива кажется (мне) - просто всегда выполнять дорогостоящий поиск; Теоретически это нормально, но может быть намного дороже.

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

В любом случае, может быть, это просто признак того, что то, что я хочу сделать, плохо подходит для системы признаков, и мне следует переключиться на какой-то другой механизм, например, макросы: P

И действительно, то, что я хочу, имеет привкус «негативных рассуждений» (хотя закрытых черт было бы недостаточно).

Альтернативой отрицательному рассуждению является требование, чтобы тип реализовывал только одну характеристику закрытого набора характеристик, так что реализации с другими другими характеристиками в наборе не могут перекрываться (например, T реализует одну из { Float | Int | Bool | Ptr } ).

Даже если бы был способ обеспечить это в Rust (которого нет, AFAIK?), Я не думаю, что это решило бы мою проблему. Я хотел бы, чтобы пользователи в разных ящиках могли реализовывать произвольное количество новых констант, которые должны сравниваться равными только самим себе и не равными любой другой определенной константе, включая те, которые неизвестны во время определения ящика. Я не понимаю, как какой-либо закрытый набор черт (или даже набор семейств черт) может достичь этой цели сам по себе: это проблема, которую принципиально нельзя решить, не глядя непосредственно на типы. Причина, по которой это будет работать с проекциями по умолчанию, заключается в том, что вы можете по умолчанию все, чтобы «не сравнивать равные», а затем реализовать равенство вашей новой константы самой себе в любом ящике, в котором вы определили константу, что не будет мешать сироте rules, потому что все типы в реализации трейта были в одном ящике. Если бы я хотел почти любое такое правило, кроме равенства, даже это не сработало бы, но равенства для меня достаточно :)

В настоящее время каждую ночь это работает:

trait Foo {}
trait Bar {}

impl<T: Bar> Foo for T {}
impl Foo for () {}

но даже со специализацией и ночным использованием этого не происходит:

#![feature(specialization)]

trait Foo<F> {}
trait Bar<F> {}

default impl<F, T: Bar<F>> Foo<F> for T {}
impl<F> Foo<F> for () {}

Есть ли в этом причина или это ошибка?

@rmanoka Разве это не обычные правила для сирот? В первом случае ни один нижний ящик не может impl Bar for () поэтому компилятор позволяет это, но во втором примере нижний ящик может impl Bar<CustomType> for () что будет конфликтовать с вашим imp по умолчанию.

@Boscop В этом сценарии imp по умолчанию в любом случае должен быть заменен не по умолчанию ниже. Например, если бы у меня было: impl Bar<bool> for () {} добавленное перед другими имплементациями, я бы ожидал, что это сработает (согласно RFC / ожиданию). Не правда ли?

Углубляясь в рассуждения о контрпримере, который вы упомянули, я понимаю (или верю), что этот пример удовлетворяет критерию «всегда применимость» и, возможно, над ним работают.

Эта проблема, вероятно, зависит от # 45814.

Есть ли какие-либо планы по поддержке границ черт по умолчанию, которых нет в специализации?

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

#![feature(specialization)]
trait Handler<M> {
    fn handle(&self, m:M);
}

struct Inner;
impl Handler<f64> for Inner {
    fn handle(&self, m : f64) {
        println!("inner got an f64={}", m);
    }
}

struct Struct<T>(T);
impl<T:Handler<M>, M:std::fmt::Debug> Handler<M> for Struct<T> {
    default fn handle(&self, m : M) {
        println!("got something else: {:?}", m);
        self.0.handle(m)
    }
}
impl<T> Handler<String> for Struct<T> {
    fn handle(&self, m : String) {
        println!("got a string={}", m);
    }
}
impl<T> Handler<u32> for Struct<T> {
    fn handle(&self, m : u32) {
        println!("got a u32={}", m);
    }
}

fn main() {
    let s = Struct(Inner);
    s.handle("hello".to_string());
    s.handle(5.0 as f64);
    s.handle(5 as u32);
}

Кроме того, в приведенном выше примере я испытал нечто странное - после удаления признака, привязанного к обработчику по умолчанию impl (а также self.0.handle (m)), код компилируется без проблем. Однако, когда вы удаляете реализацию для u32, похоже, нарушается вывод другого признака:

#![feature(specialization)]
trait Handler<M> {
    fn handle(&self, m:M);
}

struct Struct<T>(T);
impl<T, M:std::fmt::Debug> Handler<M> for Struct<T> {
    default fn handle(&self, m : M) {
        println!("got something else: {:?}", m);
    }
}
impl<T> Handler<String> for Struct<T> {
    fn handle(&self, m : String) {
        println!("got a string={}", m);
    }
}
// impl<T> Handler<u32> for Struct<T> {
//     fn handle(&self, m : u32) {
//         println!("got a u32={}", m);
//     }
// }
fn main() {
    let s = Struct(());
    s.handle("hello".to_string());
    s.handle(5.0 as f64);
}

Несмотря на то, что нет кода, вызывающего обработчик для u32, отсутствие специализации приводит к тому, что код не компилируется.

Изменить: похоже, это то же самое, что и вторая проблема («Однако, когда вы удаляете реализацию для u32, это, кажется, нарушает вывод другого признака»), Глэдди упомянула один пост назад.

При использовании rustc 1.35.0-nightly (3de010678 2019-04-11) следующий код выдает ошибку:

#![feature(specialization)]
trait MyTrait<T> {
    fn print(&self, parameter: T);
}

struct Message;

impl<T> MyTrait<T> for Message {
    default fn print(&self, parameter: T) {}
}

impl MyTrait<u8> for Message {
    fn print(&self, parameter: u8) {}
}

fn main() {
    let message = Message;
    message.print(1_u16);
}

ошибка:

error[E0308]: mismatched types
  --> src/main.rs:20:19
   |
18 |     message.print(1_u16);
   |                   ^^^^^ expected u8, found u16

Однако код компилируется и работает, когда я опускаю блок impl MyTrait<u8> :

#![feature(specialization)]
trait MyTrait<T> {
    fn print(&self, parameter: T);
}

struct Message;

impl<T> MyTrait<T> for Message {
    default fn print(&self, parameter: T) {}
}

/*
impl MyTrait<u8> for Message {
    fn print(&self, parameter: u8) {}
}
*/

fn main() {
    let message = Message;
    message.print(1_u16);
}

Это намеренно, потому что реализация не завершена, или это ошибка?

Кроме того, я хотел бы знать, будет ли поддерживаться этот вариант использования для специализации (реализация черт с перекрывающимися параметрами типа для одного конкретного типа, в отличие от реализации той же черты для перекрывающихся типов). Читая раздел «Определение правил приоритета» в RFC 1210, я думаю, что он будет поддерживаться, но RFC не дает таких примеров, и я не знаю, строго ли мы все еще строго следуем этому RFC.

Сообщить о странности:

trait MyTrait {}
impl<E: std::error::Error> MyTrait for E {}

struct Foo {}
impl MyTrait for Foo {}  // OK

// But this one is conflicting with error message:
//
//   "... note: upstream crates may add new impl of trait `std::error::Error` for type
//    std::boxed::Box<(dyn std::error::Error + 'static)>` in future versions"
//
// impl MyTrait for Box<dyn std::error::Error> {}

Почему в этом случае Box<dyn std::error::Error> особенный (избегайте использования слова "специальный")? Даже если это подразумевает std::error::Error в будущем, impl MyTrait for Box<dyn std::error::Error> по-прежнему является действительной специализацией impl<E: std::error::Error> MyTrait for E , не так ли?

все еще действующая специализация

В вашем случае impl<E: std::error::Error> MyTrait for E не может быть специализированным, поскольку у него нет методов default .

@ bjorn3 Похоже, это должно работать, но это не так, даже если вы добавите фиктивные методы

в ящике bar

pub trait Bar {}
impl<B: Bar> Bar for Box<B> {}

В ящике foo

#![feature(specialization)]

use bar::*;

trait Trait {
    fn func(&self) {}
}

impl<E: Bar> Trait for E {
    default fn func(&self) {}
}

struct Foo;
impl Trait for Foo {}  // OK

impl Trait for Box<dyn Bar> {} // Error error[E0119]: conflicting implementations of trait

Обратите внимание: если вы измените crate bar на

pub trait Bar {}
impl<B: ?Sized + Bar> Bar for Box<B> {}

Затем скомпилирует foo .

@ bjorn3 Похоже, что нам не нужен метод default чтобы его специализировать ( игровая площадка ).

@KrishnaSannasi Я не могу воспроизвести ошибку "конфликтующие реализации" в вашем примере ( детская площадка ).

Обновление: О, понятно. Чтобы пример работал, трейт Bar должен быть из апстрима.

@updogliu ваш пример не показывает специализацию, потому что Foo не реализует Error .

Я программирую сегодня слишком поздно, или это не должно вызывать переполнение стека?

#![feature(specialization)]
use std::fmt::Debug;

trait Print {
    fn print(self);
}

default impl<T> Print for [T; 1] where T: Debug {
    fn print(self) {
        println!("{:?}", self);
    }
}

impl<T> Print for [T; 1] where T: Debug + Clone {
    fn print(self) {
        println!("{:?}", self.clone());
    }
}

fn main() {
    let x = [0u8];
    x.print();
}

Ссылка на игровую площадку

Крупнозернистые блоки default impl всегда делали для меня очень странные вещи, я бы предложил вместо этого попробовать синтаксис мелкозернистой специализации default fn .

РЕДАКТИРОВАТЬ: это ожидается при перекрестной проверке RFC, поскольку default impl самом деле _не_ означает, что все элементы в блоке impl являются default ed. Я считаю эту семантику удивительной, если не сказать больше.

Ссылка на игровую площадку

@ HadrienG2 На самом деле я всегда использовал default fn в этом проекте, но на этот раз я забыл ключевое слово default и компилятор предложил добавить его в impl . Раньше не видел проблемы с рекурсией стека и не был уверен, ожидалось ли это на данном этапе. Спасибо за предложение, default fn отлично работает.

В исходном RFC есть раздел, посвященный специализации встроенных импов. Кто-то дал мне попробовать?

Подход, предложенный в RFC, может больше не работать напрямую, по крайней мере, для внутренних методов const:

// This compiles correctly today:
#![feature(specialization)] 
use std::marker::PhantomData;
struct Foo<T>(PhantomData<T>);
impl<T> Foo<T> {
    default const fn foo() -> Self { Self(PhantomData) }
    // ^^should't default here error?
}
// ----
// Adding this fails:
impl<T: Copy> Foo<T> {
    const fn foo() -> Self { Self(PhantomData) }
}

Исходный RFC предлагает преобразовать метод в типаж, реализовать его для типа и специализовать impl. Я полагаю, что для методов const fn эти impls признака для типа должны быть const impls.

Для тех, кто сталкивается с этим и интересуется статусом, в 2018 году было сделано несколько значительных концептуальных достижений:
http://smallcultfollowing.com/babysteps/blog/2018/02/09/maximally-minimal-specialization-always-applicable-impls/
http://aturon.github.io/tech/2018/04/05/sound-specialization/

Совсем недавно, в прошлом месяце, @nikomatsakis написал (например, в другом контексте; полужирный шрифт), что:

была одна ключевая проблема [в специализации], которая так и не была решена удовлетворительно, проблема технической надежности в отношении продолжительности жизни и характеристик [...] Затем [эти два сообщения, ссылки на которые приведены выше]. Похоже, что эти идеи в основном решили проблему , но пока что мы были заняты, и у нас не было времени на дальнейшие действия.

Звучит обнадеживающе, хотя явно есть над чем поработать.

(Публикуя это, потому что я нашел эту ветку несколько недель назад и понятия не имел о прогрессе за прошлый год, то совсем недавно случайно наткнулся на эти сообщения. Выше есть комментарии, в которых они упоминаются, но на GitHub становится все труднее увидеть какие-либо, кроме первых и последние несколько комментариев к длинной цепочке: cry:. Было бы полезно, если бы это обновление было включено в описание проблемы.)

Привет всем! Может ли кто-нибудь сказать мне, почему этот вариант использования не работает? Ошибки или ожидаемое поведение?

Как этот пример . impl A for i32 в порядке, но impl A for () не может быть скомпилирован в 1.39.0-nightly.

#![feature(specialization)]

trait A {
    fn a();
}

default impl <T: ToString> A for T {
    fn a() {}
}

impl A for i32 {
    fn a() {}
}

impl A for () {
    fn a() {}
}

составление сообщения:

error[E0119]: conflicting implementations of trait `A` for type `()`:
  --> src/lib.rs:16:1
   |
8  | default impl <T: ToString> A for T {
   | ---------------------------------- first implementation here
...
16 | impl A for () {
   | ^^^^^^^^^^^^^ conflicting implementation for `()`
   |
   = note: upstream crates may add new impl of trait `std::fmt::Display` for type `()` in future versions

@Hexilee Поместите default в методы, а не в имп.

@KrishnaSannasi, пример 2

@zserik да, я знаю. Я не думаю, что это было реализовано, или от него отказались. Во всяком случае сейчас не работает.

Очевидно, сейчас это не работает, но я думаю, что должно работать.

Я спрашиваю об этом здесь, потому что я не заметил, чтобы эта тема поднималась где-либо еще - есть ли какие-либо планы по default -ифицировать различные функции стандартной библиотеки, аналогично тому, как у нас есть const -ified функции, когда это считается безопасным? Основная причина, по которой я спрашиваю, заключается в том, что общие реализации From и Into по умолчанию ( impl<T, U: From<T>> Into<U> for T и impl<T> From<T> for T ) затрудняют написание всеобъемлющего универсального From Реализации Into ниже по течению от core , и было бы неплохо, если бы я мог переопределить эти преобразования в моих собственных ящиках.

Даже если мы разрешим специализацию для From / Into это не поможет универсальным имплементам из-за проблемы с решеткой.

@KrishnaSannasi Я не верю, что это так. Например, этот код должен работать, если From и Into были специализированными, но не потому, что они не являются:

impl<M: Into<[S; 2]>, S> From<M> for GLVec2<S> {
    fn from(to_array: M) -> GLVec2<S> {
        unimplemented!()
    }
}
impl<M, S> Into<M> for GLVec2<S>
where
    [S; 2]: Into<M>,
{
    fn into(self) -> M {
        unimplemented!()
    }
}

pub struct GLVec2<S> {
    pub x: S,
    pub y: S,
}

Это работает, если вы конвертируете From и Into в настраиваемую черту, которая не имеет этих общих реализаций: https://play.rust-lang.org/?version=stable&mode=debug&edition= 2018 & gist = cc126b016ff62643946aebc6bab88c98

@Osspial Что ж, если вы попытаетесь смоделировать с использованием имплементации по умолчанию, вы увидите проблему,

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e5b9da0eeca05d063e2605135a0b5ead

Я повторюсь, изменение From/Into impl на значение по умолчанию impl в стандартной библиотеке не сделает возможными универсальные impls для Into . (и это не влияет на общие импликации From )

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

Этот шаблон прост - мы можем определять такие структуры, как WithLabel или WithID которые добавляют некоторые поля и методы к базовым структурам, поэтому, например, если мы создадим WithLabel<WithID<MyType>> тогда мы сможем чтобы получить id , label и все поля / методы MyType . К сожалению, в текущей реализации это невозможно.

Ниже приведен пример кода, показывающий использование этого шаблона. Закомментированный код не компилируется, но он должен сделать этот шаблон действительно полезным:

#![feature(specialization)]

use std::ops::Deref;
use std::ops::DerefMut;

// =================
// === WithLabel ===
// =================

struct WithLabel<T>(String, T);

pub trait HasLabel {
    fn label(&self) -> &String;
}

impl<T> HasLabel for WithLabel<T> {
    fn label(&self) -> &String { 
        &self.0
    }
}

// THIS SHOULD COMPILE, BUT GETS REJECTED
// impl<T> HasLabel for T
// where T: Deref, <Self as Deref>::Target : HasLabel {
//     default fn label(&self) -> &String { 
//         self.deref().label() 
//     }
// }

impl<T> Deref for WithLabel<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.1
    }
}

// ==============
// === WithID ===
// ==============

struct WithID<T>(i32, T);

pub trait HasID {
    fn id(&self) -> &i32;
}

impl<T> HasID for WithID<T> {
    fn id(&self) -> &i32 { 
        &self.0
    }
}

// THIS SHOULD COMPILE, BUT GETS REJECTED
// impl<T> HasID for T
// where T: Deref, <Self as Deref>::Target : HasID {
//     default fn id(&self) -> &i32 { 
//         self.deref().id() 
//     }
// }

impl<T> Deref for WithID<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.1
    }
}

// =============
// === Usage ===
// =============

struct A(i32);

type X = WithLabel<WithID<A>>;

fn test<T: HasID + HasLabel> (t: T) {
    println!("{:?}", t.label());
    println!("{:?}", t.id());
}

fn main() {
    let v1 = WithLabel("label1".to_string(), WithID(0, A(1)));
    // test(v1); // THIS IS EXAMPLE USE CASE WHICH DOES NOT COMPILE
}

Для того, чтобы строка test(v1) работала, нам нужно добавить такой трейт impl вручную:

impl<T: HasID> HasID for WithLabel<T> {
    fn id(&self) -> &i32 { 
        self.deref().id()
    }
}

Конечно, чтобы сделать его полным, нам также нужно сделать эту черту подразумевающей:

impl<T: HasLabel> HasLabel for WithID<T> {
    fn label(&self) -> &String { 
        self.deref().label()
    }
}

И это ОЧЕНЬ ПЛОХО . Всего для 2-х типов это просто. Однако представьте, что у нас есть 10 различных определений непрозрачных типов, которые добавляют разные поля, например WithID , WithLabel , WithCallback , ... вы называете это. При текущем поведении специализаций нам нужно будет определить ... более 1000 различных реализаций трейтов! Если закомментированный код будет принят, нам потребуется всего 10 реализаций признаков, а для реализации каждого нового типа потребуется только одна дополнительная реализация .

Я не уверен, как ваш код связан со специализацией. Ваш аргумент (ваш исходный код компилируется, но закомментированная строка test(v1); не компилируется без представленного вами руководства) по-прежнему применяется, если первая строка #![feature(specialization)] удалена.

@qnighy Код должен компилироваться после раскомментирования impls HasLabel for T и HasID for T - они используют специализацию. В настоящее время они отклонены (попробуйте раскомментировать их в предоставленном мной коде!). Теперь это имеет для вас смысл? 🙂

Рассмотрим три экземпляра WithLabel<WithID<A>> , WithID<WithLabel<A>> и WithLabel<WithLabel<A>> . потом

• первый имп охватывает WithLabel<WithID<A>> и WithLabel<WithLabel<A>> .
• второй имп покрывает WithID<WithLabel<A>> и WithLabel<WithLabel<A>> .

Поэтому пара impls не удовлетворяет следующему пункту RFC :

Чтобы гарантировать согласованность специализации, мы гарантируем, что для любых двух пересекающихся импов I и J у нас будет либо I < J или J < I . То есть одно должно быть действительно более конкретным, чем другое.

И в вашем случае это тоже настоящая проблема, потому что HasLabel impl из WithLabel<WithLabel<A>> можно интерпретировать двояко.

Как мы можем решить этот случай, уже обсуждается в RFC , и вывод такой:

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

@qnighy , спасибо, что подумал об этом.

И это реальная проблема и в вашем случае, потому что импликация HasLabel WithLabel<WithLabel<A>> может быть интерпретирована двояко.

Это верно, если мы не считаем impl<T> HasLabel for WithLabel<T> более специализированным, чем impl<T> HasLabel for T для ввода WithLabel<WithLabel<A>> . Часть RFC, которую вы вставили, действительно охватывает это, однако я считаю, что это серьезное ограничение, и я бы попросил пересмотреть поддержку этого варианта использования в первом выпуске этого расширения.

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

Хорошо то, что сейчас компилируется все (включая специализации), но не использование test(v1) :

#![feature(specialization)]
#![feature(optin_builtin_traits)]

use std::ops::Deref;
use std::ops::DerefMut;

// =================
// === WithLabel ===
// =================

struct WithLabel<T>(String, T);

auto trait IsNotWithLabel {}
impl<T> !IsNotWithLabel for WithLabel<T> {}

pub trait HasLabel {
    fn label(&self) -> &String;
}

impl<T> HasLabel for WithLabel<T> {
    fn label(&self) -> &String { 
        &self.0
    }
}

impl<T> HasLabel for T
where T: Deref + IsNotWithLabel, <Self as Deref>::Target : HasLabel {
    default fn label(&self) -> &String { 
        self.deref().label() 
    }
}

impl<T> Deref for WithLabel<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.1
    }
}

// ==============
// === WithID ===
// ==============

struct WithID<T>(i32, T);

pub trait HasID {
    fn id(&self) -> &i32;
}

impl<T> HasID for WithID<T> {
    fn id(&self) -> &i32 { 
        &self.0
    }
}

auto trait IsNotWithID {}
impl<T> !IsNotWithID for WithID<T> {}

impl<T> HasID for T
where T: Deref + IsNotWithID, <Self as Deref>::Target : HasID {
    default fn id(&self) -> &i32 { 
        self.deref().id() 
    }
}

impl<T> Deref for WithID<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.1
    }
}

// =============
// === Usage ===
// =============

struct A(i32);

type X = WithLabel<WithID<A>>;

fn test<T: HasID + HasLabel> (t: T) {
    println!("{:?}", t.label());
    println!("{:?}", t.id());
}

fn main() {
    let v1 = WithLabel("label1".to_string(), WithID(0, A(1)));
    test(v1);
}

Тем временем вы можете использовать RFC1268 overlapping_marker_traits чтобы разрешить перекрывающиеся

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b66ee0021db73efaaa5d46edfb4f3990

@qnighy Я создал отдельную проблему по поводу этой ошибки: https://github.com/rust-lang/rust/issues/66041

Хорошо, я только что обнаружил, что auto traits никогда не будет здесь решением, поскольку (согласно https://doc.rust-lang.org/nightly/unstable-book/language-features/optin-builtin-traits. html) они распространяются на все поля в структуре:

Автоматические свойства, такие как Send или Sync в стандартной библиотеке, являются характеристиками-маркерами, которые автоматически реализуются для каждого типа, если только тип или тип, который он содержит, явно не отключен через отрицательный impl.

РЕДАКТИРОВАТЬ
@qnighy как-то упустил из виду, что вы дали ссылку на детскую площадку. ❤️ Большое спасибо за это. Это работает, и я поражен тем, насколько хакерским является это решение. Удивительно, что мы можем выразить это сейчас, и я надеюсь, что эта возможность не исчезнет в будущем!

В такой ситуации overlapping marker traits - единственный хак, который мы можем использовать сейчас, но я думаю, было бы неплохо разрешить в будущем какое-то более простое решение для выражения непрозрачных типов (как описано в моем предыдущем посте: https : //github.com/rust-lang/rust/issues/31844#issuecomment-549023367).

Очень простой пример (упрощение приведенного выше примера ), который не работает:

trait Trait<T> {}
impl<T> Trait<T> for T {}
impl<T> Trait<()> for T {}

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

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

Для тех, кто еще не знает: dtolnay обнаружил удивительный трюк, который позволяет использовать (очень ограниченную) специализацию на стабильной ржавчине.

Я не уверен, было ли это уже решено, но черты с реализациями по умолчанию для их методов должны быть переопределены, чтобы их можно было пометить как default . Пример;

trait Trait {
    fn test(&self) { println!("default implementation"); }
}

impl<T> Trait for T {
    // violates DRY principle
    default fn test(&self) { println!("default implementation"); }
}

Я предлагаю следующий синтаксис, чтобы исправить это (если это нужно исправить):

impl<T> Trait for T {
    // delegates to the already existing default implementation
    default fn test(&self);
}

Перемещено в # 68309

@jazzfool Пожалуйста, укажите это как проблему (обычно относится ко всем, кто задает подобные вопросы здесь) и

Есть ли подход к специализации тестирования? Например, при написании теста, который проверяет правильность специализации, вам сначала нужно знать, действительно ли применяется специализация, которую вы пытаетесь проверить, вместо реализации по умолчанию.

@ the8472 вы имеете в виду тестирование компилятора или тестирование в вашем собственном коде? Вы, конечно, можете написать модульные тесты, которые будут вести себя по-другому (например, вызвать fn и посмотреть, получите ли вы специализированный вариант). Возможно, вы говорите, что эти два варианта эквивалентны, за исключением того, что один должен быть быстрее, и, следовательно, вы не знаете, как проверить, какую версию вы получаете? В таком случае, я согласен, я не знаю, как вы можете это проверить прямо сейчас.

Я мог бы предположить, что вы можете создать какой-нибудь другой трейт с тем же набором impl, но где fns будут вести себя по-другому, просто чтобы успокоить себя.

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

Вы можете проверить это с помощью макроса. Я немного заржавел со своим Rust, но что-то в этом роде ...

[#cfg(test)]
static mut SPECIALIZATION_TRIGGERED : bool = false;

[#cfg(test)]
macro_rules! specialization_trigger {
    () =>  { SPECIALIZATION_TRIGGERED = true; };
}

[#cfg(not(test))]
macro_rules! specialization_trigger {
    () => {};
}

Затем используйте specialization_trigger!() в специализированном impl, а в тестах используйте assert!(SPECIALIZATION_TRIGGERED);

[#cfg(test)]
static mut SPECIALIZATION_TRIGGERED : bool = false;
...

Вы захотите использовать thread_local! { static VAR: Cell<bool> = Cell::new(false); } вместо static mut потому что в противном случае переменная может быть установлена ​​в одном потоке тестового примера и ошибочно прочитана из другого потока. Также не забудьте сбрасывать переменную в начале каждого теста, иначе вы получите true из предыдущего теста.

У меня есть вопрос по тексту RFC, надеюсь, это хорошее место.

В разделе повторного использования приведен этот пример:

trait Add<Rhs=Self> {
    type Output;
    fn add(self, rhs: Rhs) -> Self::Output;
    fn add_assign(&mut self, rhs: Rhs);
}

// the `default` qualifier here means (1) not all items are implied
// and (2) those that are can be further specialized
default impl<T: Clone, Rhs> Add<Rhs> for T {
    fn add_assign(&mut self, rhs: Rhs) {
        let tmp = self.clone() + rhs;
        *self = tmp;
    }
}

Интересно, как это предполагается для проверки типа, учитывая, что tmp имеет тип Self::Output и ничего не известно об этом связанном типе. Текст RFC, похоже, не объясняет этого, по крайней мере, нигде рядом с тем, где приводится пример.

Есть ли здесь какой-то механизм, который должен / должен был заставить это работать?

Может ли это значение по умолчанию быть ограничено where T: Add<Output = T> ? Или это петля причинно-следственной связи?

@RalfJung Я согласен, это кажется неправильным.

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

Пожалуйста, не отменяйте реализацию. Сломанные, несостоятельные и неполные по-прежнему позволяют экспериментировать.

Если это правда, должны ли мы просто отменить реализацию этой и других функций (например, GAT) до тех пор, пока они не будут должным образом переделаны?

Пожалуйста, не надо, PyO3 (библиотека привязок Python) в настоящее время зависит от специализации. См. Https://github.com/PyO3/pyo3/issues/210

Разве от этого не зависит и изрядное количество std ? Хотя я вспомнил, что видел много специализированных внутренних реализаций для векторных и строковых вещей. Не то чтобы это должно предотвратить отмену реализации, просто это будет не так просто, как удалить соответствующие разделы из средства проверки типов.

@Lucretiel: да, многие полезные оптимизации (особенно вокруг итераторов) зависят от специализации, поэтому ее реализация была бы огромной регрессией в производительности.

Например, FusedIterator и TrustedLen бесполезны без специализации.

PyO3 (библиотека привязок Python) в настоящее время зависит от специализации

Это страшно, из-за «некачественной» детали. В стандартной библиотеке были критические ошибки надежности из-за неправильной специализации. Насколько вы уверены, что у вас нет таких же ошибок? Попробуйте вместо этого использовать min_specialization , мы надеемся, что это по крайней мере менее опасно.

Возможно, specialization должно получить предупреждение, подобное const_generics котором говорится, что «эта функция неполная, ненадежная и неисправная, не используется в производстве ».

многие полезные оптимизации (особенно в отношении итераторов) зависят от специализации, поэтому ее реализация была бы огромной регрессией в производительности.

В наши дни они зависят от min_specialization (см., Например, https://github.com/rust-lang/rust/pull/71321), в котором закрыты самые большие дыры в надежности.

@nikomatsakis

Я согласен, это кажется неправильным.

Есть идеи, что это за код? Сначала я подумал, что default impl предназначено также для установки type Output = Self; , но это фактически невозможно в предлагаемом RFC . Так, может быть, намеревались привязать Output = T ?

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

Я не смог найти упоминания о min_specialization этой проблеме отслеживания за пределами PR # 71321 - и, согласно книге Unstable, это проблема отслеживания для этой функции.

Я тоже мало что знаю об этой функции, я только что видел исправления корректности libstd. Он был представлен на https://github.com/rust-lang/rust/pull/68970, что объясняет еще несколько вещей об этом.

@matthewjasper, есть ли смысл задокументировать это еще немного и попросить еженощных пользователей feature(specialization) выполнить миграцию?

Вроде как минимум должно быть предупреждение. Похоже, что эта функция явно нарушена и опасна для использования в ее текущем состоянии.

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

@RalfJung

Есть идеи, что это за код?

Что ж, в какой-то момент мы рассматривали режим, в котором значения по умолчанию могут зависеть друг от друга. Поэтому я полагаю, что в этот момент сработало бы следующее:

default impl<T: Clone, Rhs> Add<Rhs> for T {
    type Output = T;

    fn add_assign(&mut self, rhs: Rhs) {
        let tmp = self.clone() + rhs;
        *self = tmp;
    }
}

Предостережение заключалось в том, что если вы переопределяете какой-либо член impl , вам придется переопределить их все . Позже мы отказались от этой идеи, а затем принялись за различные итерации, такие как «группы по умолчанию» (которые также будут работать здесь), и в конечном итоге не приняли никакого решения, потому что полагали, что сможем добраться до него позже, когда разберемся с другая, э-э, насущные проблемы (cc # 71420).

Пожалуйста, не надо, PyO3 (библиотека привязок Python) в настоящее время зависит от специализации. См. PyO3 / pyo3 # 210

Сопровождающий PyO3 - мы за отход от специализации, чтобы перейти на стабильный Rust. Будет ли стабилизироваться min_specialization до завершения остальной специализации?

Я думаю, что на совещании по планированию языкового дизайна издания 2021 года было некоторое обсуждение попытки стабилизировать min_specialization (оно есть на YouTube; извините, я говорю по телефону, или я бы попытался найти ссылку). Я забыл, что они говорили об этом

Я думаю, что на совещании по планированию языкового дизайна издания 2021 года было некоторое обсуждение попытки стабилизировать min_specialization (оно есть на YouTube; извините, я говорю по телефону, или я бы попытался найти ссылку). Я забыл, что они говорили об этом

Думаю, это правильная ссылка на YouTube: https://youtu.be/uDbs_1LXqus
(также на моем телефоне)

Ага, вот и все. Вот ссылка на конкретное обсуждение: https://youtu.be/uDbs_1LXqus?t=2073

Я использовал #[min_specialization] в экспериментальной библиотеке, которую разрабатываю, поэтому решил поделиться своим опытом. Цель состоит в том, чтобы использовать специализацию в ее простейшей форме: иметь несколько узких случаев с более быстрой реализацией, чем общий случай. В частности, чтобы криптографические алгоритмы в общем случае работали в постоянное время, но затем, если все входы помечены Public чтобы иметь специализированную версию, которая работает в более быстром переменном времени (потому что, если они являются общедоступными, мы не заботиться об утечке информации о них во время выполнения). Кроме того, некоторые алгоритмы работают быстрее в зависимости от того, нормализована точка эллиптической кривой или нет. Чтобы заставить это работать, мы начнем с

#![feature(rustc_attrs, min_specialization)]

Затем, если вам нужно создать черту _specialization predicate_, как описано в разделе с максимальной минимальной специализацией, вы помечаете объявление свойства с помощью #[rustc_specialization_trait] .

Вся моя специализация сделана в этом файле, и вот пример признака предиката специализации.

Функция работает и делает именно то, что мне нужно. Очевидно, что здесь используется внутренний маркер rustc, поэтому он может сломаться без предупреждения.

Единственный негативный отзыв заключается в том, что я не чувствую смысла в ключевом слове default . По сути, default означает прямо сейчас: «этот имплт является специализированным, поэтому интерпретируйте имплант, который покрывает подмножество этого имплантата, как его специализацию, а не конфликтующий имплант». Проблема в том, что это приводит к очень странному виду кода:

https://github.com/LLFourn/secp256kfun/blob/6766b60c02c99ca24f816801fe876fed79643c3a/secp256kfun/src/op.rs#L196 -L206

Здесь второй impl специализируется на первом, но это тоже default . Значение default кажется утерянным. Если вы посмотрите на остальные имплы, то довольно сложно понять, какие имплы на каких специализируются. Более того, когда я сделал ошибочный имплимент, который перекрывался с существующим, часто было трудно понять, где я ошибся.

Мне кажется, это было бы проще, если бы все было специализированным, и когда вы специализируете что-то, вы четко заявляете, что подразумевает, что вы специализируетесь. Преобразование примера из RFC в то, что я имел в виду:

impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>
{
    // no need for default
    fn extend(&mut self, iterable: T) {
        ...
    }
}

// We declare explicitly which impl we are specializing repeating all type bounds etc
specialize impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>
    // And then we declare explicitly how we are making this impl narrower with ‘when’.
    // i.e. This impl is like the first except replace all occurances of ‘T’ with ‘&'a [A]’
    when<'a> T = &'a [A]
{
    fn extend(&mut self, iterable: &'a [A]) {
        ...
    }
}

Спасибо за ответ.

Мой комментарий здесь , в частности , пункт 6, обеспечивает случай бетона в стандартной библиотеке , где она может быть желательно иметь специализацию, которая лишь частично переопределение: IndexSet потребуется отчетливый Output типа , потому что IndexSet можно реализовать без Index , но мы, вероятно, не хотим, чтобы два типа сосуществовали с разными типами Output . Поскольку IndexSet может иметь реализацию по умолчанию в терминах IndexMut , было бы разумно разрешить специализацию метода index_set не допуская специализации Output .

У меня проблемы с видео, поэтому я не могу найти связанное видео, однако у меня есть один вопрос по поводу #[min_specialization] . Как есть, существует атрибут rustc_unsafe_specialization_marker для таких свойств, как FusedIterator которые предоставляют подсказки по оптимизации, чтобы их можно было специализировать. @matthewjasper написал:

Это необоснованно, но мы позволяем это в краткосрочной перспективе, потому что это не может вызвать использование после освобождения с чисто безопасным кодом так же, как специализация на методах свойств.

Я предполагаю, что план состоит в том, чтобы реализовать предложение @aturon и добавить модальность специализации для таких черт, как эти ( where specialize(T: FusedIterator) ). Но в настоящее время кажется, что любой код может специализироваться на этих чертах . Если он стабилизируется как есть, люди могут писать стабильные специализации, которые зависят от него, а это означает, что эта несостоятельность будет стабилизирована.

Должна ли тогда специализация на этих чертах также ограничиваться стандартной библиотекой? Достаточно ли преимуществ для стандартной библиотеки дает возможность специализироваться на них?

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

Насколько я понимаю, min_specialization as-is не предназначен для стабилизации.

Во-вторых, я хотел бы иметь какой-то маркер по специализации имп. Было довольно много случаев, когда код в rustc и стандартной библиотеке не выполнял то, как выглядит, потому что нет никакого способа узнать, что на самом деле происходит специализация:

Ненужная специализация Copy :
https://github.com/rust-lang/rust/pull/72707/files#diff -3afa644e1d09503658d661130df65f59L1955

«Специализация», которой нет:
https://github.com/rust-lang/rust/pull/71321/files#diff -da456bd3af6d94a9693e625ff7303113L1589

Реализация, сгенерированная макросом, если не передан флаг, переопределяющий значение по умолчанию impl:
https://github.com/rust-lang/rust/pull/73851/files?file-filters%5B%5D=#diff -ebb36dd2ac01b28a3fff54a1382527ddR124

@matthewjasper последняя ссылка не

Я не уверен, что это явная цель, но тот факт, что AIUI не помечает специализированные импы, дает возможность избежать нарушения изменений в общих имплиентах. Новый default impl<T> Trait for T не конфликтует с последующими импами - они просто становятся специализированными.

Может ли это быть предупреждением, только если он не помечен?

Было довольно много случаев, когда код в rustc и стандартной библиотеке не выполнял то, как выглядит, потому что нет способа узнать, что на самом деле происходит специализация.

Мой опыт работы с java аналогичен (хотя и не совсем аналогичен). Может быть сложно определить, какой подкласс класса фактически запущен ...

Но нам бы тоже нужен маркер на специализированных имплиентах, также для ясности при чтении, верно?

Мы могли бы разместить маркеры в обоих местах, что затем улучшило бы сообщения об ошибках или предупреждениях rustc, потому что теперь они знают, нужна ли специализация, и могут указывать на другое место, если оно существует.

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

Я думаю, что разница может быть слишком большой, чтобы показать изменение. Это указывает на это: https://github.com/rust-lang/rust/blob/fb818d4321dee29e1938c002c1ff79b0e7eaadff/src/librustc_span/def_id.rs#L124

Re: Blanket подразумевает, что они все равно нарушают изменения:

• Они могут частично перекрывать нижний имплант, что недопустимо.
• Когерентность может предполагать их несуществование более тонкими способами (вот почему имплименты резервирования были добавлены внутри)
• Всегда должны применяться специализированные импы, что означает:
  
  
  
  • Мы нарушаем подразумеваемые люди (что делает min_specialization ).
  
  
  • Мы требуем, чтобы они как-то аннотировали свои границы признаков, чтобы они всегда были применимы, где это необходимо.
  
  
  • Мы неявно вносим в них всегда применимые изменения и потенциально вносим небольшие ошибки времени выполнения, когда теперь применяется имплицит по умолчанию.
  
  

На самом деле impl<T: Copy> Clone for T { } imp. В любом случае я написал об этом сообщение в блоге ... но сейчас я не могу вспомнить, каков был мой вывод .

Тем не менее, мы могли бы сделать это предупреждением об отсутствии аннотации #[override] .

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

Один из незавершенных пунктов, которые мы должны сделать в проекте мела, - это попытаться вернуться и разъяснить, как должна быть выражена специализация.

Было довольно много случаев, когда код в rustc и стандартной библиотеке не выполнял то, как выглядит, потому что нет способа узнать, что на самом деле происходит специализация.

Мой опыт работы с java аналогичен (хотя и не совсем аналогичен). Может быть сложно определить, какой подкласс класса фактически запущен ...

Еще в мае я предложил альтернативу специализации на IRLO, которая на самом деле не полагается на перекрывающиеся имплименты, а скорее позволяет одному импуансу where match в параметре типа:

impl<R, T> AddAssign<R> for T {
    fn add_assign(&mut self, rhs: R) where match T {
        T: AddAssignSpec<R> => self.add_assign(rhs),
        T: Add<R> + Copy => *self = *self + rhs,
        T: Add<R> + Clone => { let tmp = self.clone() + rhs; *self = tmp; }
    }
}

Затем ящики ниже по потоку могут использовать такой impl для реализации «специализации», потому что по соглашению такой impl для признака Trait сначала будет соответствовать типам, реализующим другой признак TraitSpec , и нижележащим типам сможет реализовать эту черту, чтобы переопределить общее поведение:

// Crate upstream
pub trait Foo { fn foo(); }
pub trait FooSpec { fn foo(); }

impl<T> Foo for T {
    fn foo() where T {
        T : FooSpec => T::foo(),
        _ => { println!("generic implementation") }
    }
}

fn foo<T : Foo>(t: T) {
    T::foo()
}

// crate downstream
struct A {}
struct B {}

impl upstream::FooSpec for A {
    fn foo() { println!("Specialized"); }
}

fn main() {
    upstream::foo(A); // prints "specialized"
    upstream::foo(B); // prints "generic"
}

Эта формулировка дает больше контроля для восходящего потока, чтобы выбрать порядок применимых имплицитов, и, поскольку это часть сигнатуры признака / функции, это будет отображаться в документации. ИМО, это предотвращает «импровизированное преследование», чтобы узнать, какая ветвь действительно применима, поскольку порядок разрешения явный.

Это могло бы сделать более очевидными ошибки, связанные с продолжительностью жизни и равенством типов, поскольку только восходящий поток может встретить их при реализации специализации (поскольку нисходящий поток реализует только «признак специализации».

Недостатки этой формулировки заключаются в том, что это совсем другой путь, чем в RFC, и он внедряется с 2016 года, и что по крайней мере некоторые люди в потоке выразили опасения, что он не будет таким выразительным и / или интуитивно понятным, как текущий. особенность специализации (я считаю «сопоставление по типам» довольно интуитивно понятным, но я предвзято предлагаю формулировку).

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

@dureuill спасибо за информацию! Это действительно интересная идея. Меня беспокоит то, что он не обязательно решает некоторые другие ожидаемые варианты использования специализации, особенно случай «постепенного уточнения поведения», как описано @aturon в этом сообщении в

@dureuill Идея действительно интересная и может иметь большой потенциал, но альтернатива не всегда равнозначна обмену.
Причина, по которой я так не думаю, заключается в том, что у человека нет возможности полностью заменить более общую реализацию. Еще одна проблема может заключаться в том, что на самом деле у нас нет поддержки всех функций, представленных в RFC синтаксиса where от которых зависит ваше предложение.
Предложение интригующее, так что, возможно, он мог бы иметь свой собственный RFC в качестве отдельной функции, а не конкурента специализации, потому что оба были бы полезны, и я не вижу причин, по которым они не могут жить вместе.

@ the8472 @nikomatsakis , @ Dark-Legion: Спасибо за положительный отзыв! Я пытаюсь ответить на некоторые из ваших замечаний в ветке IRLO , так как я не хочу слишком шумно

Я могу открыть отдельный RFC, если мне удастся написать что-нибудь для публикации. Между тем, я очень открыт для отзывов о связанной ветке IRLO . Я добавил более длинный пример из сообщения в блоге aturon, так что не стесняйтесь его комментировать!

Я также за то, чтобы иметь какой-то маркер по специализации имп.

Приближается издание 2021 года, которое позволяет нам зарезервировать дополнительные ключевые слова (например, specialize ). Глядя на сложность и историю этой функции, я не думаю, что она стабилизируется до выпуска версии 2021 (не стесняйтесь доказывать, что я ошибаюсь), что означает, на мой взгляд, игру с (a) новым ключевым словом (ами) ) разумно.

В противном случае единственным существующим ключевым словом, которое кажется ... ну ... подходящим в качестве маркера, могло бы быть super ?

Резюме путем повторного использования примера @LLFourn из https://github.com/rust-lang/rust/issues/31844#issuecomment -639977601:

• super (уже зарезервировано, но может быть неверно истолковано как альтернатива default )

super impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>

• specialize

specialize impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>

• spec (сокращение от specialize как impl означает implement ) (обоснованное беспокойство, поднятое @ssokolow в https://github.com/rust-lang / rust / issues / 31844 # issuecomment-690980762)

spec impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>

• override (уже зарезервировано, спасибо @ the8472 https://github.com/rust-lang/rust/issues/31844#issuecomment-691042082)

override impl<A, T> Extend<A, T> for Vec<A> where T: IntoIterator<Item=A>

уже зарезервированные ключевые слова можно найти здесь

или spec (сокращение от specialize например impl означает implement )

«Спецификация» уже более знакома людям как сокращение от «спецификация» (например, «спецификация HTML 5»), поэтому я не думаю, что это было бы хорошим сокращением для «специализации».

override - зарезервированное ключевое слово, я полагаю, оно предназначалось для функций, поэтому его можно использовать для блока impl.

specialize также зависит от языкового стандарта - я как австралиец специализируюсь на этом, поэтому использование слова «spec» устраняет двусмысленность языкового стандарта.

specialize также зависит от языкового стандарта - я как австралиец специализируюсь на этом, поэтому использование слова «spec» устраняет двусмысленность языкового стандарта.

это работает, за исключением того, что «спецификация» - это обычное сокращение для спецификации, поэтому я думаю, что использование «спецификации» для обозначения специализации может сбить с толку. Даже если слова в Австралии пишутся по-разному, каждый может понять, какое слово имеет в виду, если оно написано с буквой «z» или «s».

Как канадец, я должен сказать, что специализация / специализация - не единственное слово, используемое в программировании, которое зависит от локали.

Здесь мы используем «цвет», но он всегда сбивает меня с толку в тех редких случаях, когда язык программирования или библиотека используют его вместо «цвета». Хорошо это или плохо, но американский английский - это своего рода стандарт де-факто в дизайне API, и для таких слов, как цвет / цвет, предпочтение одного написания по сравнению с другим неизбежно, не будучи по-настоящему надуманным.

Учитывая, насколько сильно я ожидаю, что «spec» будет означать «спецификация», я думаю, что это еще одна ситуация, когда мы должны просто рассматривать написание в американском английском как наименее худший вариант.

Возможно, это де-факто, но это не значит, что их можно использовать. Я обнаружил, что делаю импорт, например, «использовать цвет как цвет». Я тоже всегда спотыкаюсь о s vs z. Я думаю, что, учитывая положительное отношение Rust к инклюзивности и доступности, имеет смысл выбирать языковые термины, не зависящие от локали, поскольку небольшие разочарования пользователей, такие как цвет / цвет и s / z, действительно накапливаются.

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

Как не носитель английского языка, мне кажется забавным, что носители английского языка жаловались на лишние u как на препятствие для инклюзивности. Только представьте, как бы это было, если бы все не было написано немного странно, а было написано совершенно на другом языке.

Другими словами: каждый термин, используемый в Rust, зависит от локали.

Хорошо это или плохо, но в Rust все написано на американском английском. Для многих здесь это означает работу на втором или третьем языке; для других это означает необходимость немного подправить орфографию. Это то, что нужно, чтобы заставить работать вместе целую группу людей. Я думаю, что польза от попытки подобрать слова, которые пишутся одинаково во многих вариантах английского языка, незначительна по сравнению с выбором хорошего однозначного термина - а spec неоднозначно, как указано выше.

использовать special в качестве ключевого слова?

В качестве альтернативы создайте два ключевых слова: specialize и specialise и сделайте их эквивалентными ...

(Или вы, забавные неамериканцы, можете научиться правильно писать: нас: 😂)

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

@ mark-im К сожалению, это скользкая дорожка, ведущая к аргументам в пользу того, что Rust должен иметь альтернативные наборы ключевых слов на всех основных языках, с которых могут приходить изучающие.

Это также излишне усложняет язык из-за наличия нескольких синонимов для ключевых слов, поскольку люди и парсеры привыкли только к мысли, что пробелы могут изменяться таким образом.

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

Вместо того, чтобы спорить о том, на каком диалекте английского языка мы хотим использовать этот идентификатор, возможно, мы можем пойти на компромисс и вместо этого использовать иврит ?

@ssokolow, хотя аргумент о скользкой

• Некоторые слова на разных языках выглядят одинаково, но означают разные вещи (сейчас не могу привести пример, связанный с программированием, но случайный пример: a на словацком означает and на английском)
• У людей будут большие проблемы с чтением кода на другом языке, даже если они знают этот язык . Знаю по опыту. (Короче говоря: у меня были огромные проблемы с пониманием некоторых текстов, термины которых были напрямую переведены с английского на мой «родной язык», при мошенничестве с университетским образованием.)

Теперь, работая в обратном направлении, почему следует отдавать предпочтение другим диалектам английского языка, а не другим языкам? Я не вижу в этом смысла. Последовательность (все на американском английском) кажется самым простым, легким для понимания и наименее подверженным ошибкам.

Как бы то ни было, я был бы очень рад, если бы вы имели в виду XXX? сообщение об ошибке. Нейтральные слова, не имеющие других проблем, тоже подойдут.

По крайней мере, никому не нужно обсуждать футбол в коде. ;)

Около 70% носителей английского языка живут в странах, в которых используется орфография США.

Также..

"Правописание -ize часто ошибочно воспринимается в Британии как американизм. Оно используется с 15 века, более чем на столетие раньше, чем -ise. -Ize происходит непосредственно от греческого -ιζειν -izein и латинского -izāre, а - ise идет через французский -iser. Оксфордский словарь английского языка (OED) рекомендует -ize и перечисляет -ise в качестве альтернативы ».

"Публикации Oxford University Press (OUP) - такие как Словарь современного английского языка Генри Ватсона Фаулера, Правила Харта и Оксфордское руководство по использованию английского языка - также рекомендуют -ize. Однако в книге Роберта Аллана Карманное использование английского языка Фаулера рассматривается любой вариант написания быть приемлемым где угодно, кроме США ".

исх. https://en.wikipedia.org/wiki/American_and_British_English_spelling_differences# -ise, _- ize _ (- isation, _- ization)

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

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