Rust: 専門分野の追跡の問題（RFC 1210）

いくつかの追加の未解決の質問：

• 専門性に照らして、孤立したルールを再検討する必要がありますか？ 今、物事をより柔軟にする方法はありますか？
• RFCの「連鎖律」を、いわゆる「格子規則」のような、より表現力豊かなものに拡張する必要がありますか？
• 上記の両方に関連して、否定的な推論はどのように物語に適合しますか？ 特殊化/孤立したルールを巧みに使用することで、必要な否定的な推論を回復できますか、それとももっとファーストクラスにする必要がありますか？

専門化によって孤立したルールが変わるかどうかはわかりません。

• 「リンク」孤立ルールは同じままである必要があります。そうしないと、安全なリンクが得られないためです。
• 「将来の互換性」の孤立したルールは変更されるべきではないと思います。 あなたの下に専門外のimplを追加することは、それでも重大な変更になります。

さらに悪いことに、「将来の互換性」の孤立したルールは、クレート間の特殊化をかなり厳しく管理し続けます。 それらがないと、メソッドを開いたままにするdefault-implsはさらに悪化します。

私は明白な否定的な推論が好きではありませんでした。 私は、専門化が提供する完全な否定的な推論は良い妥協点だと思います。

この実装は、実装された特殊化で許可する必要がありますか？ それとも私は何かが足りないのですか？
http://is.gd/3Ul0pe

これと同じように、コンパイルされることを期待していました： http ：

関連するタイプが関係している場合、オーバーラップを決定する際にいくつかの癖があるようです。 これはコンパイルされます： http ： http ：

これが私が特殊化してコンパイルすることを期待したコードの一部です：

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

最初の2つの例を見る時間がありました。 これが私のメモです。

例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>,

問題は、これらのimplが重複しているが、どちらも他よりも具体的ではないことです。

• T: FromSql<ST, DB>が存在する可能性がありますが、 Tはペアではありません（したがって、最初のimplと一致しますが、2番目のimplとは一致しません）。
• あなたは潜在的に(T, U)持つことができますここで：
  
  
  
  • T: FromSqlRow<ST, DB> 、
  
  
  • U: FromSqlRow<SU, DB> 、しかし_not_
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  
  • （したがって、2番目のimplは一致しますが、最初のimplは一致しません）
  
  
• 次のような(T, U)持つことができるため、2つのimplは重複します。
  
  
  
  • T: FromSqlRow<ST, DB>
  
  
  • U: FromSqlRow<SU, DB>
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  

これは、lattice implsが許容するような状況です。重複するケースに対して、3番目の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> （第1、第2のimplと一致するではなく）
• T: Queryable<ST, DB>ようにOption<T>を持つことができますが、 Option<T>: FromSqlRow<Nullable<ST>, DB>はできません

@SergioBenitez

コンパイルは、実装の競合を理由にコンパイラで失敗します。 &strはFromStr実装していないため、競合が発生しないことに注意してください。

問題は、コンパイラが&strが将来FromStrを実装するようになるかもしれないと控えめに想定していることです。 この例ではそれはばかげているように見えるかもしれませんが、一般に、新しいimplを常に追加し、それらのimplを追加するときにダウンストリームコードが壊れないように保護したいと考えています。

これは控えめな選択であり、時間をかけてリラックスしたいと思うかもしれません。 ここで背景を取得できます：

• 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

この2つのケースを明確にしていただきありがとうございます。 今では完全に理にかなっています

2016年3月22日火曜日、午後6時34分アーロンテューロン[email protected]は次のように書いています。

@SergioBenitez https://github.com/SergioBenitez

コンパイルは、実装の競合を理由にコンパイラで失敗します。 注意
＆strはFromStrを実装していないため、競合が発生することはありません。

問題は、コンパイラが保守的に＆strを想定していることです。
将来的にFromStrを実装するようになるかもしれません。 それはばかげているように見えるかもしれません
この例ですが、一般的には、常に新しいimplを追加します。
これらのimplを追加するときに、ダウンストリームコードが壊れないように保護します。

これは控えめな選択であり、私たちがリラックスしたいと思うかもしれないものです
時間とともに。 ここで背景を取得できます：

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

• rust-lang / rfcs＃1023 https://github.com/rust-lang/rfcs/pull/1023
• rust-lang / rfcs＃1053 https://github.com/rust-lang/rfcs/issues/1053
• rust-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を実装するようになる可能性があると控えめに想定していることです。 この例ではそれはばかげているように見えるかもしれませんが、一般に、新しいimplを常に追加し、それらのimplを追加するときにダウンストリームコードが壊れないように保護したいと考えています。

これはまさに専門分野が対処しようとしていることではありませんか？ 専門で、私はそれを期待する場合でもの実装FromStrのための&str 、将来的に追加されましたが、直接実装Simple形質の&str優先されます。

@SergioBenitezは、より一般的なimplにdefault fnを入れる必要があります。 君の
例は特殊化されていません。

2016年3月22日火曜日、午後6時54分セルジオベニテス[email protected]
書きました：

@aturon https://github.com/aturon

問題は、コンパイラが保守的に＆strを想定していることです。
将来的にFromStrを実装するようになるかもしれません。 これにはばかげているように見えるかもしれません
例ですが、一般的には、常に新しいimplを追加します。
これらのimplを追加するときに、ダウンストリームコードが壊れないように保護します。

これはまさに専門分野が対処しようとしていることではありませんか？ と
専門分野では、FromStrの実装であっても
＆strは将来追加され、の直接実装
＆strの特性が優先​​されます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/rust-lang/rust/issues/31844#issuecomment -200097995

「デフォルト」のトレイトアイテムが自動的にdefaultと見なされるのimplを緩和するとともに、Haskellなどのような特性の両方のパラメトリシティが必要になる場合があります。 また、 defaultように、簡単にgrepすることはできません。 defaultキーワードを入力し、デフォルトの実装を指定することは難しくありませんが、そのまま分離することはできません。 また、言語を明確にしたい場合は、これらの「デフォルト」の特性アイテムの名前を、ドキュメント内の「特性提案」アイテムに変更できます。

＃32999（コメント）からの注意：ラティスルールを使用する（または負の制約を許可する）場合、何かのさらなる特殊化を防ぐための「中間特性を使用する」トリックは機能しなくなります。

@Stebalien

なぜそれが機能しないのですか？ このトリックは、専門分野を私的な特性に限定します。 あなたがそれにアクセスできない場合、あなたは私的な特性を専門にすることはできません。

@ arielb1ああ。 いい視点ね。 私の場合、その特性は私的なものではありません。

「孤立した上位互換性+コヒーレンスルールのために外部ソースを専門化できない」という推論は、特に興味深いまたは有用ではないと思います。 特に、特定の一貫性ルールにコミットしない場合。

オーバーライドされたdefault implにアクセスする方法はありますか？ もしそうなら、これはテストの構築に役立つ可能性があります。 契約による設計とlibhoareを参照してください。

型チェック中にデフォルトの関連付けられた型の投影を許可すると、コンパイル時に型の不等式を適用できます： //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のコメントごとに編集

CloudFlareを使用しているためにTorユーザーに対して解決されないため、おそらくfyi @ rphmeierは

@burdges FWIW play.rust-lang.org自体は、「短縮」ボタンにis.gdを使用しています。

ただし、おそらく変更できます： https ：

このように使用します（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

将来のspecializationはこれをサポートしますか？現在、他の種類の実装はありますか？

@zitsen

T: Foo + BarもT: Foo + Bazも他よりも特殊化されていないため、これらの実装は現在の特殊化設計では許可されていません。 つまり、 T: Foo + Bar + Baz場合、どのimplが「勝つ」べきかは明確ではありません。

T: Foo + Bar + Baz含意を_また_与えることができ、したがって曖昧さを解消できる、より表現力豊かなシステムについていくつかの考えがありますが、それはまだ完全には提案されていません。

負の特性がtrait Baz: !Bar到達する場合は、それを特殊化とともに使用して、Barを実装するタイプのセットとBazを実装するタイプのセットが区別されて個別に特殊化できることを証明することもできます。

@rphmeierの返信は私がまさに望んでいるもののようです。 T: Foo + Bar + Baz implsも役立ちます。

これを無視してください。私はまだ私のケースと関係があり、 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 {
   |> ^

ベビーサークル

上記はコンパイルする必要があると思います。実際に意図したとおりに機能する2つの興味深いバリエーションがあります。

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テキストは、許可する必要があることを示唆していますが、その例はそこからコピーされています。

特殊化の恩恵を受けることができるいくつかのコードで遊んだ。 連鎖ではなくラティスルールを採用する必要があると強く思います。それは自然な感じであり、必要な柔軟性を得る唯一の方法でした（効果的）。

implと個々のアイテムでdefaultした場合、いずれかのアイテムがオーバーライドされた場合、それらはすべてオーバーライドされる必要があることを強制できますか？ これにより、他の項目のデフォルトの関連タイプ（たとえば）の正確なタイプに基づいて推論できるようになります。これは、表現力を高めるのに役立つようです。

以下を許可する必要がありますか？ 要素タイプがCopyの場合はArrayVecがCopyになるように、それ以外の場合はデストラクタを持つように、タイプを特殊化したいと思います。 特殊化に置き換えられた内部フィールドを使用してそれを達成しようとしています。

これがコンパイルされることを望みました。つまり、 A: Copy + Arrayバウンド（遊び場でコンパイル可能なスニペット）によって選択されたフィールドタイプからArrayVec<A>のフィールドのコピー可能性を推測します。

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

コメントアウトされたwhere句は、パブリックインターフェイスでプライベートタイプReprを公​​開するため、不要です。 （とにかくそれもICEです）。

編集：私はこれについてすでに問題＃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がある場合：

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はないかもしれないということです。

ここでいくつかの可能な答えについて話しました。 それらの1つは、 defaultを使用してアイテムをグループ化できるようにすること

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

これは問題ありませんが、少し「右方向へのドリフトを誘発」します。 defaultもネーミングスコープのように見えますが、そうではありません。 「override-any」（今日のように）と「override-all」（必要なもの）を切り替えることができる、より単純なバリアントがあるかもしれません。

また、 impl Trait活用することでうまくいくことを望んでいました。 ここでの場合のように、メソッドの戻り値の型をカスタマイズする場合、これが最も頻繁に発生するという考えです。 したがって、 impl Traitを使用するようにトレイトを書き直すことができれば：

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

これは、タイプとfnを含むデフォルトのグループに実装すると、事実上一種の省略形になります。 （ただし、純粋にimplでそれを行う方法があるかどうかはわかりません。）

PSさん、メッセージへの返信が大幅に遅れて申し訳ありません。日付は_ 7月_です。

impl Traitは役に立ちますが、受け入れられたり実装されたりして、あらゆる形式のトレイトボディで使用できるRFCはないため、このRFCを探すのは少し奇妙に感じます。

default impl機能（すべてのアイテムがdefault ）の実装に興味があります。
それについての貢献を受け入れますか？

@giannicic間違いなく！ 仕事の指導も喜んでお手伝いさせていただきます。

現在、関連するタイプを特殊化する必要があるかどうかについての結論はありますか？

以下は私のユースケースの簡略化であり、特殊化可能な関連タイプの必要性を示しています。
コンテナトレイトオブジェクトのコレクション（ &trait::Property ）を調整する一般的なデータ構造、たとえばFooがあります。 特性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 ！
基本的に、 ast::ItemKind::Impl構造体に新しい「defaultness」属性を追加して作業を行っています（次に、新しい属性をimplアイテムの「defaultness」属性と一緒に使用します）が、すばやく簡単に実行することもできます
解析中にデフォルトをdefault implすべてのimplアイテムに設定することで構成される可能性。
「デフォルト」がimplの各項目ではなく、implに関連しているという情報を失ったため、これは「完全な」解決策ではありません。
さらに、 partial implを導入する計画がある場合、最初のソリューションは、 defaultとpartialを格納するために使用できる属性をすでに提供します。 しかし、念のために
時間を無駄にしないで、あなたはどう思いますか？

@giannicic @aturon default implについて話し合うための特定の問題を作成することを提案できますか？

気にしないでください、私はそれを作成しました： https ：

与えられた場合、ラティスルールは私に許可しますか？

trait Foo {}

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

A 、 B 、 C 、...の組み合わせを実装するタイプのサブセットにFoo実装を追加します。

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は決して起こらないはずです。

いいえ、これはラティスルールで許可されるものではありません。 それは、何らかの形や種類の「否定的な推論」の領域になります。

コンテキスト：さまざまな種類のシェイプ（ポイント、キューブ、ポリゴンなど）に近似（Shape、Shape）トレイトを実装するときに、これらがすべてトレイトである場合に、これが必要になりました。 実装の競合を回避するために、これをさまざまな特性、たとえば、ApproxEqualPoint（Point、Point）にリファクタリングすることにより、これを回避する必要がありました。

そのため、 @ withoutboatsは、特定の特性セットが相互に排他的であると宣言できる（つまり、最大で1つを実装できる）「除外グループ」のアイデアを推進しています。 私はこれを列挙型のようなものとして想像しています（つまり、特性はすべて一緒に宣言されます）。 私はこれのアイデアが好きです、特に（私が思うに！）それが否定的な推論のより有害な側面のいくつかを避けるのを助けるので。 しかし、私はこの面でもっと考える必要があるように感じます-そしてまた、否定的な推論について考える方法について浮かんでいるすべての「データ」を要約しようとする良い記事もあります。 おそらく今、私は（ほとんど）HKTと専門シリーズをまとめたので、それについて考えることができます...

@nikomatsakis ：

そのため、 @ withoutboatsは、特定の特性セットが相互に排他的であると宣言できる（つまり、最大で1つを実装できる）「除外グループ」のアイデアを推進しています。 私はこれを列挙型のようなものとして想像しています（つまり、特性はすべて一緒に宣言されます）。 私はこれのアイデアが好きです、特に（私が思うに！）それが否定的な推論のより有害な側面のいくつかを避けるのを助けるので。 しかし、私はこの面でもっと考える必要があるように感じます-そしてまた、否定的な推論について考える方法について浮かんでいるすべての「データ」を要約しようとする良い記事もあります。 おそらく今、私は（ほとんど）HKTと専門シリーズをまとめたので、それについて考えることができます...

これを書いているときに除外グループについて考えましたが（先日フォーラムで言及しました）、この特定の例ではすべてのトレイトの実装が排他的であるとは限らないため、除外グループが機能するとは思いません。 最も簡単な例は、 PointとFloat特性です。 Floatは1Dポイントになる可能性があるため、 ApproxEqualPoint(Point, Point)とApproxEqualFloat(Float, Float)はできません。排他的。 SquareとPolygon 、またはBox |のような他の例があります CubeおよびAABB （軸に沿った境界ボックス）。ここで、「特性階層」は実際にはより複雑な制約を必要とします。

いいえ、これはラティスルールで許可されるものではありません。 それは、何らかの形や種類の「否定的な推論」の領域になります。

私は少なくとも特定のケースを実装し、それにunimplemented!()を入れることができるでしょう。 それで十分ですが、 unimplemented!()を含む関数を呼び出すケースをコンパイラーが静的にキャッチするのであれば、明らかにもっと欲しいです（そしてこの時点で、私たちは再び否定的な推論の地にいます） 。

@gnzlbgラティスの特殊化により、その暗黙のパニックを引き起こすことができますが、それを行うというアイデアは私を： cry：にします。

「除外グループ」の概念は、実際には単なる負の超特性境界です。 あまり徹底的に調査していないことの1つは、逆極性の特殊化の概念です。これにより、極性が逆の特殊化されたimplを、あまり特殊化されていないimplに書き込むことができます。 たとえば、この場合、次のように記述します。

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

それを許可することの意味が完全にはわかりません。 これは、特殊化がコードの再利用とポリモーフィズムを現在どのように混同しているのかについて、ニコがすでに強調している問題に関連していると思います。

ネガティブな推論とネガティブな含意についてのこのすべての議論で、私は「インスタンスチェーン」の古いHaskellのアイデア（紙、紙、 GHC問題追跡システム、 Rust pre-RFC ）を、何もないとしても潜在的なインスピレーションの源として再び持ち出すことを余儀なくされていると感じていますそうしないと。

基本的に、 trait implを記述できる場所であればどこでも、前の節の場合に適用する必要がある別のimplを指定する「elseif節」をいくつでも記述できるという考え方です。負のimplを指定するオプションの最後の「else句」を使用して、そうではありませんでした（つまり、 Traitの句がどれも適用されない場合、 !Trait適用されます）。

@withoutboats

「除外グループ」の概念は、実際には単なる負の超特性境界です。

私のユースケースではそれで十分だと思います。

これは、特殊化がコードの再利用とポリモーフィズムを現在どのように混同しているのかについて、ニコがすでに強調している問題に関連していると思います。

これらを解くことができるかどうかはわかりません。 私が欲しい：

• ポリモーフィズム：多くの異なるタイプの操作の異なる実装を抽象化する単一の特性、
• コードの再利用：タイプごとに操作を実装する代わりに、いくつかの特性を実装するタイプのグループに実装したいと思います。
• パフォーマンス：既存の実装よりも具体的な制約のセットを持つ特定のタイプまたはタイプのサブセットの既存の実装をオーバーライドできます。
• 生産性：プログラムをコンパイルするために大量のimplを追加する代わりに、プログラムを段階的に記述してテストすることができます。

すべてのケースをカバーするのは難しいですが、コンパイラーが私にすべてのケースをカバーするように強制した場合：

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

必要に応じてimplを段階的に追加できます。また、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

これらの2つの実装は、特殊化によって有効であると期待されますね。 うまく拾えないようです。

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,
{
    ...
}

Serdeにスペシャライゼーションを構築する作業中に遭遇した予期しない動作について、 https：//github.com/rust-lang/rust/issues/38516を提出しました。 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> { ... }

（これは、イテレーターとベクトル以外の状況に関連しています。もちろん、これは1つの例にすぎません。）

今日、これはコンパイルされず、ツリスと歯ぎしりがあります。 専門化はこの問題を解決します：

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

しかし、この問題を解決するために、クレートにパブリックコントラクトを追加しました。 Fooのイテレーターimplを無効にすることができます。 たぶん私たちはあなたにそうすることを強制したくないでしょう-したがって、 defaultなしのローカルスペシャライゼーション。

私が思う質問は、 default役割は正確には何であるかということです。 default要求することは、元々、明示性と自己文書化コードへのジェスチャーだったと思います。 Rustコードがデフォルトで不変、デフォルトでプライベート、デフォルトで安全であるように、デフォルトでもfinalである必要があります。 「非終局は、」グローバルプロパティであるので、私はあなたがアイテムを特化させない限り、しかし、私はアイテムを特化することはできません。

default要求することは、元々、明示性と自己文書化コードへのジェスチャーだったと思います。 ただし、[..]専門化させない限り、専門化することはできません。

それは本当に悪いですか？ implを専門にしたい場合は、他の人も同様にしたいと思うかもしれません。

このRFCについて考えるだけで、わいせつな量のオーバーロードと継承を使用するC ++コードベースでの作業のPTSDフラッシュバックがすでに得られており、メソッド呼び出しがあるコード行でwtfが発生していることがわかりません。 @aturonが費やした長さに本当に感謝しています。

それは本当に悪いですか？ implを専門にしたい場合は、他の人も同様にしたいと思うかもしれません。

他の人も「たぶん」それを専門にしたいだけで、私たちが彼らに望まない良い場合があるなら、これを指定することを不可能にすべきではありません。 （カプセル化に少し似ています。一部のデータにアクセスしたいが、他の人もアクセスしたい場合があるため、すべてのデータをデフォルトでパブリックにするのではなく、明示的に_this data_ publicとマークします。）

このRFCについて考えるだけで、すでにPTSDフラッシュバックが発生しているので心配です...

しかし、この仕様を禁止すると、これらのことが起こらないようにする方法はありますか？

望まない良いケースがある場合は、これを指定できないようにするべきではありません。

ユーザーが適切なユースケースを持っている場合はいつでも、ユーザーにパワーを与えることは必ずしも良い考えではありません。 また、ユーザーが紛らわしいコードを記述できる場合はそうではありません。

しかし、この仕様を禁止すると、これらのことが起こらないようにする方法はありますか？

foo.bar()が表示されていて、 bar()機能を確認したいとします。 現在、一致する型に実装されているメソッドが見つかり、 defaultマークが付いていない場合は、探しているメソッド定義であることがわかります。 @withoutboatsの提案では、これはもはや真実ではありません。代わりに、実行されているコードを実際に見ているかどうかを確実に知ることはできません。

代わりに、実行されているコードを実際に見ているかどうかを確実に知ることはできません。

これは、ローカルタイプのデフォルト以外のimplの特殊化を許可する効果のかなり誇張です。 あなたが具体的なimplを見ているなら、あなたはあなたが正しいimplを見ていることを知っています。 そして、あなたはこのクレートのソース全体にアクセスできます。 このimplが特殊化されているかどうか、または「決して」よりも大幅に早くないかどうかを判断できます。

一方、 defaultを使用しても、implがファイナライズされていない場合は問題が残ります。 正しいimplが実際にdefault implである場合、これが正しいimplであるかどうかわからないという同じ状況にあります。 そしてもちろん、特殊化が採用されている場合、これは非常に一般的に当てはまります（たとえば、これは今日、 ToStringほぼすべての実装に当てはまります）。

実際、これはかなり深刻な問題だと思いますが、 default解決できるとは思いません。 必要なのは、より優れたコードナビゲーションツールです。 現在、rustdocは、トレイトimplに関しては、非常に「ベストエフォート」アプローチを採用しています。ソースにリンクしておらず、包括的implによって提供されるimplもリストされていません。

この変更が決してスラムダンクだと言っているわけではありませんが、もっと微妙な検討の価値があると思います。

ユーザーが適切なユースケースを持っている場合はいつでも、ユーザーにパワーを与えることは必ずしも良い考えではありません。 また、ユーザーが紛らわしいコードを記述できる場合はそうではありません。

正確に、私は絶対に同意します。 ここでは、あなたが書いた木枠のユーザーである別の「ユーザー」について話していると思います。 あなたは彼らがあなたのクレートの特性を自由に専門化することを望まない（おそらくあなたのクレートの振る舞いにハッキーな方法で影響を与える）。 一方、私たちはあなたが話している「ユーザー」、つまりクレートの作者にもっと力を与えるでしょうが、 @ withoutboatsの提案がなくても、「デフォルト」を使用して同じ問題に

defaultは、コードの読み取りを単純化したい場合は、誰もdefault使用しないように依頼したり、コードを使用するための厳密なドキュメントルールを確立したりできるという意味で役立つと思います。 その時点で、あなたはstdからのdefaultについて心配するだけでよく、おそらく人々はもっとよく理解するでしょう。

スペシャライゼーションの使用法に文書化ルールを課すことができ、スペシャライゼーションRFCの承認に貢献したという考えを思い出します。

@withoutboatsは、「オーバーライド可能ですが、このクレート内でのみ」を意味する制限された形式のdefaultが必要なため、 defaultを緩める動機を読んで正しいです（つまり、 pub(crate)しかしdefault ）？ ただし、物事を単純にするために、 defaultらしさの目盛りを追加するのではなく、 defaultを省略するセマンティクスを変更することを提案していますか？

正しい。 default(crate)ようなことをするのはやり過ぎのようです。

先験的に、私は、木枠が何を輸出するかを通してそれをシミュレートできると思います、そうではありませんか？ defaultメソッドを使用してプライベートヘルパートレイトを単純に導入し、それを自分の最終的なimplから呼び出すことができない状況はありますか？ ユーザーにdefaultを使用させたいが、独自のものは提供しないようにしたいですか？

正しい。 default（crate）のようなことをするのはやり過ぎのようです。

同意しません。 私は本当にデフォルトの制限された形式が欲しいです。 私はそれを提案するつもりでした。 私の動機は、交差点などがデフォルトを追加することを強制することがあるということですが、それはあなたが任意のクレートがあなたの行動を変えることを許可したいという意味ではありません。 申し訳ありませんが、会議があります。少し例を挙げて詳しく説明します。

@nikomatsakis私は同じ動機を持っています。私が提案しているのは、レバーを追加するのではなく、同じクレートに特化するというデフォルトの要件を削除することです。 :-)

たまたまこのエクスポートされていないデフォルトがより一般的な使用法である可能性がある場合、 #[default_export]機能は、 #[macro_export]との類推によって覚えやすくなります。 中間オプションは、 pub useまたはpub mod行に対してこのエクスポート機能を許可することです。

Macros 2.0は通常のアイテムとしてマクロをサポートし、 #[macro_use]代わりにpubを使用するため、 pubキーワードを使用する方が適切です。 pubを使用して全体的な可視性を示すことは、その一貫性にとって大きなメリットになります。

@withoutboatsに関係なく、ローカルに特化したいと思うこともあると思いますが、必ずしもすべての人に門戸を開く必要はありません

pubキーワードを使用する方が良いでしょう

pub default fnということは、関数自体の可視性に影響を与えるのではなく、「fnのデフォルトをパブリックにエクスポートする」ことを意味します。これは初心者にとって非常に混乱します。

@jimmycuadraは、 pubキーワードを使用するという意味ですか？ @sgrifの方が紛らわしいように思われることに同意します。デフォルトのスコープを明示的に許可する場合は、可視性をスコープするために決定したのと同じ構文が正しいパスのように見えます。

おそらく、正確にはpub default fnではありません。これは、両方とも言及しているように、あいまいだからです。 pub普遍的に「外部にプライベートなものを公開する」という意味にすることにpubを含む構文の定式化がおそらくあります。

少し構文的ですが、 default(foo)がpub(foo)ように機能することに反対するつもりはありません。2つの間の対称性は、私にとって構文の煩わしさをわずかに上回っています。

Bikeshed警告：我々はそれを呼び出すと考えられてきたoverridableの代わりにdefault ？ それは文字通り説明的であり、 overridable(foo)はdefault(foo)よりも読みやすくなっています-後者は「これはfooの範囲内のデフォルトですが、他の何かがデフォルトである可能性があります前者は「これはfooの範囲内で上書き可能です」と言っていますが、これは正しいです。

最初の2つの質問は本当に次のとおりです。 defaultエクスポートするかしないかは、かなり一般的ですか。 defaultエクスポートすることをデフォルトの動作にすべきではありませんか？

はいの場合：他の場所でのエクスポートとの類似性を最大化することができます。 pub mod mymodule default;やpub use mymodule::MyTrait default; 、またはoverridableます。 必要に応じて、 pub use MyModule::MyTrait::{methoda,methodb} default;使用する一部のメソッドに対してのみdefaultエクスポートできます。

ケースなし：とにかくRustの他のものとはかなり異なる、公開ではなく非公開を表現する必要があるため、 default(crate)がこれらのエクスポートを制御する通常の方法になります。

また、 defaultエクスポートする場合とエクスポートしない場合が比較的一般的である場合は、「はい」または「いいえ」のどちらの場合でも任意に選択できるため、 pub use MyModule::MyTrait::{methoda,methodb} default;選択するだけで問題ありません。

これらの表記はすべて、とにかく互換性があるように見えます。 別のオプションは、 defaultを閉じた特別なimplかもしれませんが、それは複雑で奇妙に聞こえます。

@burdges後ろに「 nocase 」というラベルがありますか、それとも私はあなたが言っていることを誤解していますか？

うん、おっと！ 修繕！

impl<T> Borrow<T> for T where T: ?Sizedので、 Borrow<T>バウンドは、所有する値を借用したかのように扱うことができます。

特殊化を使用して、 Borrow<T>からcloneへの呼び出しを最適化できると思います。

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が必要になると思われるため、 T: ?Sizedバインドを削除しました。

別のアプローチは

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 ：

特に事後のニコのコメントが高揚しているように見えるので、私は私たちが到達したすべての結論について100％自信がありません。 しばらくの間、それは私には少し黙示録的なように見えました。

私がかなり確信していることの1つは、 defaultを要求することは、新しいdefault implを追加することが常に下位互換性があるという保証と互換性を持たせることができないということです。 これがデモンストレーションです：

クレート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) { }
}

ローカルはAとC実装しますが、 B実装しません。 ローカルで実装されたB場合、そのC実装B 、特殊化されていない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が追加され、完全に特殊化可能なimplであるため、これは重大な変更ではないと述べました。 ただし、他動詞の意味を作成します。「すべてのA impl C（特殊化不可）」を追加することで、「すべてのA impl C（特殊化不可）」というステートメントを暗黙的に追加しました。 "。 現在、子クレートはアップグレードできません。

アーロンは（上記のリンクのログでわかるように）デフォルト性に関して同等の保証を行うimplを記述できることを示したため、特殊なimplを追加することが重大な変更ではないことを保証するという考えは完全に窓の外にある場合があります。 。 ただし、Nikoのその後のコメントは、そのようなimplが孤立したルールによって禁止されている（または少なくとも禁止されている）可能性があることを示唆しています。

したがって、「implが非破壊である」という保証が救済可能かどうかは私にはわかりませんが、implの最終性に対する明示的な制御と互換性がないことは確かです。

これを許可する予定はありますか？

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に境界があるtypeパラメーターを持つテンプレート関数の特殊化です。特殊化されたバージョンにはB境界があります（ Aが必要です）。

@torkleyyは現在ではありませんが、 T: ReadとT: BufRead両方に実装され、そのトレイトの実装に特化したいコードの部分を含むトレイトを作成することで、密かにそれを行うことができます。 パブリックAPIで表示する必要はありません。

下位互換性の問題に関しては、孤立したルールのおかげで、次のルールを回避できると思います。

_implは、以下を除いて追加するための下位互換性があります：_

• _実装されているトレイトは自動トレイトです。_
• _レシーバーはタイプパラメーターであり、implのすべての特性は以前に存在していました。_

つまり、問題のあるすべての例で、追加されたimplは包括的implであると思います。 完全にデフォルトのブランケットインプも大丈夫だと言いたかったのですが、既存のブランケットインプを追加することは重大な変更になる可能性があると言わなければならないと思います。

問題は、それに直面してどのような保証をしたいのかということです-たとえば、少なくとも包括的implがクレート内のコードに基づいた重大な変更にすぎない場合は、非常に優れたプロパティになると思います。あなたのクレートとあなたがメジャーバージョンをインクリメントする必要があるかどうかを確実に知っています。

@withoutboats

下位互換性の問題に関しては、孤立したルールのおかげで、次のルールを回避できると思います。

_implは、以下を除いて追加するための下位互換性があります：_

• _実装されているトレイトは自動トレイトです。_
• _レシーバーはタイプパラメーターであり、implのすべての特性は以前に存在していました。_

つまり、問題のあるすべての例で、追加されたimplは包括的implであると思います。 完全にデフォルトのブランケットインプも大丈夫だと言いたかったのですが、既存のブランケットインプを追加することは重大な変更になる可能性があると言わなければならないと思います。

1週間後、多くの議論がありましたが、残念ながらそうでは

結果は：crying_cat_face：ですが、私がそこに書いたことはあなたの結論と同じだと思います。 包括的実装を追加することは、何があっても、重大な変更です。 ただし、包括的実装（および自動特性実装）のみです。 私の知る限り、包括的でないimplがダウンストリームコードを壊す可能性があるケースは見つかりませんでした（そしてそれは非常に悪いことです）。

ある時点で、孤立したルールを緩和して、 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ああ、私はあなたの2つの箇条書きのリストをandではなくまたはとして理解しました。それはあなたが意味したことのようですか？

@aturonええ、私は「または」を意味しました-これらはそれがます： //is.gd/k4Xtlp

つまり、新しい名前が含まれていない限りです。 新しい名前を含むimplが壊れることはありません。

@withoutboats自動特性に関する否定的な論理に依存している人々を制限できる/すべきかどうか疑問に思います。 つまり、自動特性の新しいimplを追加することは法的な違反の変更であると言った場合、 Send追加する上流のクレートによって破損する可能性のあるimplについて警告する可能性があります。 これは、次の場合に最適に機能します。

1. 安定した専門化でdefault 、戦略的な場所に
2. Rcような型は、決してSendにならないという意図を宣言できるように、何らかの形式の明示的な負のimplです。ただし、自動特性用のものがあるので、それらを考慮に入れることができます。

強いモチベーションがあるかどうかによると思います。 すでにリリースした後、タイプにunsafe impl Send/Syncが含まれる可能性があることに気付く可能性は特に低いようです。 ほとんどの場合、安全だと思いますが、安全であるという予見を持って型を作成しているはずです（それが型のポイントだからです）。

私はいつも事後にunsafe impl Send/Syncを追加します。 スレッドセーフにすることもあれば、インターフェースしているC APIがスレッド間で共有しても問題ないことを認識していることもあります。また、何かがSend / Syncあるべきかどうかという理由だけである場合もあります。タイプを紹介するときに私が考えていることではありません。

C APIをバインドするときにも、事後に追加します。多くの場合、誰かが明示的にそれらの境界を要求するため、基になるライブラリが何を保証するかを確認します。

関連する特性の特殊化が現在どのように機能するかについて私が気に入らないことの1つは、このパターンが機能しないことです。

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が有効である必要があるためです。

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

特性のimpl Traitは、この種のパターンに対する多くの欲求を解放しますが、一般的なimplが有効であるが、型エラーが発生するため、その特殊化が機能しない、より良い解決策はないのではないかと思います。 ？

@withoutboatsええ、これはデザインに関する主な未解決の質問の1つです（最近の議論で取り上げることを忘れていました）。 これについては元のRFCスレッドでかなりの量の議論がありますが、オプション/トレードオフの要約をすぐに書き上げようとします。

@aturon現在のソリューションは最も保守的ですか（私たちがやりたいことと上位互換性があります）、それとも安定する前に決定する必要がありますか？

個人的には、 @ withoutboatsが発生したこの問題の唯一の実際の解決策は、 defaultタグを指定したときにアイテムを「グループ化」できるようにすることだと思います。 これは一種のより良い解決策ですが、より悪い-より良いバリアント（すべてをオーバーライドする手段をオーバーライドする）はかなり悪いように感じます。 （しかし、実際には、このコードを記述した方法でBufferの戻り値の型としてimpl BufReadを使用する代わりに、 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は混乱を招きます。 Bufferの戻り値の型としてimplBufReadを使用する代わりに、Self :: BufReaderを意味していると思いますよね？

はい、ソリューションをimpl特性ベースのソリューションに変更してから元に戻しましたが、特性の戻り値の型を見逃していました。

Rustsに似ているように見えるので、この言語の型システムのようなものも興味深いかもしれませんが、いくつかの機能を備えているため、現在の問題を解決できる可能性があります。
（ A <: Bは、 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が特別であるためか、 Defaultがタプルに実装されていないのにDisplayが実装されていないためでしょうか。

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

デフォルトで関数を呼び出すか、パラメーターがunitの場合は値を返します。
競合する実装についても同じエラーが発生します。
専門分野でそれを行うことは可能です（またはこれは可能でしょうか）？
そうでない場合、代替手段は何ですか？

編集：私はそれがコンパイルされない理由を理解したと思います：
Tでfor Tより一般的である()でfor ()最初にimpl特殊であることはできません。
また、 CはC: Fn(Self) -> Rよりも一般的であるため、2番目のimplを特殊化することはできません。
私が間違っているかどうか教えてください。
しかし、 Displayの最初の例で機能しない理由はまだわかりません。

これは現在正しい動作です。

Custom例では、特別なローカルの否定的な推論のために、これらのimplはオーバーラップしません。 特性はこのクレートからのものであるため、 Custom実装を持たない() 、 T: Customと重複しないと推測できます。 専門化は必要ありません。

ただし、クレートに由来しない特性については、この否定的な推論は実行しません。 標準ライブラリは次のリリースでDisplay for ()を追加する可能性があり、それが重大な変更になることは望ましくありません。 私たちは、図書館にそのような変更を加える自由を持たせたいと思っています。 したがって、（）は表示を意味しませんが、重なりチェックでその情報を使用することはできません。

ただし、（）はDisplayを意味しないため、 T: Displayよりも具体的ではありません。 これが特殊化が機能しない理由ですが、デフォルトの場合は(): Defaultであるため、そのimplはT: Defaultよりも具体的です。

このような暗黙の意味は、「辺獄」のようなものであり、重複することも重複しないことも想定できません。 これを機能させるための原則的な方法を見つけようとしていますが、これは特殊化の最初の実装ではなく、後で提供されるその機能の下位互換性のある拡張機能です。

生涯に関連する健全性の問題を追跡するために＃40582を提出しました。

スペシャライゼーションを使用しようとして問題が発生しました。@ antoyoの問題とはまったく同じではないと思います。別の問題として提出しました。＃41140、必要に応じてサンプルコードをここに取り込むことができます。

@ afonso360いいえ、別の問題で問題ありません。

一般的なポイントとして：この時点で、チョークの作業では専門化の作業がブロックされます。これにより、健全性の問題に取り組むことができ、今日ヒットしているICEをクリアできる可能性があります。

これがバグなのか、意図的に禁止されているものなのかを誰かが明確にできますか？ https://is.gd/pBvefi

@sgrifここでの問題は、デフォルトの関連タイプの投影が許可されていないことだけだと思います。 ただし、診断の方が優れている可能性があります： https ：

なぜそれが許可されないと予想されるのかについて詳しく教えてください。 孤立したルールに違反するため、これ以上特定のimplを追加できないことはわかっています。

このコメントは、健全性を要求するために必要な場合もあれば（理由はわかりませんが）、インターフェースのコンシューマーにそれを抽象型として扱うように強制する必要があることを示しています： https ：

誰かがhttps://github.com/rust-lang/rust/issues/31844#issuecomment-266221638を見ることができたことがありますか？ これらのimplは、私が知る限り、特殊化によって有効になるはずです。 それらを妨げているバグがあると思います。

@sgrifコードの問題は、 https： //github.com/rust-lang/rust/issues/31844#issuecomment-284235369の問題と同様である可能性があると思いますwithoutboatsはhttps://github.comで説明してい@ 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実装を選択することを期待します。このコードを許可しても、上位互換性には影響しません。互換性。

全体として、専門分野を扱うのは非常に苛立たしいと思います。 私が期待するほとんどすべてが機能しない。 私が特殊化で成功した唯一のケースは、 T where T: AとT where T: A + Bを含む2つのimplがあるなど、非常に単純なケースです。 他のものを機能させるのに苦労しています。エラーメッセージには、特殊化の試みが機能しない理由が示されていません。 もちろん、まだ道のりはあるので、あまり役立つエラーメッセージは期待していません。 しかし、（上記のように）実際に何かが機能することを期待しているケースはかなりあるようですが、そうではありません。現在、許可されていることを誤解しているためかどうかを確認するのは非常に困難です（さらに重要なのは、理由）、何かが間違っている場合、または何かがまだ実装されていない場合。 この機能が現状のままで何が起こっているのかについての概要は非常に役立ちます。

これが適切な場所にあるとは思いませんが、ここで言及したいユーザーフォーラムで問題が発生しました。

次のコード（ここでは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上記の例の関連するタイプのみに特化している場合、 generateのdefaulti implはタイプチェックしません。

こちらのスレッドへのリンク

@ 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を導出することは危険であり、非常に微妙なバグにつながる可能性があることに注意してください。 これらのデフォルトのimplを使用すると、これらの特性を導き出す誘惑が少なくなるため、問題はある程度軽減されます。

または、特殊化を利用するように派生を変更します。 例えば、書き込み#[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))
    }
}

このようにして、 Ordが実装されていない場合、デフォルトのimplが使用されます。 ただし、そうである場合、 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が2つの重複するクロージャのセットを表し、多くの場合、両方の特性を実装する必要があるためです。

rfc 2132の表現は、クロージャが5種類しかないことを意味しているように思われることを理解してください。

• FnOnce （キャプチャされたすべての変数がCopyでもCloneでもないmoveクロージャ）
• FnOnce + Clone （キャプチャされたすべての変数がCloneあるmoveクロージャ）
• FnOnce + Copy + Clone （ moveクロージャ、キャプチャされたすべての変数はCopyであるため、 Clone ）
• FnMut + FnOnce （キャプチャされた変数が変更されたmoveクロージャ）
• Fn + FnMut + FnOnce + Copy + Clone （キャプチャされた変数が変更されていないmoveクロージャ）

したがって、近い将来に仕様が利用できなくなった場合は、 Fn特性の定義を更新して、 FnがFnOnce + Cloneと重複しないようにする必要がありますか？

誰かがCopy/CloneなしでFn特定のタイプをすでに実装している可能性があることを理解していますが、これは非推奨にする必要がありますか？ 同じことをするより良い方法は常にあると思います。

以下は特殊化によって許可されることになっていますか（ 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 ：

https://github.com/rust-lang/rust/issues/48444である@glandium

それは...ですか？ 私の例には空のimplはありません。

@glandium

 impl B for Foo {}

@MoSalですが、 Bはデフォルトの実装でメソッドを追加するため、そのimplは「空ではありません」。

@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

専門化は、起こりうる将来の対立を防ぎませんか？

よかった、これは動きの遅い機能です！ 2年以上経っても進展はないようです（確かに元の投稿によると）。 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 implではなくfnをデフォルトにすると、ユースケースは機能します。

#![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/を参照して

私の推測では、誰もが今エディションに集中していると思います...

わかりましたありがとう...この問題は永遠に続いているようですが、十分に公平です。 大変だと思います。 残念ながら、現在、他の場所に注意が向けられています。

完全に単形の場合にデフォルトの関連タイプの予測を許可しない背後にある理論的根拠を誰かがより具体的に説明できますか？ その機能が必要なユースケースがあり（特に、完全に単形ではない型でトレイトが呼び出されることは意味的に正しくありません）、健全性の問題がない場合は、理由が完全にはわかりません。許可されていません。

@pythonesquehttps：//github.com/rust-lang/rust/pull/42411でいくつかの議論があります

ああ、プロジェクションが一般的にスペシャライゼーションとひどく相互作用することが判明したかどうかはわかり

残念ながら、そのような機能なしで私がやりたいことを本当に行う方法があるかどうかはわかりません。特定の特性を実装する2つの渡された型が構文的に等しい場合に、「True」を出力する関連付けられた型が必要です。そして、そうでない場合は「False」（「False」の場合は、「意味的に」等しいかどうかを判断できる、より高価な特性検索をトリガーします）。 唯一の本当の選択肢は（私には）常に高価な検索を行うことだと思われます。 これは理論的には問題ありませんが、はるかに高価になる可能性があります。

（トレイトが閉じられることを意図している場合は、ヘッド位置にあるコンストラクターの可能なすべてのペアを列挙し、それらにTrueまたはFalseを出力させることで、これを回避できますが、リポジトリーの外部で拡張できるようにすることを目的としています。特に、2つの異なるユーザーリポジトリでの実装が必ずしもお互いを認識しているとは限らないため、機能しない可能性があります。

とにかく、これは私がやりたいことが特性システムに適していないことを示しているだけかもしれません。マクロのような他のメカニズムに切り替える必要があります：P

そして、私が望んでいるのは「否定的な推論」のフレーバーであることは確かに真実です（ただし、閉じた特性は実際には十分ではありません）。

否定的な推論の代わりに、型が閉じた特性のセットの1つの特性のみを実装することを要求し、セット内の他の特性との実装が重複しないようにします（たとえば、 Tは{ Float | Int | Bool | Ptr }つを実装します） ）。

Rustでそれを強制する方法があったとしても（AFAIKはありませんか？）、それが私の問題を解決するとは思いません。 異なるクレートのユーザーが任意の数の新しい定数を実装できるようにしたいと思います。これらの定数は、クレートの定義時に不明なものを含め、自分だけに等しく、他のすべての定義済み定数と等しくない必要があります。 閉じた特性のセット（または特性のファミリーのセット）がそれ自体でその目標をどのように達成できるかわかりません。これは、タイプを直接見ないと基本的に解決できない問題です。 デフォルトのプロジェクションで機能する理由は、すべてをデフォルトで「等しく比較しない」に設定してから、定数を定義したクレートに新しい定数の同等性を実装できるためです。これにより、孤立状態に陥ることはありません。特性実装のすべてのタイプが同じクレートにあったため、ルール。 平等以外のほとんどすべてのそのようなルールが

現在の毎晩、これは機能します：

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 ()できないため、コンパイラはこれを許可しますが、2番目の例では、ダウンストリームクレートはimpl Bar<CustomType> for ()あり、デフォルトのimplと競合します。

@Boscopそのシナリオでは、デフォルトのimplは、とにかく以下のデフォルト以外のimplによってオーバーライドされます。 たとえば、他のimplの前に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);
}

さらに、上記の例では、私が経験した奇妙なことです-デフォルトのHandler 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のハンドラーを呼び出すコードはありませんが、特殊化が存在しないと、コードがコンパイルされません。

編集：これは、 Gladdyが1つの投稿に同じようです。

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メソッドがないため、 impl<E: std::error::Error> MyTrait for Eを特殊化することはできません。

@ 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

クレートbarをに変更する場合は注意してください

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

次に、クレートfooコンパイルされます。

@ bjorn3それをdefaultメソッドは必要ないようです（遊び場）。

@KrishnaSannasiあなたの例（ playground ）で「競合する実装」エラーを再現することはできません。

更新：ああ、なるほど。 トレイトBarは、例が機能するために上流のクレートからのものである必要があります。

FooはError実装していないため、例の@updogliuは特殊化を示していません。

今夜はプログラミングが遅すぎますか、それともスタックオーバーフローを引き起こしてはいけませんか？

#![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を見ると、固有のimplの特殊化に関するセクションがあります。 誰かが私が試したことを与えましたか？

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メソッドの場合、型の特性のこれらのimplはconstimplである必要があると思います。

これに出くわし、ステータスに興味がある人にとっては、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が次のように書いています（例として、別のコンテキストで、太字の鉱山）。

[専門分野で]十分に解決されなかった重要な問題が1つありました。それは、寿命と特性に関する技術的な健全性の懸念です[...]次に、[上記の2つの投稿]。 これらのアイデアは、基本的に問題を解決してきたが、我々はその間に忙しかったし、フォローアップする時間がなかった

まだやるべきことが明らかに残っていますが、希望に満ちているようです。

（数週間前にこのスレッドを見つけて昨年の進捗状況がわからなかったため、これを投稿しましたが、最近、偶然にそれらの投稿に出くわしました。上記のコメントがありますが、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

@Hexileeimplではなくメソッドにdefaultを置きます。

@KrishnaSannasiの例2

@zserikはい、わかっています。 まだ実装されていないか、削除されたと思います。 いずれにせよ、今は機能しません。

明らかに現在は機能していませんが、機能するはずです。

このトピックが他の場所で取り上げられていることに気付いていないので、ここでこれを尋ねています- constと同様に、さまざまな標準ライブラリ関数をdefaultする計画はありますか？安全であると見なされたときにconst化された関数？ 私が尋ねている主な理由は、デフォルトのジェネリック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 ：

@Osspialさて、デフォルトのimplを使用してシミュレーションしようとすると、問題が発生します。

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

繰り返しますが、 From/Into implを標準ライブラリのデフォルトimplに変更しても、 Into汎用implは使用できません。 （そしてそれはFrom一般的な実装には影響しません）

こんにちは、現在のスペシャライゼーションの実装には重大なバグがあります。 明示的な設計上の決定であったとしても、最も強力な特殊化機能の1つ、つまり「不透明（OPAQUE）型」（正式な名前ではない）の作成の可能性を使用できなくなるため、バグとしてラベル付けします。 このパターンは、HaskellやScalaなどの型クラスを提供する他の言語で最も原始的な構成要素の1つです。

このパターンは単純です。 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種類で簡単です。 ただし、 WithID 、 WithLabel 、 WithCallbackなどのさまざまなフィールドを追加する10種類の不透明（OPAQUE）型の定義があると想像してください。 スペシャライゼーションの現在の動作では、1000を超える異なるトレイトの実装を定義する必要があります。 コメントアウトされたコードが受け入れられる場合、必要な特性の実装は10個だけであり、新しいタイプを実装するために必要な追加の実装は1つだけです。

あなたのコードが特殊化にどのように関連しているかわかりません。 最初の#![feature(specialization)]行が削除された場合でも、引数（最初のコードはコンパイルされますが、コメント付きのtest(v1);行は手動のimplがないとコンパイルされません）が適用されます。

@qnighyコードは、impls HasLabel for TとHasID for Tコメントを解除した後にコンパイルする必要があります-それらは特殊化を使用しています。 現在、それらは拒否されています（私が提供したコードでコメントを外してみてください！）。 今あなたにとってそれは理にかなっていますか？ 🙂

3つのインスタンスWithLabel<WithID<A>> 、 WithID<WithLabel<A>> 、およびWithLabel<WithLabel<A>>について考えてみましょう。 次に

• 最初のimplはWithLabel<WithID<A>>とWithLabel<WithLabel<A>>カバーします。
• 2番目のimplはWithID<WithLabel<A>>とWithLabel<WithLabel<A>>カバーします。

したがって、implのペアはRFCの次の節

特殊化の一貫性を確保するために、重複する2つのimpl IとJに対して、 I < JまたはJ < Iいずれかがあることを確認します。 つまり、一方が他方よりも本当に具体的でなければなりません。

また、 WithLabel<WithLabel<A>>のHasLabel implは2つの方法で解釈される可能性があるため、これはあなたの場合にも実際の問題です。

このケースをどのようにカバーできるかはRFCでもすでに

ラティスルールが対処する制限は、（動機付けで説明されているように）特殊化の主な目標のかなり二次的なものであり、ラティスルールは後で追加できるため、RFCは今のところ単純なチェーンルールに固執します。

@qnighy 、考えてくれてありがとう。

また、 WithLabel<WithLabel<A>>のHasLabel implは2つの方法で解釈される可能性があるため、これはあなたの場合にも実際の問題です。

これは、 impl<T> HasLabel for WithLabel<T>がWithLabel<WithLabel<A>>入力に対してimpl<T> HasLabel for Tよりも特殊であると見なさない場合に当てはまります。 貼り付けた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を悪用して、マーカー以外の特性を重複させることができますが、このハックにはさらに3つの特性が必要です（1つはマーカー特性を通過するため、2つは特殊化によって消去されたデータを再取得するため）。

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

@qnighyこのバグについて別の問題を作成しました： https ：

わかりました。（https://doc.rust-lang.org/nightly/unstable-book/language-features/optin-builtin-traitsによると） auto traitsがここで解決されることは決してないことを発見しました。 html）それらは構造体のすべてのフィールドに伝播します：

標準ライブラリのSendやSyncなどの自動トレイトは、タイプまたはそれに含まれるタイプが負のimplを介して明示的にオプトアウトされていない限り、すべてのタイプに自動的に実装されるマーカートレイトです。

編集
@qnighyどういうわけか、あなたが遊び場へのリンクを提供しているのを見落としていました。 ❤️ありがとうございました。 それは機能し、私はこのソリューションがいかにハッキーであるかに驚いています。 現在それを表現できるのは素晴らしいことであり、この可能性が将来消えないことを願っています！

このような状況では、現在使用できるハックはoverlapping marker traitsだけですが、将来、不透明（OPAQUE）型を表現するための何らかの簡単なソリューションを許可するとよいと思います（以前の投稿で説明したように：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を呼び出して、特殊なバリアントを取得するかどうかを確認します）。 おそらく、2つのバリアントは同等であると言っていますが、1つはより高速であると考えられているため、どちらのバージョンを取得しているかをテストする方法がわかりません。 その場合、私は同意します、私はあなたが今それをどのようにテストすることができるかわかりません。

同じimplのセットを使用して他の特性を作成すると思いますが、fnsの動作が異なる場合は、安心してください。

おそらく、2つのバリアントは同等であると言っていますが、1つはより高速であると考えられているため、どちらのバージョンを取得しているかをテストする方法がわかりません。 その場合、私は同意します、私はあなたが今それをどのようにテストすることができるかわかりません。

マクロを使用してそれをテストできます。 私は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!()を使用し、テストでは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が文書化される可能性はありますか？ 健全性のバグがわかっている（場合によっては不明な）ものよりも、完全に文書化されていない機能をクレートで使用する方がリスクが高いと感じています。 どちらも良いことではありませんが、少なくとも後者はコンパイラの内部だけではありません。

＃71321 PRの外で、この追跡の問題からmin_specializationについての言及を見つけることができませんでした。不安定な本によると、これはその機能の追跡の問題です。

その機能についてもよくわかりません。libstdの健全性の修正を見ただけです。 https://github.com/rust-lang/rust/pull/68970で紹介されており、それについてさらにいくつかのことが説明されてい

@matthewjasperこれをもう少し文書化して、 feature(specialization)夜間ユーザーに移行を依頼するのは理にかなっていますか？

少なくとも警告があるはずのようです。 この機能は明らかに壊れており、現在の状態で使用するのは危険なようです。

specializationはmin_specialization同義語になる可能性があると思いますが、PyO3などの既存のプロジェクトに必要な場合は、別のunsound_specialization機能を追加します。 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いずれかのメンバーをオーバーライドする場合、それらすべてをオーバーライドする必要があるということでした。 その後、このアイデアを撤回し、「デフォルトグループ」（ここでも機能します）などのさまざまな反復を開始しましたが、対処すれば後で到達できると考えたため、最終的にはソリューションを採用しませんでした。もう1つは、差し迫った問題です（cc＃71420）。

現在、PyO3（Pythonバインディングライブラリ）は専門分野に依存しています。 PyO3 / pyo3＃210を参照してください

ここのPyO3メンテナー-安定したRustに乗れるように、専門分野から離れることに賛成です。 min_specializationは、残りのスペシャライゼーションが完了する前に安定する可能性がありますか？

2021年版の計画言語設計会議でmin_specializationを安定させることを試みることについての議論があったと思います（それはyoutubeにあります;申し訳ありませんが、私は私の電話にいます、または私はリンクを見つけようとします）。 私は彼らがそれについて言ったことを忘れました

2021年版の計画言語設計会議でmin_specializationを安定させることを試みることについての議論があったと思います（それはyoutubeにあります;申し訳ありませんが、私は私の電話にいます、または私はリンクを見つけようとします）。 私は彼らがそれについて言ったことを忘れました

これは正しいYouTubeリンクだと思います： https ：
（私の電話でも）

うん、それだけです。 特定のディスカッションへのリンクは次のとおりです： https ：

私は自分が開発している実験ライブラリで#[min_specialization]しているので、自分の経験を共有したいと思いました。 目標は、特殊化を最も単純な形式で使用することです。つまり、一般的なケースよりも実装が高速な狭いケースをいくつか持つことです。 特に、一般的なケースで暗号化アルゴリズムを一定時間で実行するが、すべての入力がPublicとマークされている場合は、より高速な可変時間で実行される特殊なバージョンがあります（公開されている場合は公開されていないため）実行時間を介してそれらに関する情報を漏らすことに注意してください）。 さらに、一部のアルゴリズムは、楕円曲線点が正規化されているかどうかに応じて高速になります。 これを機能させるには、まず

#![feature(rustc_attrs, min_specialization)]

次に、最大限に最小限の特殊化で説明されているように_特殊化述語_特性を作成する必要がある場合は、特性宣言に#[rustc_specialization_trait]マークを付けます。

私のすべての特殊化はこのファイルで行われ、例です。

この機能は機能し、私が必要としていることを正確に実行します。 これは明らかにrustc内部マーカーを使用しているため、警告なしに破損する傾向があります。

フィードバックの唯一の否定的な点は、 defaultキーワードが意味をなさないと感じていることです。 基本的に、現在default意味するのは、「このimplは特殊化可能であるため、このimplのサブセットをカバーするimplを、競合するimplではなく特殊化として解釈する」ということです。 問題は、非常に奇妙なコードにつながることです。

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

ここで、2番目のimplは最初のimplを特殊化していますが、これもdefaultです。 defaultの意味が失われているようです。 残りのimplを見ると、どのimplがどれを専門にしているのかを理解するのは非常に困難です。 さらに、既存のものと重複する誤ったimplを作成したとき、どこが間違っているのかを理解するのが難しいことがよくありました。

すべてが特殊化されていて、何かを特殊化するときに、どのimplを特殊化するかを正確に宣言すると、これはより簡単になるように思えます。 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なしで実装できますが、2つのタイプを異なるOutputタイプと共存させたくない場合があります。 IndexSetはIndexMutに関してデフォルトの実装を持つことができるので、 Output特殊化を許可せずに、 index_setメソッドの特殊化を許可することは合理的です。

私はビデオで苦労しているので、リンクされたビデオを検索することはできませんが、 #[min_specialization]について1つの質問があります。 現状では、 FusedIteratorような特性には、最適化のヒントを提供するrustc_unsafe_specialization_marker属性があり、それらを専門にすることができます。 @matthewjasperは書いた：

これは不健全ですが、トレイトメソッドに特化するのと同じように、純粋に安全なコードで解放後に使用することはできないため、短期的には許可します。

計画は@aturonの提案を実装し、これらのような特性（ where specialize(T: FusedIterator) ）の特殊化モダリティを追加することだと思います。 しかし現在、どのコードもこれらの特性に特化できるようです。 それがそのまま安定していれば、人々はそれに依存する安定した専門分野を書くことができます。つまり、この不健全さが安定することを意味します。

では、これらの特性の専門化も標準ライブラリに限定する必要がありますか？ 標準ライブラリは、それらに特化できることから十分な利益を得ていますか？

それがそのまま安定していれば、人々はそれに依存する安定した専門分野を書くことができます。つまり、この不健全さが安定することを意味します。

min_specializationは現状のままでは、安定化を目的としたものではないことを理解しています。

次に、implの特殊化に何らかのマーカーを付けたいと思います。 特殊化が実際に行われていることを知る方法がないため、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は、特殊なimplがマークされていないという事実により、包括的implの変更を壊さないようにする方法を提供します。 新しいdefault impl<T> Trait for Tは、ダウンストリームのimplと競合しません。これらは、特殊化するだけです。

マークを外すだけの警告でしょうか？

特殊化が実際に行われていることを知る方法がないため、rustcと標準ライブラリのコードが見た目どおりに動作しないケースがかなりあります。

私のJavaの経験は似ています（正確には似ていませんが）。 クラスのどのサブクラスが実際に実行されているかを見つけるのは難しい場合があります...

ただし、読みやすくするために、特殊なimplにもマーカーが必要です。

マーカーを両方の場所に配置すると、特殊化が必要かどうかがわかり、存在する場合は別の場所を指すことができるため、rustcエラーまたは警告メッセージが改善されます。

アップストリームクレートがimplを追加する場合、単にアップグレードする以外に、ダウンストリームクレートは、新しいバージョンと古いバージョンの両方に対してコンパイルできるトリックを使用する可能性がありますが、それが有益かどうかはわかりません。

差分が大きすぎて変化が見られないのではないかと思います。 これを指しています： https ：

Re：ブランケットは、とにかく変更を壊しています：

• それらは、許可されていないダウンストリームimplと部分的にオーバーラップする可能性があります
• コヒーレンスは、より微妙な方法でそれらが存在しないと想定できます（これが、予約の実装が内部で追加された理由です）
• 特殊なimplは常に適用可能である必要があります。つまり、次のいずれかです。
  
  
  
  • 私たちは人々の暗黙を破ります（ min_specializationがすること）。
  
  
  • 必要に応じて常に適用できるように、何らかの方法で特性の境界に注釈を付ける必要があります。
  
  
  • それらに常に適用可能な変更を暗黙的に行い、デフォルトのimplが適用されると、微妙なランタイムバグが発生する可能性があります。
  
  

@cuviper実は、特殊化したとしても、新しいブランケットimplを追加することに関してはまだエッジケースがあったように感じます。 impl<T: Copy> Clone for T { }インプを追加するのに何が必要かを理解しようとしていたことを覚えています。いずれにせよ、

とにかく、 #[override]アノテーションがないことを糸くずの警告にすることができます。

とは言うものの、ユーザーがどのimplを専門にしているのかを宣言することができれば（どのように行うのかわからない）、いくつかのことが単純化されます。 現在、コンパイラはimpl間の関係を推測する必要があり、それは常に少し注意が必要です。

チョークプロジェクトで私たちがしなければならない保留中の項目の1つは、戻って、そこで専門性をどのように表現すべきかを詳しく説明することです。

特殊化が実際に行われていることを知る方法がないため、rustcと標準ライブラリのコードが見た目どおりに動作しないケースがかなりあります。

私のJavaの経験は似ています（正確には似ていませんが）。 クラスのどのサブクラスが実際に実行されているかを見つけるのは難しい場合があります...

5月に、重複するimplに実際には依存せず、型パラメーターで単一のimplをwhere matchに許可する、IRLOの特殊化の代替案を提案しました。

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を使用して「特殊化」を実装できます。これは、慣例により、トレイト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"
}

この定式化により、上流で適用可能なimplの順序を選択するための制御が強化されます。これは特性/関数のシグネチャの一部であるため、ドキュメントに表示されます。 IMOは、解決順序が明示的であるため、どのブランチが実際に適用可能かを知るための「暗黙の追跡」を防ぎます。

これにより、特殊化の実装中にアップストリームのみがそれらに対応できるため、ライフタイムとタイプの同等性に関するエラーがより明らかになる可能性があります（ダウンストリームは「特殊化特性」のみを実装しているため）。

この定式化の欠点は、RFCのルートとは大きく異なり、2016年以降に実装されていることと、スレッドの少なくとも一部の人々が、現在のルートほど表現的および/または直感的ではないことへの懸念を表明したことです。特殊化機能（「タイプのマッチング」は非常に直感的ですが、定式化を提案するときに偏りがあります）。

一致構文には、別の（構文上の）利点がある可能性があります。将来のある時点で、constで評価された一致ガードで拡張された場合、const式を条件として境界を表現するために体操を行う必要はありません。 たとえば、 size_of 、 align_of 、 needs_dropまたは配列サイズに基づいて特殊化を適用できます。

@dureuill情報をありがとう！ それは確かに興味深いアイデアです。 私が懸念していることの1つは、特殊化のために予想される他のユースケースのいくつか、特にこのブログ投稿で@aturonによって説明されている「段階的に洗練された動作」のケースを必ずしも解決しないことです。 それでも、覚えておく価値はあります。

@dureuillこのアイデアは確かに興味深く、多くの可能性を秘めているかもしれませんが、代替案は必ずしも同等の交換ではありません。
私がそうは思わない理由は、より一般的な実装を完全に置き換える機会が与えられていないからです。 また、別の問題は、提案が依存するwhere構文RFCに存在するすべての機能を実際にサポートしていないという事実である可能性があります。
提案は興味をそそるので、おそらくそれは専門化の競争相手ではなく、別個の機能としてそれ自身のRFCを持っている可能性があります。

@ the8472 @nikomatsakis、ダーク軍団@：正のフィードバックをありがとう！ 追跡の問題についてあまりうるさくなりたくないので、 IRLOスレッドであなたの

公開可能なものを書くことができれば、別のRFCを開くことができます。 その間、私はリンクされたIRLOスレッドに関するフィードバックを非常に

私はまた、implを専門化する上である種のマーカーを持つことに賛成です。

2021 Editionのアプローチにより、さらにキーワード（ 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 （ implはimplementようにspecialize略）（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 （ implはimplementように、 specialize略）

「spec」は、「specification」の省略形（「HTML 5 spec」など）としてすでに人々に親しまれているため、「specialize」の省略形としては適切ではないと思います。

overrideは予約済みのキーワードです。関数を対象としていると思いますので、implブロックで使用できる可能性があります。

specializeはロケールにも依存します-オーストラリア人としては私に特化しているので、「spec」を使用するとロケールのあいまいさがなくなります。

specializeはロケールにも依存します-オーストラリア人としては私に特化しているので、「spec」を使用するとロケールのあいまいさがなくなります。

'spec'は仕様の一般的な略語であるという点を除いて、これは機能します。したがって、 'spec'を使用して特殊化を意味するのは混乱を招くと思います。 オーストラリアでは単語のスペルが異なっていても、「z」または「s」のいずれかでスペルされていれば、誰もがどの単語が意図されているかを理解できます。

カナダ人として、私は専門分野/専門分野だけがロケールによって異なるプログラミングで使用される単語ではないと言わなければなりません。

ここでは「色」を使用していますが、プログラミング言語やライブラリが「色」の代わりに「色」を使用している場合は、まれにつまずきます。 良くも悪くも、アメリカ英語はAPI設計の事実上の標準であり、色/色などの単語では、実際に工夫することなく、一方のスペルを他方よりも優先することを選択することは避けられません。

「仕様」が「仕様」を意味することをどれほど強く期待しているのかを考えると、これは、アメリカ英語のスペルを最悪の選択肢と見なす必要があるもう1つの状況だと思います。

それは事実かもしれませんが、それはそれらを使用しても大丈夫だという意味ではありません。 たとえば、「色を色として使用する」などのインポートを行っています。 私はいつもs対zにもつまずきます。 包括性とアクセシビリティに対するRustの前向きな姿勢を考えると、色/色やs / zなどの小さなユーザーの欲求不満が高まるため、ロケールに依存しない言語用語を選択することは理にかなっていると思います。

原則として同意します。 この場合、解決する以上の問題を引き起こさないロケール中立の選択があるのではないかと私は懐疑的です。

英語を母国語としない人として、英語を母国語とする人が、包括性の障壁として余分なuについて不平を言うのは少し面白いと思います。 すべてが少し奇妙な綴りではなく、まったく異なる言語で書かれているとしたらどうなるか想像してみてください。

言い換えると、Rustで使用されるすべての用語はロケールに依存します。

良くも悪くも、Rustの内容はアメリカ英語で綴られています。 ここの多くの人にとって、これは彼らの第二または第三言語で働くことを意味します。 他の人にとっては、スペルを少し調整する必要があることを意味します。 これは、たくさんの人々が一緒に働くようにするために必要なことです。 英語の多くのバリエーションで同じスペルの単語を選択することの利点は、明確な用語を選択することと比較してわずかであると思います。また、上記で指摘したように、 specはあいまいです。

キーワードとしてspecialを使用しますか？

別の方法として、 specializeとspecialise 2つのキーワードを作成し、それらを同等にします...

（または、面白い非アメリカ人は本当の適切なスペルを学ぶことができます：us：😂）

私はほとんどの言語が何をするかについて話すことができませんが、CSSはすべての新しいものにアメリカ英語のスペルを使用します。 逸話的に、アメリカ英語はプログラミングでもより頻繁に使用されているようです。

@ mark-im残念ながら、それは滑りやすい坂道であり、Rustは、学習者が来る可能性のあるすべての主要言語で代替のキーワードセットを使用する必要があるという議論につながります。

また、人々とパーサーは空白がそのように変化する可能性があるという考えにしか慣れていないため、キーワードの複数の同義語を持つように言語を不必要に複雑にします。

（言うまでもなく、ライブラリ内の同等の同義語のプッシュに影響を与える可能性があり、その場合、それらが正味のネガティブにならないようにするためにrustdocの設計と実装作業が必要になります。）

この識別子をどの英語の方言に入れたいかについて議論するのではなく、妥協してヘブライ語に入れることができるでしょうか。

@ssokolowは、一般的に滑りやすい坂の議論を使用するための強力な議論ではありませんが、この場合はあなたに同意します。 複数の言語で問題ないと主張する人もいるかもしれませんが、そうでない理由は少なくとも2つあります。

• 異なる言語のいくつかの単語は同じように見えますが、意味が異なります（現在、プログラミング関連の例を思い付くことができませんが、ランダムな例：スロバキア語のa andは英語の
• 人々は言語を知っている場合でも、別の言語での巨大なトラブルの読み取りコードを持っています。 私は経験から知っています。 （簡単に言えば、大学教育詐欺で、英語から私の「母国語」に直接翻訳された用語を含むいくつかのテキストを理解するのに非常に苦労しました。）

今、逆に取り組んでいますが、他の言語ではないにしても、なぜ英語の異なる方言が好まれるのですか？ 意味がわかりません。 一貫性（すべてが米国英語）は、最も単純で、理解しやすく、エラーが発生しにくいようです。

そうは言っても、「XXXのことですか？」ととても嬉しいです。 エラーメッセージアプローチ。 他に問題のない中立的な言葉でも構いません。

少なくとも、コードでサッカーについて議論する必要はありません。 ;）

英語を母国語とする人の約70％は、米国のスペルを使用している国に住んでいます。

また..

「-izeのつづりは、英国ではアメリカニズムと誤って見なされることがよくあります。15世紀から使用されており、-iseより1世紀以上前に使用されています。-izeはギリシャ語の-ιζειν-izeinとラテン語の-izāreに直接由来します。 iseはフランス語の-iserを介して提供されます。OxfordEnglishDictionary（OED）は、-izeを推奨し、代わりに-ise形式をリストしています。」

「オックスフォード大学出版局（OUP）による出版物（ヘンリーワトソンファウラーの現代英語用法辞典、ハートの規則、オックスフォード英語使用法ガイドなど）も-izeを推奨しています。ただし、ロバートアランのポケットファウラーの現代英語用法はどちらの綴りも考慮しています。米国以外のどこでも受け入れられるように」

参照。 https://en.wikipedia.org/wiki/American_and_British_English_spelling_differences# -ise、_- ize _（-isation、_- ization）

スペイン語とイタリア語にはazが1つか2つあるようですが、フランス語がどこで取得されるかわからないので、おそらくドイツ語からですか？

特定のキーワードと名前の周りのバイクシェディングを内部スレッドに移動でき