Rust: विशेषज्ञता के लिए ट्रैकिंग मुद्दा (RFC 1210)

कुछ अतिरिक्त खुले प्रश्न:

• क्या हमें विशेषज्ञता के प्रकाश में अनाथ नियमों को फिर से देखना चाहिए? क्या अब चीजों को अधिक लचीला बनाने के तरीके हैं?
• क्या हमें RFC में "चेन रूल" को कुछ अधिक अभिव्यंजक के रूप में विस्तारित करना चाहिए, जैसे तथाकथित "जाली नियम"?
• उपरोक्त दोनों से संबंधित, कहानी में नकारात्मक तर्क कैसे फिट बैठता है? क्या हम विशेषज्ञता / अनाथ नियमों के एक चतुर पर्याप्त उपयोग द्वारा आवश्यक नकारात्मक तर्क को ठीक कर सकते हैं, या हमें इसे और अधिक प्रथम श्रेणी में लाना चाहिए?

मुझे यकीन नहीं है कि विशेषज्ञता अनाथ नियमों को बदल देती है:

• "लिंकिंग" अनाथ नियम समान रहना चाहिए, क्योंकि अन्यथा आपके पास सुरक्षित लिंकिंग नहीं होगी।
• मुझे नहीं लगता कि "भविष्य की संगतता" अनाथ नियमों को बदलना चाहिए। आपके अधीन एक गैर-विशिष्ट जोड़ जोड़ना अभी भी एक ब्रेकिंग परिवर्तन होगा।

इससे भी बदतर, "भविष्य की अनुकूलता" अनाथ नियम बहुत भारी नियंत्रण में क्रॉस-टोकरा विशेषज्ञता रखते हैं। उनके बिना, उनके तरीकों को खुला छोड़ने के डिफ़ॉल्ट-बहुत अधिक बुरे हो जाते हैं।

मुझे स्पष्ट नकारात्मक तर्क पसंद नहीं आया। मुझे लगता है कि कुल नकारात्मक तर्क विशेषज्ञता प्रदान करता है एक अच्छा समझौता है।

क्या इस निहितार्थ को विशेषज्ञता के साथ लागू किया जाना चाहिए? या क्या मैं कुछ न कुछ भूल रहा हूं?
http://is.gd/3Ul0pe

इस एक के साथ भी, यह संकलन करने की उम्मीद की होगी: http://is.gd/RyFIEl

लगता है कि जब संबंधित प्रकार शामिल होते हैं तो ओवरलैप का निर्धारण करने में कुछ विचित्रताएँ होती हैं। यह संकलित करता है: http://is.gd/JBPzIX , जबकि यह प्रभावी रूप से समान कोड नहीं है: http://is.gd/0JLLX

यहाँ विशेषज्ञता के साथ संकलन करने के लिए अपेक्षित कोड का एक टुकड़ा है:

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 एक जोड़ी नहीं है (इसलिए यह पहली बार के निहितार्थ से मेल खाता है, लेकिन दूसरे से नहीं)।
• आपके पास संभावित रूप से (T, U) :
  
  
  
  • T: FromSqlRow<ST, DB> ,
  
  
  • U: FromSqlRow<SU, DB> , लेकिन _not_
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  
  • (इसलिए दूसरा अंतर्निहित मैच, लेकिन पहले नहीं)
  
  
• दो ओवरलैप होते हैं क्योंकि आपके पास (T, U) ऐसे हो सकते हैं:
  
  
  
  • T: FromSqlRow<ST, DB>
  
  
  • U: FromSqlRow<SU, DB>
  
  
  • (T, U): FromSql<(ST, SU), DB>
  
  

यह इस तरह की स्थिति है कि जाली के प्रत्यारोपण की अनुमति होगी - आपको ओवरलैपिंग के मामले के लिए तीसरा प्रत्यारोपण लिखना होगा, और कहेंगे कि इसे क्या करना चाहिए। वैकल्पिक रूप से, नकारात्मक लक्षण आच्छादन आपको ओवरलैप या अन्यथा मिलान करने का एक तरीका दे सकता है जो मैच संभव हैं।

उदाहरण 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>

लेकिन न तो निहित अधिक विशिष्ट है:

• आपके पास 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

उन दो मामलों को स्पष्ट करने के लिए धन्यवाद। यह अब पूर्ण समझ में आता है

Tue, Mar 22, 2016 को, 6:34 अपराह्न आरोन तुरॉन सूचनाएँ @ithub.com ने लिखा:

@SergioBenitez https://github.com/SergioBenitez

कंपाइलर कार्यान्वयन संघर्षों का हवाला देते हुए कंपाइलर के साथ विफल हो जाता है। ध्यान दें
वह और स्ट्रिंग FromStr को लागू नहीं करता है, इसलिए कोई विरोध नहीं होना चाहिए।

समस्या यह है कि संकलक रूढ़िवादी रूप से यह मान रहा है कि str
भविष्य में FromStr को लागू करने के लिए आ सकता है। यह मूर्खतापूर्ण लग सकता है
यह उदाहरण है, लेकिन सामान्य तौर पर, हम हर समय नए इम्प्लांट जोड़ते हैं, और हम चाहते हैं
जब हम उन आकृतियों को जोड़ते हैं तो डाउनस्ट्रीम कोड को टूटने से बचाते हैं।

यह एक रूढ़िवादी विकल्प है, और कुछ ऐसा है जिसे हम आराम करना चाहते हैं
अधिक समय तक। आप यहाँ पृष्ठभूमि प्राप्त कर सकते हैं:

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

• जंग-लंग / rfcs # 1023 https://github.com/rust-lang/rfcs/pull/1023
• जंग-लंग / rfcs # 1053 https://github.com/rust-lang/rfcs/issues/1053
• जंग-लंग / rfcs # 1148 https://github.com/rust-lang/rfcs/pull/1148

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/31844#issuecomment -200093757

@aturon

समस्या यह है कि संकलक रूढ़िवादी रूप से यह मानकर चल रहा है कि भविष्य में FromStr को लागू करने के लिए str आ सकता है। यह इस उदाहरण के लिए मूर्खतापूर्ण लग सकता है, लेकिन सामान्य तौर पर, हम हर समय नए इम्प्लॉइज जोड़ते हैं, और जब हम उन इम्प्लांट्स को जोड़ते हैं तो हम डाउनस्ट्रीम कोड को टूटने से बचाना चाहते हैं।

क्या यह वास्तव में क्या विशेषज्ञता को संबोधित करने की कोशिश नहीं है? विशेषज्ञता के साथ, मैं उम्मीद करूंगा कि भविष्य में FromStr &str का कार्यान्वयन होने पर भी, Simple &str लिए Simple का प्रत्यक्ष कार्यान्वयन लागू हो। पूर्वता लेना होगा।

@SergioBenitez आपको अधिक सामान्य निहितार्थ में default fn डालने की आवश्यकता है। तुम्हारी
उदाहरण विशेष नहीं है।

Tue पर, मार्च 22, 2016, 6:54 PM सर्जियो बेनिटेज़ नोटिफिकेशन @github.com
लिखा था:

@aturon https://github.com/aturon

समस्या यह है कि संकलक रूढ़िवादी रूप से यह मान रहा है कि str
भविष्य में FromStr को लागू करने के लिए आ सकता है। इसके लिए वह मूर्खतापूर्ण लग सकता है
उदाहरण के लिए, लेकिन सामान्य तौर पर, हम हर समय नए इम्प्लांट जोड़ते हैं, और हम चाहते हैं
जब हम उन आकृतियों को जोड़ते हैं तो डाउनस्ट्रीम कोड को टूटने से बचाते हैं।

क्या यह वास्तव में क्या विशेषज्ञता को संबोधित करने की कोशिश नहीं है? साथ में
विशेषज्ञता, मुझे उम्मीद है कि भले ही FromStr का एक कार्यान्वयन
भविष्य के लिए & str को जोड़ा गया, के लिए प्रत्यक्ष कार्यान्वयन
& str के लिए विशेषता पूर्वता ले जाएगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/31844#issuecomment -200097995

मुझे लगता है कि "डिफ़ॉल्ट" विशेषता आइटमों को स्वचालित रूप से default ध्वनियों को भ्रमित करने वाला माना जाता है। आप impl s को आसान बनाने के साथ-साथ Haskell, आदि जैसे गुण के लिए दोनों समरूपता चाहते हैं। इसके अलावा, आप आसानी से grep उनके लिए ऐसा नहीं कर सकते जैसे आप default लिए कर सकते हैं। यह दोनों default कीवर्ड के लिए कठिन नहीं है और एक डिफ़ॉल्ट कार्यान्वयन देता है, लेकिन उन्हें अलग नहीं किया जा सकता है। इसके अलावा, यदि कोई भाषा को स्पष्ट करना चाहता है, तो इन "डिफ़ॉल्ट" विशेषता वस्तुओं का नाम बदलकर "प्रस्तावित प्रस्तावित" आइटम दस्तावेज़ीकरण में रखा जा सकता है।

# 32999 (टिप्पणी) से ध्यान दें: यदि हम जाली नियम के साथ जाते हैं (या नकारात्मक बाधाओं की अनुमति देते हैं), तो किसी चीज़ के आगे विशेषज्ञता को रोकने के लिए "एक मध्यवर्ती विशेषता का उपयोग करें" चाल अब काम नहीं करेगी।

@Stebalien

यह काम क्यों नहीं करेगा? चाल विशेषज्ञता को एक निजी विशेषता तक सीमित करती है। यदि आप इसे एक्सेस नहीं कर सकते हैं, तो आप निजी विशेषता का विशेषज्ञ नहीं बन सकते।

@ arielb1 आह। अच्छी बात। मेरे मामले में, विशेषता निजी नहीं है।

मुझे नहीं लगता कि "बाह्य विशेषज्ञ विशेषज्ञ नहीं कर सकते क्योंकि अनाथ आगे-संगतता + सुसंगतता" तर्क विशेष रूप से दिलचस्प या उपयोगी है। खासकर जब हम अपने विशिष्ट सुसंगत नियमों के लिए प्रतिबद्ध नहीं होते हैं।

क्या एक ओवरराइड default impl का उपयोग करने का एक तरीका है? यदि हां, तो यह परीक्षण के निर्माण में सहायता कर सकता है। अनुबंध और libhoare द्वारा डिजाइन देखें।

टाइप-चेकिंग के दौरान डिफ़ॉल्ट संबद्ध प्रकारों के प्रक्षेपण से संकलन-समय पर प्रकार की असमानता को लागू करने की अनुमति मिलेगी: https://gist.github.com/7c081574958d22f89d434a97b626b1b4

#![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 से बचना चाहिए क्योंकि यह CloudFlare का उपयोग करने के कारण Tor उपयोगकर्ताओं के लिए हल नहीं होता है। GitHub पूर्ण URL के साथ ठीक काम करता है। और play.rust-lang.org टोर पर ठीक काम करता है।

@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

क्या यह specialization समर्थन करता है, और क्या वर्तमान में किसी अन्य प्रकार का कार्यान्वयन है?

@zitsen

इन प्रत्यारोपणों को वर्तमान विशेषज्ञता डिजाइन द्वारा अनुमति नहीं है, क्योंकि T: Foo + Bar या T: Foo + Baz अन्य की तुलना में अधिक विशिष्ट नहीं है। यही है, अगर आपके पास कुछ T: Foo + Bar + Baz , तो यह स्पष्ट नहीं है कि कौन सा "जीत" होना चाहिए।

हमारे पास एक अधिक अभिव्यंजक प्रणाली पर कुछ विचार हैं, जो आपको _also_ को T: Foo + Bar + Baz लिए एक निहितार्थ देने की अनुमति देगा और इस तरह से अस्वीकार कर देगा, लेकिन यह अभी तक पूरी तरह से प्रस्तावित नहीं किया गया है।

यदि ऋणात्मक गुण trait Baz: !Bar कभी भूमि की सीमा बनाते हैं, तो इसका उपयोग विशेषज्ञता के साथ भी किया जा सकता है ताकि यह साबित किया जा सके कि बार को लागू करने वाले प्रकार और बाज को लागू करने वाले प्रकार विशिष्ट और व्यक्तिगत रूप से विशिष्ट हैं।

लगता है @rphmeier का जवाब है कि मैं वास्तव में क्या चाहता हूँ, 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 {
   |> ^

playpen

मेरा मानना ​​है कि उपरोक्त _should_ संकलन, और दो दिलचस्प भिन्नताएं हैं जो वास्तव में काम-के रूप में करते हैं:

1) where T::Mark: Fizz बाउंड को निकालना:

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

playpen

2) एक "विशेषता बाध्य उपनाम" जोड़ना:

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

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

playpen

(जो _doesn't_ काम करता है, तो 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)

जो प्रासंगिक होने के लिए आपके मामले के समान पर्याप्त लगता है।

@ इस उदाहरण उदाहरण विशेषता के लिए सहज परिभाषा के साथ संकलन करने के लिए प्रतीत नहीं होता है: https://play.rust-lang.org/?gist=97ff3c2f7f3e3b50bd3aef000dbfa2ca4a&version=nightly&backtrace=0

विशेषज्ञता कोड इसे स्पष्ट रूप से अस्वीकार कर देता है - # 33481 देखें, जो मैंने शुरू में सोचा था कि एक त्रुटि थी लेकिन एक निदान मुद्दा निकला। मेरे निदानों को सुधारने के लिए मेरे पीआरओं पर किसी का ध्यान नहीं गया और मैंने उन्हें कुछ समय के लिए नवीनतम स्वामी के पास नहीं रखा।

@ Rphmeier RFC पाठ बताता है कि इसे अनुमति दी जानी चाहिए, हालांकि, इसका उदाहरण इससे कॉपी किया गया है।

मेरा कुछ कोड के साथ एक नाटक था जो विशेषज्ञता से लाभान्वित हो सकता था। मुझे दृढ़ता से लगता है कि हमें जाली शासन के लिए जाना चाहिए, बल्कि यह स्वाभाविक लगता है और मुझे जिस लचीलेपन की आवश्यकता थी उसे प्राप्त करने का एकमात्र तरीका (afaict) था।

यदि हम default impl साथ-साथ व्यक्तिगत वस्तुओं पर भी गए, तो क्या हम यह लागू कर सकते हैं कि यदि कोई वस्तु ओवरराइड है तो वे सभी होनी चाहिए? यह हमें अन्य मदों में एक डिफ़ॉल्ट एशोक प्रकार (उदाहरण के लिए) के सटीक प्रकार के आधार पर तर्क करने की अनुमति देगा, जो अभिव्यक्ति में एक उपयोगी बढ़ावा की तरह लगता है।

क्या निम्नलिखित की अनुमति दी जानी चाहिए? मैं एक प्रकार का विशेषज्ञ बनाना चाहता हूं ताकि ArrayVec Copy जब इसका तत्व प्रकार प्रतिलिपि हो, और यह कि इसमें एक विध्वंसक हो। मैं एक आंतरिक क्षेत्र का उपयोग करके इसे पूरा करने की कोशिश कर रहा हूं जिसे विशेषज्ञता द्वारा बदल दिया गया है।

मुझे आशा है कि यह संकलित करेगा, अर्थात यह ArrayVec<A> फ़ील्ड फ़ील्ड्स से A: Copy + Array बाउंड (खेल के मैदान पर संकलित स्निपेट) द्वारा चुनी गई की कॉपी करने योग्यता को घटाता है।

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

कमेंट-आउट जहां क्लॉज़ नहीं चाहता है क्योंकि यह सार्वजनिक इंटरफ़ेस में एक निजी प्रकार Repr को उजागर करता है। (यह वैसे भी ICEs है)।

संपादित करें: मैं भूल गया था कि मैंने पहले ही इस बारे में # 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 लेकिन _not_ 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 वाले डिफ़ॉल्ट समूह के लिए कार्यान्वित किया जाता है। (मुझे यकीन नहीं है कि अगर विशुद्ध रूप से इस आरोप में ऐसा करने का कोई तरीका होगा।)

पुनश्च, आपके संदेशों का जवाब देने में लंबे समय तक देरी के लिए खेद है, जो मुझे _July_ से दिनांक दिखाई देता है।

जबकि ट्राईट ट्रेट की मदद करता है, कोई आरएफसी नहीं है जिसे स्वीकार या कार्यान्वित किया गया है जो इसे किसी भी रूप में विशेषता निकायों के साथ उपयोग करने की अनुमति देता है, इसलिए इस आरएफसी के लिए इसे देखना थोड़ा अजीब लगता है।

मैं default impl फ़ीचर लागू करने में रुचि रखता हूं (जहां सभी आइटम default )।
क्या आप उस पर योगदान स्वीकार करेंगे?

@ वफादारी निश्चित रूप से! मैं काम के रूप में अच्छी तरह से मदद करने में खुशी होगी।

क्या वर्तमान में इस पर कोई निष्कर्ष है कि क्या संबंधित प्रकारों को विशेष योग्य होना चाहिए?

निम्नलिखित मेरे उपयोग-मामले का एक सरलीकरण है, जो विशेष रूप से संबंधित प्रकारों की आवश्यकता को प्रदर्शित करता है।
मेरे पास एक सामान्य डेटा संरचना है, 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::<_>());
    }
}

थैंक्स @ न्यूट्रॉन !
मूल रूप से मैं ast::ItemKind::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

और मुझे कुछ संयोजनों को "निषिद्ध" करने की अनुमति दें, उदाहरण के लिए, ए + सी कभी नहीं होना चाहिए:

नहीं, यह कुछ ऐसा नहीं है जो जाली नियम की अनुमति देगा। यह कुछ आकार या प्रकार में "नकारात्मक तर्क" का अधिक डोमेन होगा।

प्रसंग: मैं विभिन्न प्रकार के आकृतियों (अंक, क्यूब्स, बहुभुज, ...) के लिए एक ApproxEqual (आकृति, आकृति) विशेषता को लागू करते समय यह चाहने में उतर गया कि ये सभी लक्षण कहां हैं। परस्पर विरोधी कार्यान्वयन से बचने के लिए, मुझे इसे अलग-अलग लक्षणों, जैसे, ApproxEqualPoint (प्वाइंट, पॉइंट) में बदलकर इसके आसपास काम करना था।

तो @withoutboats "बहिष्करण समूहों" के विचार को बढ़ावा दे रहा है, जहाँ आप यह घोषणा कर सकते हैं कि लक्षणों का एक निश्चित समूह पारस्परिक रूप से अनन्य है (यानी, आप उनमें से अधिकांश पर लागू कर सकते हैं)। मैं इसे एक एनम की तरह होने के रूप में कल्पना करता हूं (यानी, लक्षण सभी एक साथ घोषित किए जाते हैं)। मुझे इसका विचार पसंद है, विशेष रूप से (मुझे लगता है!) यह नकारात्मक तर्क के कुछ अधिक खतरनाक पहलुओं से बचने में मदद करता है। लेकिन मुझे लगता है कि इस मोर्चे पर अधिक विचार की आवश्यकता है - और यह भी एक अच्छा राइटअप है जो नकारात्मक तर्क के बारे में सोचने के बारे में तैरने वाले सभी "डेटा" को संक्षेप में प्रस्तुत करने की कोशिश करता है। शायद अब है कि मैं (ज्यादातर) मेरे एचटीटी और विशेषज्ञता श्रृंखला को लपेटता हूं मैं उस बारे में सोच सकता हूं ...

@nikomatsakis :

तो @withoutboats "बहिष्करण समूहों" के विचार को बढ़ावा दे रहा है, जहाँ आप यह घोषणा कर सकते हैं कि लक्षणों का एक निश्चित समूह पारस्परिक रूप से अनन्य है (यानी, आप उनमें से अधिकांश पर लागू कर सकते हैं)। मैं इसे एक एनम की तरह होने के रूप में कल्पना करता हूं (यानी, लक्षण सभी एक साथ घोषित किए जाते हैं)। मुझे इसका विचार पसंद है, विशेष रूप से (मुझे लगता है!) यह नकारात्मक तर्क के कुछ अधिक खतरनाक पहलुओं से बचने में मदद करता है। लेकिन मुझे लगता है कि इस मोर्चे पर अधिक विचार की आवश्यकता है - और यह भी एक अच्छा राइटअप है जो नकारात्मक तर्क के बारे में सोचने के बारे में तैरने वाले सभी "डेटा" को संक्षेप में प्रस्तुत करने की कोशिश करता है। शायद अब है कि मैं (ज्यादातर) मेरे एचटीटी और विशेषज्ञता श्रृंखला को लपेटता हूं मैं उस बारे में सोच सकता हूं ...

मैंने इसे लिखते समय बहिष्करण समूहों के बारे में सोचा (आपने दूसरे दिन मंचों में इसका उल्लेख किया), लेकिन मुझे नहीं लगता कि वे इस विशेष उदाहरण में काम कर सकते हैं क्योंकि सभी लक्षण कार्यान्वयन अनन्य नहीं हैं। सबसे तुच्छ उदाहरण Point और Float लक्षण है: Float _can_ एक 1D बिंदु है, इसलिए ApproxEqualPoint(Point, Point) और ApproxEqualFloat(Float, Float) नहीं हो सकता है अनन्य। अन्य उदाहरण हैं जैसे Square और Polygon , या Box | Cube और AABB (अक्ष-संरेखित बाउंडिंग बॉक्स) जहां "विशेषता पदानुक्रम" वास्तव में अधिक जटिल बाधाओं की आवश्यकता होती है।

नहीं, यह कुछ ऐसा नहीं है जो जाली नियम की अनुमति देगा। यह कुछ आकार या प्रकार में "नकारात्मक तर्क" का अधिक डोमेन होगा।

मैं कम से कम किसी विशेष मामले को लागू करने में सक्षम होऊंगा और उसमें unimplemented!() डालूंगा। यह पर्याप्त होगा, लेकिन जाहिर है कि मैं इसे और अधिक पसंद करूंगा यदि संकलक उन मामलों को सांख्यिकीय रूप से पकड़ लेगा, जिसमें मैं unimplemented!() साथ एक फ़ंक्शन को कॉल करता हूं (और इस बिंदु पर, हम फिर से नकारात्मक तर्क भूमि में हैं) ।

@gnzlbg जाली विशेषज्ञता आपको उस निहित आतंक को बनाने की अनुमति देगी, लेकिन ऐसा करने का विचार मुझे बनाता है: रोना:।

"अपवर्जन समूहों" का विचार वास्तव में सिर्फ नकारात्मक सुपरसट्रेट सीमा है। एक चीज जिसे हमने बहुत अच्छी तरह से नहीं समझा है, वह है रिवर्स पोलरिटी स्पेशलाइजेशन की धारणा - आपको एक विशेष इम्प्लांट लिखने की अनुमति देता है जो कि रिवर्स कम पोलरिटी का होता है। उदाहरण के लिए, इस मामले में आप बस लिखेंगे:

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

मुझे पूरी तरह से यकीन नहीं है कि अनुमति देने के निहितार्थ क्या हैं। मुझे लगता है कि यह उन मुद्दों से जुड़ता है जो निको पहले से ही इस बात पर प्रकाश डालते हैं कि विशेषज्ञता किस तरह से पॉलीमोर्फिज़्म के साथ कोड पुन: उपयोग करने के लिए है।

नकारात्मक तर्क और नकारात्मक प्रभाव की इस सभी चर्चा के साथ, मैं फिर से "उदाहरण श्रृंखला" के पुराने हास्केल विचार को लाने के लिए मजबूर महसूस करता हूं ( कागज , कागज , जीएचसी मुद्दा ट्रैकर , रस्ट प्री-आरएफसी ), प्रेरणा के संभावित स्रोत के रूप में अगर कुछ भी नहीं। अन्य।

अनिवार्य रूप से यह विचार है कि कहीं भी आप trait निहितार्थ लिख सकते हैं, आप किसी और संख्या को "और भी लिख सकते हैं यदि एक अलग 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

जब मुझे उनकी आवश्यकता होती है तो मैं incrementally इम्प्लांट जोड़ सकूंगा और जब मुझे कोई टाइप नहीं होता है तो एक टाइप के साथ एक ट्रेट का उपयोग करने की कोशिश करने पर मुझे अच्छे कंपाइलर एरर मिलते हैं।

मुझे पूरी तरह से यकीन नहीं है कि अनुमति देने के निहितार्थ क्या हैं।

निको ने उल्लेख किया कि नकारात्मक तर्क के साथ समस्याएं हैं। एफडब्ल्यूआईडब्ल्यू केवल एक चीज है जिसका उपयोग नकारात्मक तर्क के लिए ऊपर दिए गए उदाहरण में किया गया है, यह बताता है कि उपयोगकर्ता जानता है कि किसी विशेष मामले के लिए एक इम्प्लांट की आवश्यकता है, लेकिन स्पष्ट रूप से इसके लिए एक कार्यान्वयन प्रदान नहीं करने का फैसला किया है।

मैं सिर्फ # 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 और

#![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 दायर किया, जो मैं सर्डे में विशेषज्ञता के निर्माण पर काम करते हुए चला। Https://github.com/rust-lang/rust/issues/38167 के समान, यह एक ऐसा मामला है जहां कार्यक्रम विशेष आरेख के बिना संकलित होता है और जब इसे जोड़ा जाता है तो एक प्रकार की त्रुटि होती है। cc @bluss जो इस स्थिति से पहले चिंतित थे।

क्या होगा यदि हम एक एकल टोकरे के भीतर default कीवर्ड के बिना विशेषज्ञता की अनुमति देते हैं, इसी तरह हम एक एकल टोकरे के भीतर नकारात्मक तर्क की अनुमति कैसे देते हैं?

मेरा मुख्य औचित्य यह है: "पुनरावृत्तियों और वैक्टर पैटर्न।" कभी-कभी, उपयोगकर्ता सभी पुनरावृत्तियों और वैक्टर के लिए कुछ लागू करना चाहते हैं:

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

(यह पुनरावृत्तियों और वैक्टर की तुलना में अन्य स्थितियों के लिए प्रासंगिक है, ज़ाहिर है, यह सिर्फ एक उदाहरण है।)

आज यह संकलन नहीं है, और दांतों का tsuris और gnashing है। विशेषज्ञता इस समस्या को हल करती है:

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

लेकिन इस समस्या को हल करने में, आपने अपने टोकरे में एक सार्वजनिक अनुबंध जोड़ दिया है: Foo होने वाली पुनरावृत्ति को रोकना संभव है। शायद हम आपको ऐसा करने के लिए मजबूर नहीं करना चाहते - इसलिए, default बिना स्थानीय विशेषज्ञता।

मुझे लगता है कि सवाल यह है कि वास्तव में default की भूमिका क्या है। default थी, मुझे लगता है, मूल रूप से एक गवाह है जो गवाह और स्व-दस्तावेजीकरण कोड की ओर इशारा करता है। जिस प्रकार Rust code डिफ़ॉल्ट रूप से अपरिवर्तनीय है, डिफ़ॉल्ट रूप से निजी, डिफ़ॉल्ट रूप से सुरक्षित, यह भी डिफ़ॉल्ट रूप से अंतिम होना चाहिए। हालाँकि, क्योंकि "नॉन-फ़ाइनलिटी" एक वैश्विक संपत्ति है, मैं किसी आइटम को तब तक विशेषज्ञ नहीं बना सकता जब तक कि मैं आपको किसी आइटम का विशेषज्ञ न होने दूं।

default थी, मुझे लगता है, मूल रूप से खोजकर्ता और स्व-दस्तावेजीकरण कोड की ओर इशारा है। हालाँकि [..] मैं किसी वस्तु को तब तक विशेषज्ञ नहीं बना सकता जब तक कि मैं आपको किसी वस्तु का विशेषज्ञ न बनाऊँ।

हालांकि यह वास्तव में इतना बुरा है? यदि आप एक निहित विशेषज्ञ बनाना चाहते हैं तो शायद अन्य लोग भी अस्वस्थ होना चाहते हैं।

मुझे चिंता है क्योंकि इस RFC के बारे में सोचने से मुझे पहले से ही C ++ कोडबेस में काम करने का PTSD फ्लैशबैक दे रहा है जो ओवरलोडिंग और विरासत की अश्लील मात्रा का उपयोग करते हैं और बिना किसी विचार के wtf कोड की किसी भी पंक्ति में चल रहे हैं, जिसमें एक विधि कॉल है। मैं वास्तव में उन लंबाई की सराहना करता हूं जो @aturon विशेषज्ञता और स्पष्ट और स्व-दस्तावेजीकरण बनाने के लिए गए हैं।

हालांकि यह वास्तव में इतना बुरा है? यदि आप एक निहित विशेषज्ञ बनाना चाहते हैं तो शायद अन्य लोग भी अस्वस्थ होना चाहते हैं।

यदि अन्य लोग केवल "शायद" इसे भी विशेषज्ञ बनाना चाहते हैं, और अगर ऐसे अच्छे मामले हैं जहां हम उन्हें नहीं चाहते हैं, तो हमें इसे निर्दिष्ट करना असंभव नहीं होना चाहिए। (इनकैप्सुलेशन के समान एक सा: आप कुछ डेटा एक्सेस करना चाहते हैं और शायद कुछ अन्य लोग भी चाहते हैं - इसलिए आप स्पष्ट रूप से _this data_ public को चिह्नित करते हैं, बजाय सभी डेटा को सार्वजनिक करने के।

मुझे चिंता है क्योंकि इस RFC के बारे में सोचने से पहले ही मुझे PTSD फ्लैशबैक दे रहा है ...

लेकिन इस विनिर्देशन को अस्वीकार करने से इन चीजों को होने से कैसे रोका जा सकता है?

यदि ऐसे अच्छे मामले हैं, जहां हम उन्हें नहीं चाहते हैं, तो हमें इसे निर्दिष्ट करना असंभव नहीं होना चाहिए।

यह जरूरी नहीं है कि जब भी वे इसके लिए एक अच्छा उपयोग कर सकते हैं तो उपयोगकर्ताओं को एक शक्ति देना एक अच्छा विचार है। ऐसा नहीं है कि यह उपयोगकर्ताओं को भ्रमित कोड लिखने में सक्षम बनाता है।

लेकिन इस विनिर्देशन को अस्वीकार करने से इन चीजों को होने से कैसे रोका जा सकता है?

मान लें कि आप foo.bar() और आप bar() क्या देखना चाहते हैं। अभी, यदि आप एक मिलान प्रकार पर लागू विधि पाते हैं और यह default चिह्नित नहीं है, तो आप जानते हैं कि इसकी विधि परिभाषा जिसे आप खोज रहे हैं। @Withoutboats के प्रस्ताव के साथ यह अब सच नहीं होगा - इसके बजाय आपको कभी भी यह पता नहीं चलेगा कि आप वास्तव में उस कोड को देख रहे हैं जिसे निष्पादित किया जा रहा है।

इसके बजाय आप कभी भी यह नहीं जान पाएंगे कि आप वास्तव में उस कोड को देख रहे हैं जिसे निष्पादित किया जा रहा है।

यह स्थानीय प्रकारों के लिए गैर-डिफ़ॉल्ट प्रत्यारोपण की विशेषज्ञता की अनुमति के प्रभाव का काफी अतिशयोक्ति है। यदि आप एक ठोस निहितार्थ देख रहे हैं, तो आप जानते हैं कि आप सही प्रत्यारोपण देख रहे हैं। और आपके पास इस टोकरे के पूरे स्रोत तक पहुंच है; आप यह निर्धारित कर सकते हैं कि यह निहित विशेष है या नहीं की तुलना में बहुत जल्दी "कभी नहीं।"

इस बीच, default , समस्या बनी हुई है जब एक अंजीर को अंतिम रूप नहीं दिया गया है। यदि सही निहितार्थ वास्तव में default निहित है, तो आप अनिश्चित होने की कठिनाई की एक ही स्थिति में हैं यदि यह सही निहित है। और निश्चित रूप से यदि विशेषज्ञता को नियोजित किया जाता है, तो यह आमतौर पर मामला होगा (उदाहरण के लिए, यह आज लगभग ToString प्रत्येक निहितार्थ के लिए मामला है)।

वास्तव में मुझे लगता है कि यह एक गंभीर समस्या है, लेकिन मुझे यकीन नहीं है कि default इसे हल करता है। हमें बेहतर कोड नेविगेशन टूल की आवश्यकता है। वर्तमान में रूडडॉक एक बहुत 'सर्वश्रेष्ठ प्रयास' दृष्टिकोण बनाता है जब यह ट्रेस के निशान की बात आती है - यह उनके स्रोत से लिंक नहीं करता है और यह उन सूचियों को भी सूचीबद्ध नहीं करता है जो कंबल प्रत्यारोपण द्वारा प्रदान की जाती हैं।

मैं यह नहीं कह रहा हूँ कि यह परिवर्तन किसी भी तरह से एक स्लैमडंक है, लेकिन मुझे लगता है कि यह एक अधिक सूक्ष्म विचार के लायक है।

यह जरूरी नहीं है कि जब भी वे इसके लिए एक अच्छा उपयोग कर सकते हैं तो उपयोगकर्ताओं को एक शक्ति देना एक अच्छा विचार है। ऐसा नहीं है कि यह उपयोगकर्ताओं को भ्रमित कोड लिखने में सक्षम बनाता है।

बिल्कुल, मैं बिल्कुल सहमत हूं। मुझे लगता है कि मैं यहां एक अलग "उपयोगकर्ता" के बारे में बात कर रहा हूं, जो आपके द्वारा लिखे गए बक्से का उपयोगकर्ता है। आप नहीं चाहते हैं कि वे आपके टोकरे में स्वतंत्र रूप से विशेषज्ञ हों (संभवतः आपके टोकरे के व्यवहार को हैकी तरीके से प्रभावित कर रहे हैं)। दूसरी ओर, हम अधिक उपयोगकर्ता को "उपयोगकर्ता" के बारे में बता रहे हैं, जिसके बारे में आप टोकरा लेखक कह रहे हैं, लेकिन @withoutboats के प्रस्ताव के बिना भी, आपको "डिफ़ॉल्ट" का उपयोग करना होगा और उसी समस्या में चलना होगा ।

मुझे लगता है कि default इस अर्थ में मदद करता है कि यदि आप किसी कोड को पढ़ने को सरल बनाना चाहते हैं तो आप पूछ सकते हैं कि कोई भी default का उपयोग नहीं करता है या इसका उपयोग करने के लिए कठोर प्रलेखन नियम स्थापित नहीं करता है। उस बिंदु पर, आपको केवल default s से std चिंता करने की आवश्यकता है, जो संभवतः लोगों को बेहतर समझ में आएगा।

मुझे यह विचार याद है कि प्रलेखन नियमों को विशेषज्ञता के usages पर लगाया जा सकता है, जिसे RFC द्वारा अनुमोदित विशेषज्ञता प्राप्त करने में योगदान दिया गया है।

@withoutboats क्या मैं default शिथिलता के लिए आपकी प्रेरणा को पढ़ने में सही हूं क्योंकि आप default का एक प्रतिबंधित रूप चाहते हैं जिसका अर्थ है "अति-योग्य, लेकिन केवल इस टोकरे में" (यानी, pub(crate) लेकिन default )? हालांकि, इसे आसान बनाने के लिए आप को छोड़ते हुए के शब्दों को बदलने का प्रस्ताव कर रहे हैं default , बजाय के graduations जोड़ने default -नेस?

सही बात। default(crate) जैसा कुछ करना ओवरकिल जैसा लगता है।

एक प्राथमिकता, मैं कल्पना कर सकता हूं कि कोई भी इसका अनुकरण कर सकता है कि क्रेट निर्यात के माध्यम से, नहीं? क्या ऐसी कोई स्थितियाँ हैं जहाँ आप default विधियों के साथ एक निजी सहायक विशेषता का परिचय नहीं दे सके और इसे अपने अंतिम impl s से कॉल करें? आप चाहते हैं कि उपयोगकर्ता आपके default s का उपयोग करें लेकिन उनकी स्वयं की आपूर्ति न करें?

सही बात। डिफ़ॉल्ट (टोकरा) की तरह कुछ करना ओवरकिल की तरह लगता है।

मैं असहमत हूं। मैं वास्तव में डिफ़ॉल्ट का प्रतिबंधित रूप चाहता हूं। मुझे इसका प्रस्ताव करने का अर्थ है। मेरा अभिप्राय यह है कि कभी-कभी चौराहे का आशय आदि आपको डिफ़ॉल्ट जोड़ने के लिए मजबूर कर देगा, लेकिन इसका मतलब यह नहीं है कि आप अपने व्यवहार को बदलने के लिए मनमाने बक्से के लिए अनुमति देना चाहते हैं। क्षमा करें, एक बैठक है, मैं एक उदाहरण के साथ थोड़ा विस्तार से बताने का प्रयास कर सकता हूं।

@nikomatsakis मेरे पास एक ही प्रेरणा है, जो मैं प्रस्ताव कर रहा हूं वह यह है कि हम केवल एक ही टोकरे में विशेषज्ञ के लिए डिफ़ॉल्ट आवश्यकता को हटा दें, क्योंकि अधिक लीवर को जोड़ने के लिए। :-)

संयोग से इस गैर निर्यात डिफ़ॉल्ट अधिक आम उपयोग है, तो हो सकता है एक #[default_export] सुविधा के साथ तुलना करके याद करने के लिए आसान होगा #[macro_export] । एक मध्यवर्ती विकल्प pub use या pub mod लाइनों के लिए इस निर्यात सुविधा की अनुमति दे सकता है।

pub कीवर्ड का उपयोग करना बेहतर होगा, क्योंकि मैक्रोज़ 2.0 सामान्य वस्तुओं के रूप में मैक्रोज़ का समर्थन करेगा और pub बजाय #[macro_use] । बोर्ड भर में दृश्यता को इंगित करने के लिए pub का उपयोग करना इसकी स्थिरता के लिए एक बड़ी जीत होगी।

@withoutboats की परवाह किए बिना, मुझे लगता है कि कभी-कभी आप स्थानीय स्तर पर विशेषज्ञ बनाना चाहते हैं, लेकिन जरूरी नहीं कि सभी के लिए दरवाजे खुले हों

पब कीवर्ड का उपयोग करना बेहतर होगा

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 ness का निर्यात करना या नहीं करना आम बात है? default नेस डिफ़ॉल्ट व्यवहार नहीं होना चाहिए?

हाँ मामला: आप निर्यात के साथ समानता को कहीं और बढ़ा सकते हैं जैसे pub mod mymodule default; और pub use mymodule::MyTrait default; , या शायद overridable । यदि आवश्यक हो, तो आप pub use MyModule::MyTrait::{methoda,methodb} default; साथ केवल कुछ तरीकों के लिए default नेस निर्यात कर सकते हैं

कोई मामला नहीं: आपको निजीता व्यक्त करने की आवश्यकता है, न कि प्रचार की, जो रस्ट वैसे भी किसी भी चीज़ से काफी भिन्न है, इसलिए अब 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 };
}

हमने आज कुछ संभावित खोजों को परेशान कर दिया है, आप यहाँ आईआरसी लॉग पढ़ सकते हैं: https://botbot.me/mozilla/rust-lang/

मैं सभी निष्कर्षों के बारे में 100% आश्वस्त नहीं हूं, विशेषकर निको की टिप्पणी के बाद, विशेष रूप से निको की टिप्पणी के बाद से हम सभी निष्कर्षों पर पहुंच गए हैं। थोड़ी देर के लिए यह मेरे लिए थोड़ा सर्वनाश करने वाला लग रहा था।

एक बात जो मुझे पूरी तरह से महसूस होती है, वह यह है कि default आवश्यकता को इस गारंटी के साथ संगत नहीं किया जा सकता है कि नए default इंपोज़ हमेशा पिछड़े संगत होते हैं। यहाँ प्रदर्शन है:

टोकरा 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 निहितार्थ 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 { }

यह इम्पैक्ट जोड़ दिया गया है, और यह पूरी तरह से एक विशिष्ट इम्पैक्ट है, इसलिए हमने कहा है कि यह एक न टूटने वाला बदलाव है। हालाँकि , यह एक सकर्मक निहितार्थ पैदा करता है - हमारे पास पहले से ही "सभी ए निहित बी (विशेषनीय नहीं)" था, "सभी ए बी बी (विशेष)" को जोड़कर, हमने स्पष्ट रूप से बयान "सभी ए निहित सी" (विशेष नहीं) जोड़ा है। "। अब बच्चा टोकरा अपग्रेड नहीं कर सकता है।

यह मामला हो सकता है कि गारंटी देने का विचार है कि विशेष योग्य जोड़ जोड़ने से कोई परिवर्तन नहीं होता है पूरी तरह से खिड़की से बाहर है, क्योंकि आरोन ने दिखाया (जैसा कि आप ऊपर दिए गए लॉग में देख सकते हैं) कि आप ऐसे अनुमान लिख सकते हैं जो डिफ़ॉल्टता के बारे में समान गारंटी देते हैं । हालांकि, निको की बाद की टिप्पणियां बताती हैं कि अनाथ नियमों के तहत इस तरह के आरोपों को प्रतिबंधित (या कम से कम निषेधात्मक) किया जा सकता है।

मेरे लिए अपने अनिश्चित तो 'impls गैर तोड़ने' अगर गारंटी salvageable है, लेकिन यह निश्चित है कि यह 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 बाउंड के साथ एक प्रकार का पैरामीटर होता है, जहां विशेष संस्करण में B (जिसमें A आवश्यकता होती है) पर बाउंड होता है।

@torkleyy वर्तमान में नहीं है, लेकिन आप इसे गुप्त रूप से एक विशेषता बनाकर कर सकते हैं, जो T: Read और T: BufRead और आपके कोड के उन हिस्सों को शामिल करता है जिन्हें आप उस विशेषता के निहितार्थ में विशेषज्ञ बनाना चाहते हैं। इसे सार्वजनिक API में दिखाई देने की भी आवश्यकता नहीं है।

बैकवर्ड संगतता समस्या के बारे में, मुझे लगता है कि अनाथ नियमों के लिए हम इन नियमों से दूर हो सकते हैं:

_An जोड़ जब तक पीछे जोड़ने के लिए संगत है: _

• _ यह लक्षण निहित है एक ऑटो विशेषता है ।_
• _ रिसीवर एक प्रकार का पैरामीटर है, और निहित में प्रत्येक गुण पहले से मौजूद है ।_

यही है, मुझे लगता है कि सभी समस्याग्रस्त उदाहरणों में जोड़ा गया एक कंबल निहित है। हम यह कहना चाहते थे कि पूरी तरह से डिफ़ॉल्ट कंबल प्रत्यारोपण भी ठीक है, लेकिन मुझे लगता है कि हमें सिर्फ यह कहना है कि मौजूदा कंबल प्रत्यारोपणों को जोड़ना एक परिवर्तन हो सकता है।

सवाल यह है कि हम उस के सामने क्या गारंटी देना चाहते हैं - उदाहरण के लिए, मुझे लगता है कि यह एक बहुत अच्छी संपत्ति होगी यदि कम से कम एक कंबल केवल आपके टोकरे में कोड के आधार पर एक ब्रेकिंग परिवर्तन हो सकता है, तो आप समीक्षा कर सकते हैं आपके टोकरे और निश्चितता के साथ जानते हैं कि आपको प्रमुख संस्करण को बढ़ाने की आवश्यकता है या नहीं।

@withoutboats

बैकवर्ड संगतता समस्या के बारे में, मुझे लगता है कि अनाथ नियमों के लिए हम इन नियमों से दूर हो सकते हैं:

_An जोड़ जब तक पीछे जोड़ने के लिए संगत है: _

• _ यह लक्षण निहित है एक ऑटो विशेषता है ।_
• _ रिसीवर एक प्रकार का पैरामीटर है, और निहित में प्रत्येक गुण पहले से मौजूद है ।_

यही है, मुझे लगता है कि सभी समस्याग्रस्त उदाहरणों में जोड़ा गया एक कंबल निहित है। हम यह कहना चाहते थे कि पूरी तरह से डिफ़ॉल्ट कंबल प्रत्यारोपण भी ठीक है, लेकिन मुझे लगता है कि हमें सिर्फ यह कहना है कि मौजूदा कंबल प्रत्यारोपणों को जोड़ना एक परिवर्तन हो सकता है।

एक हफ्ते और कई चर्चाओं के बाद, यह दुर्भाग्य से मामला नहीं निकला है।

हमारे पास जो परिणाम हैं वे हैं: 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 आह, मैं, के रूप में या के बजाय और अपने दो बुलेट सूची समझा जो ऐसा लगता है कि तुम क्या मतलब है?

@ यूट्रॉन ये, मेरा मतलब था 'या' - वे दो मामले हैं जहां यह एक परिवर्तन है। कोई भी ऑटो निशान, चाहे कितना भी ठोस क्यों न हो, एक ब्रेकिंग चेंज है, क्योंकि जिस तरह से हम उनके बारे में नकारात्मक तर्क देते हैं, उसे प्रचारित करने की अनुमति है: https://is.gd/k4Xtlp

यही है, जब तक कि इसमें नए नाम न हों। AFAIK एक नया नाम है कि एक निहित है कभी नहीं तोड़ रहा है।

@withoutboats मुझे आश्चर्य होता है कि अगर हम ऑटो-लक्षण के आसपास नकारात्मक तर्क पर भरोसा करने वाले लोगों को रोक सकते हैं / चाहिए। यही है, अगर हमने कहा कि ऑटो ट्रैक्ट्स के नए इम्प्लिट्स को जोड़ना एक कानूनी रूप से टूटने वाला बदलाव है, तो हम फिर से उन इम्प्लांट्स के बारे में आगाह कर सकते हैं, जिन्हें अपस्ट्रीम क्रेट द्वारा Send जोड़ा जा सकता है। यह सबसे अच्छा काम करेगा अगर हमारे पास:

1. स्थिर विशेषज्ञता, एक रणनीतिक स्थानों में default जोड़कर चेतावनियों को पार कर सकता है (बहुत समय);
2. कुछ प्रकार के स्पष्ट नकारात्मक निहितार्थ, इसलिए कि Rc जैसे प्रकार कभी भी Send लिए उनके इरादे की घोषणा नहीं कर सकते हैं - लेकिन फिर हमारे पास ऑटो लक्षणों के लिए है, इसलिए हम उन्हें ध्यान में रख सकते हैं।

मुझे नहीं पता कि मुझे लगता है कि यह इस बात पर निर्भर करता है कि मजबूत प्रेरणा है या नहीं। ऐसा लगता है कि विशेष रूप से संभावना नहीं है कि आप महसूस करेंगे कि आपके द्वारा पहले ही जारी किए जाने के बाद एक प्रकार का unsafe impl Send/Sync हो सकता है; मुझे लगता है कि अधिकांश समय सुरक्षित होगा, आपने एक प्रकार से लिखा है कि यह पहले से ही सुरक्षित होगा (क्योंकि यह प्रकार का बिंदु है)।

मैं हर समय तथ्य के बाद unsafe impl Send/Sync जोड़ता हूं। कभी-कभी क्योंकि मैं इसे सुरक्षित बनाता हूं, कभी-कभी क्योंकि मुझे एहसास होता है कि जिस सी एपीआई के साथ मैं अंतर कर रहा हूं वह थ्रेड्स में साझा करने के लिए ठीक है, और कभी-कभी यह सिर्फ इसलिए है कि क्या कुछ Send / Sync isn होना चाहिए जब मैं एक प्रकार का परिचय देता हूं, तो मैं क्या सोच रहा हूं।

मैं सी एपीआई को बांधते समय इस तथ्य के बाद भी उन्हें जोड़ता हूं - अक्सर क्योंकि कोई स्पष्ट रूप से उन सीमाओं के लिए पूछता है इसलिए मैं फिर से गुजरता हूं और जांचता हूं कि अंतर्निहित लाइब्रेरी क्या गारंटी देता है।

एक बात मुझे पसंद नहीं है कि कैसे संबंधित लक्षण अभी काम करते हैं, यह पैटर्न काम नहीं करता है:

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 में लक्षण इस तरह के पैटर्न के लिए बहुत सारी इच्छाएं जारी करेंगे, लेकिन मुझे आश्चर्य है कि अगर कोई बेहतर समाधान नहीं है जहां जेनेरिक निहित मान्य है, लेकिन यह विशेषज्ञता काम नहीं करती है क्योंकि यह एक प्रकार की त्रुटि का परिचय देता है ?

@withoutboats हाँ, यह डिज़ाइन के बारे में मुख्य अनसुलझे प्रश्नों में से एक है (जो मैं हालिया चर्चाओं में लाना भूल गया हूँ)। मूल RFC थ्रेड पर इस बारे में उचित चर्चा हुई है, लेकिन मैं जल्द ही विकल्पों / ट्रेडऑफ का सारांश लिखने का प्रयास करूंगा।

@aturon वर्तमान समाधान सबसे रूढ़िवादी है (हम जो भी करना चाहते हैं उसके साथ संगत है) या यह एक ऐसा निर्णय है जिसे हमें स्थिर करने से पहले करना होगा?

मैं व्यक्तिगत रूप से इस समस्या का एकमात्र वास्तविक समाधान समझता हूं कि @withoutboats ने आइटम को "समूहीकृत" करने की अनुमति तब दी जब आप 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 जिस तरह से आपने इस कोड को लिखा है वह भ्रमित करने वाला है। मुझे लगता है कि BufRead को बफ़र के रिटर्न प्रकार के रूप में उपयोग करने के स्थान पर, आपका मतलब है :: :: BufReader, सही है?

हां, मैंने ट्रैप आधारित एक के समाधान को संशोधित किया था और फिर वापस स्विच कर दिया था, लेकिन रिटर्न टाइप को विशेषता में याद किया।

हो सकता है कि इस भाषा की प्रकार प्रणाली की तरह कुछ भी दिलचस्प हो सकता है, क्योंकि यह रुस्ट्स के समान लगता है, लेकिन कुछ विशेषताओं के साथ, जो वर्तमान समस्याओं को हल कर सकते हैं।
( 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 विशेष है, या हो सकता है क्योंकि Display tuples के लिए लागू नहीं हुआ है जबकि 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 () जोड़ सकता है, और हम नहीं चाहते कि यह एक ब्रेकिंग परिवर्तन हो। हम चाहते हैं कि पुस्तकालयों को उन प्रकार के बदलाव करने की स्वतंत्रता हो। इसलिए भले ही () प्रदर्शन नहीं होता है, हम ओवरलैप चेक में उस जानकारी का उपयोग नहीं कर सकते हैं।

लेकिन यह भी, क्योंकि () प्रदर्शन नहीं है, यह T: Display से अधिक विशिष्ट नहीं है। यही कारण है कि विशेषज्ञता काम नहीं करती है, जबकि डिफ़ॉल्ट मामले में, (): Default , इसलिए यह निहित है कि T: Default से अधिक विशिष्ट है।

इस तरह के इंप्लांट 'लिम्बो' में एक तरह के होते हैं, जहां हम न तो यह मान सकते हैं कि यह ओवरलैप होता है और न ही होता है। हम इस काम को करने के लिए एक राजसी तरीके का पता लगाने की कोशिश कर रहे हैं, लेकिन यह विशेषज्ञता का पहला कार्यान्वयन नहीं है, यह बाद में आने वाली उस सुविधा के लिए एक पश्चगामी संगत विस्तार है।

मैंने आजीवन संबंधित ध्वनि मुद्दे को ट्रैक करने के लिए # 40582 दर्ज किया।

मेरे पास एक मुद्दा था जो विशेषज्ञता का उपयोग करने की कोशिश कर रहा था, मुझे नहीं लगता कि यह वैसा ही है जैसा @antoyo के पास था, मैंने इसे एक अलग मुद्दे # 41140 के रूप में दर्ज किया था, मैं उदाहरण कोड यहां से ला सकता हूं यदि आवश्यक हो

@ afonso360 नहीं, एक अलग मुद्दा ठीक है।

एक सामान्य बिंदु के रूप में: इस बिंदु पर विशेषज्ञता पर आगे का काम चाक पर काम पर अवरुद्ध है, जिससे हमें ध्वनि मुद्दों से निपटने की अनुमति मिलनी चाहिए और आज आईसीई के हिट होने की भी संभावना है।

क्या कोई स्पष्ट कर सकता है कि क्या यह बग है, या ऐसा कुछ है जो जानबूझकर निषिद्ध है? https://is.gd/pBvefi

@sgrif मेरा मानना ​​है कि यहां मुद्दा सिर्फ यह है कि डिफ़ॉल्ट से जुड़े प्रकारों का प्रक्षेपण अस्वीकृत है। हालांकि निदान बेहतर हो सकता है: https://github.com/rust-lang/rust/issues/33481

क्या आप इस बारे में विस्तार से बता सकते हैं कि इसे क्यों अस्वीकृत किया जा सकता है? हम जानते हैं कि कोई भी अधिक विशिष्ट प्रत्यारोपण नहीं जोड़ा जा सकता है, क्योंकि यह अनाथ नियमों का उल्लंघन करेगा।

इस टिप्पणी से संकेत मिलता है कि कुछ मामलों के लिए ध्वनि की आवश्यकता होती है (हालांकि मुझे पता नहीं क्यों) और दूसरों में इंटरफ़ेस के उपभोक्ताओं को इसे एक अमूर्त प्रकार के रूप में व्यवहार करने के लिए मजबूर करने के लिए: https://github.com/rust- लैंग / जंग / ब्लॉब / e5e664f / src / librustc / लक्षण / 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 में समझाया है @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> भविष्य में जोड़ा गया था, तब भी मैं रूस्ट से गैर- 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))
    }
}

यदि 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 -249355357 और स्वतंत्र रूप से मेरे द्वारा। मैं उस प्रस्ताव पर बाद में एक 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`

@ ग्लैंडियम पृथ्वी पर क्या चल रहा है? अच्छा उदाहरण, यहाँ खेल का मैदान लिंक: https://play.rust-lang.org/?gist=fc7cf5145222c432e2bd8de1b0a425cd&version=nightly&mode-debug

@glandium जो कि https://github.com/rust-lang/rust/issues/48444 है

क्या यह? मेरे उदाहरण में कोई खाली निहितार्थ नहीं है।

@glandium

 impl B for Foo {}

@MoSal लेकिन यह 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

क्या विशेषज्ञता भविष्य के संभावित संघर्षों को रोक नहीं पाएगी?

मुझे अच्छाई दें, यह एक धीमी गति से चलने वाली विशेषता है! दो वर्षों में कोई प्रगति नहीं हुई, ऐसा लगता है (निश्चित रूप से मूल पद के अनुसार)। क्या लंग टीम ने इसे छोड़ दिया है?

@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 आपका usecase काम कर रहा है यदि आप 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/ देखें

मेरा अनुमान है कि अभी सभी का ध्यान संस्करण पर केंद्रित है ...

ठीक है धन्यवाद ... ऐसा लगता है कि यह मुद्दा हमेशा के लिए खींच रहा है, लेकिन पर्याप्त रूप से उचित है। यह कठिन है, मुझे पता है। और दुर्भाग्य से अभी कहीं और ध्यान दिया गया है।

क्या पूरी तरह से मोनोमोर्फिक मामलों में डिफ़ॉल्ट संबद्ध प्रकारों के लिए अनुमानों की अनुमति नहीं देने के पीछे कोई और अधिक तर्क कर सकता है? मेरे पास एक उपयोग का मामला है जहां मैं उस कार्यक्षमता को पसंद करूंगा (विशेष रूप से, यह कभी-कभी उन प्रकारों के साथ आह्वान करने के लिए शब्दार्थ के लिए गलत होगा जो पूरी तरह से मोनोमोर्फिक नहीं थे), और अगर कोई ध्वनि समस्या नहीं है, तो मुझे पूरी तरह से समझ नहीं आता कि क्यों यह अस्वीकृत है।

@pythonesque https://github.com/rust-lang/rust/pull/42411 पर कुछ चर्चा हुई है

आह, मुझे समझ में आया कि क्या यह पता चलता है कि प्रक्षेपण सामान्य रूप से विशेषज्ञता के साथ बुरी तरह से बातचीत करता है

दुर्भाग्य से, मुझे यकीन नहीं है कि अगर वास्तव में कोई ऐसा करने का कोई तरीका है जो मैं इस तरह की सुविधा के बिना चाहता हूं: मैं एक संबद्ध प्रकार है जो "ट्रू" आउटपुट करता है जब दो पास-इन प्रकार एक विशेष गुण को लागू करने के लिए वाक्यविन्यास समान होते हैं; और "झूठे" जब वे नहीं होते हैं ("झूठे" मामले में एक और अधिक महंगी विशेषता खोज को ट्रिगर किया जाता है जो यह तय कर सकता है कि क्या वे "शब्दार्थ" समान हैं)। केवल वास्तविक विकल्प लगता है (मेरे लिए) सिर्फ महंगी खोज करने के लिए होना; जो सिद्धांत में ठीक है, लेकिन यह बहुत अधिक महंगा हो सकता है।

(यदि इस विशेषता को चारों ओर से बंद किया जा सकता है, तो मैं मुख्य स्थिति में निर्माणकर्ताओं के हर संभावित जोड़े की गणना करके और उनका आउटपुट ट्रू या गलत होने पर काम कर सकता हूं; लेकिन इसका उद्देश्य रिपॉजिटरी के बाहर विस्तार के लिए खुला होना है, ताकि; संभवत: काम नहीं करते हैं, खासकर जब से दो अलग-अलग उपयोगकर्ता रिपॉजिटरी में कार्यान्वयन जरूरी एक दूसरे के बारे में नहीं जानते हैं)।

वैसे भी, शायद यह सिर्फ एक संकेत है कि मैं जो करना चाहता हूं वह विशेषता प्रणाली के लिए एक खराब फिट है और मुझे कुछ अन्य तंत्र पर स्विच करना चाहिए, जैसे मैक्रोज़: पी

और यह वास्तव में सच है कि जो मैं चाहता हूं वह "नकारात्मक तर्क" स्वाद का है (हालांकि बंद लक्षण वास्तव में पर्याप्त नहीं होंगे)।

नकारात्मक तर्क के लिए एक वैकल्पिक आवश्यकता होती है जो किसी प्रकार के औजार लक्षण के एक बंद सेट का केवल एक ही विशेषता, ऐसी है कि सेट के अन्य अन्य लक्षण के साथ कार्यान्वयन कर सकते हैं ओवरलैप नहीं (जैसे T औजार से एक { Float | Int | Bool | Ptr } )।

यहां तक ​​कि अगर वहाँ एक तरीका है कि जंग में लागू करने के लिए (जो वहाँ नहीं है, 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 () {}

क्या यह एक तर्क है या यह एक बग है?

@ श्रीमान अशोक सिर्फ सामान्य अनाथ नियम नहीं है? पहले मामले में, कोई डाउनस्ट्रीम टोकरा impl Bar for () नहीं हो सकता था impl Bar<CustomType> for () जो आपके डिफ़ॉल्ट निहितार्थ के साथ संघर्ष करेगा।

@Boscop उस परिदृश्य में, डिफ़ॉल्ट रूप से किसी भी तरह से गैर-डिफ़ॉल्ट द्वारा नीचे ओवरराइड किया जाना चाहिए। उदाहरण के लिए, यदि मेरे पास: impl Bar<bool> for () {} अन्य निहितार्थों से पहले जोड़ा गया है, तो मैं इसे काम करने की उम्मीद करूंगा (आरएफसी / अपेक्षा के अनुसार)। क्या यह सही नहीं है?

आपके द्वारा बताए गए काउंटर-उदाहरण की रेखाओं के साथ गहरी खुदाई करते हुए, मुझे एहसास होता है (या विश्वास) कि उदाहरण "हमेशा-लागू" परीक्षण को संतुष्ट करता है, और इस पर काम किया जा सकता है।

यह समस्या संभवतः # 45814 पर निर्भर करती है।

क्या विशेषज्ञता में मौजूद नहीं हैं डिफ़ॉल्ट पर विशेषता सीमा का समर्थन करने की कोई योजना है?

एक उदाहरण के लिए जिसके लिए यह बहुत उपयोगी होगा, जैसे कि आप आसानी से कार्यक्षमता के लिए एक सामान्य संरचना के साथ एक सामान्य संरचना बनाकर विभिन्न प्रकारों से निपटने की रचना कर सकते हैं जिसे साझा नहीं किया जाना चाहिए।

#![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);
}

इसके अलावा, ऊपर के उदाहरण में, कुछ अजीब जो मैंने अनुभव किया है - डिफ़ॉल्ट हैंडलर इम्प्लांट (और स्वयं भी ।.0 mhandle (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 के लिए कार्यान्वयन को हटाते हैं, तो यह अन्य विशेषता कटौती को तोड़ता है") कि ग्लैडी ने एक पोस्ट का

जंग के साथ 1.35.0-रात (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

ध्यान दें कि यदि आप टोकरा bar बदलते हैं

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

फिर foo संकलन करें।

@ bjorn3 ऐसा लगता है कि हमें इसे ( खेल के मैदान ) विशेषीकृत करने के लिए default विधि की आवश्यकता नहीं है।

@ कृष्णनासी I आपके उदाहरण ( खेल के मैदान ) में "परस्पर विरोधी कार्यान्वयन" त्रुटि को पुन: उत्पन्न नहीं कर सकता है।

अपडेट: ओह, मैं देख रहा हूं। लक्षण 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 वास्तव में _not_ का अर्थ है कि impl ब्लॉक में सभी आइटम default ed हैं। मुझे लगता है कि कम से कम कहने के लिए उन शब्दार्थों को आश्चर्य होता है।

खेल का मैदान लिंक

@ HadrienG2 मैंने वास्तव में इस परियोजना में हमेशा default fn किया है लेकिन इस बार मैं default कीवर्ड भूल गया और संकलक ने इसे impl जोड़ने का सुझाव दिया। पहले स्टैक पुनरावृत्ति मुद्दा नहीं देखा था और अगर यह इस स्तर पर उम्मीद थी यकीन नहीं था। सुझाव के लिए धन्यवाद, default fn ठीक काम करता है।

मूल आरएफसी को देखते हुए, अंतर्निहित प्रत्यारोपण की विशेषज्ञता के बारे में एक खंड है। क्या किसी ने दिया कि मैं कोशिश करूं?

RFC में प्रस्तावित दृष्टिकोण सीधे काम नहीं कर सकता है, कम से कम, निहित कास्ट तरीकों के लिए:

// 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 विधि को एक विशेषता में उठाने का प्रस्ताव करता है, जो कि प्रकार के लिए कार्यान्वित करता है, और इम्प्लिट करता है। मुझे लगता है कि कास्ट एफएन तरीकों के लिए, प्रकार के लिए निशान के उन लोगों को कॉन्स्ट इम्प्लांट होने की आवश्यकता होगी।

इस स्थिति में आने वाले सभी लोगों के लिए और इस स्थिति के बारे में जानने के लिए उत्सुक थे - 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 ने लिखा है (एक उदाहरण के रूप में, एक और संदर्भ में; बोल्ड माइन):

एक महत्वपूर्ण मुद्दा था [विशेषज्ञता में] जिसे कभी संतोषजनक ढंग से हल नहीं किया गया था, जीवनकाल और लक्षणों के चारों ओर एक तकनीकी ध्वनि चिंता [...] फिर, [ऊपर जो दो पोस्ट जुड़े हुए हैं]। ऐसा लगता है कि इन विचारों ने मूल रूप से समस्या को हल कर दिया है , लेकिन हम इस बीच व्यस्त हैं और उनके पास पालन करने का समय नहीं है।

उम्मीद है कि हालांकि स्पष्ट रूप से अभी भी काम करना है।

(इसे पोस्ट करना क्योंकि मुझे यह धागा कुछ हफ्ते पहले मिला था और पिछले साल की प्रगति का कोई अंदाजा नहीं था, फिर हाल ही में दुर्घटना के बाद उन पोस्ट्स में आया। इनका उल्लेख करने के ऊपर टिप्पणियां हैं, लेकिन गीथहब किसी भी लेकिन पहले को देखने के लिए तेजी से कठिन बनाता है। लंबे धागे पर अंतिम कुछ टिप्पणियां: रोना: यह मददगार हो सकता है यदि इस अद्यतन ने इसे मुद्दे के विवरण में शामिल किया हो।)

सभी को नमस्कार! क्या कोई मुझे बता सकता है कि यह उपयोग मामला काम क्यों नहीं करता है? कीड़े या अपेक्षित व्यवहार?

इस उदाहरण के रूप में। impl A for i32 ठीक है, लेकिन impl A for () को 1.39.0-रात में संकलित नहीं किया जा सकता है।

#![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 लगाएं।

@ कृष्णस्नानसी उदाहरण २

@zserik हाँ, मुझे पता है। मुझे नहीं लगता कि इसे अभी तक लागू किया गया है, या इसे हटा दिया गया है। किसी भी मामले में यह अब काम नहीं करता है।

यह स्पष्ट रूप से अब काम नहीं करता है, लेकिन मुझे लगता है कि यह काम करना चाहिए।

मैं यहाँ यह पूछ रहा हूँ, क्योंकि मैंने इस विषय पर कहीं और ध्यान नहीं दिया है - क्या कोई default विभिन्न मानक पुस्तकालय कार्यों को लागू करने की कोई योजना है, इसी तरह से हमने const कैसे किया है From और Into कार्यान्वयन ( impl<T, U: From<T>> Into<U> for T और impl<T> From<T> for T ) के लिए व्यापक सामान्य From लिखना मुश्किल है Into core से डाउनस्ट्रीम कार्यान्वयन, और यह अच्छा होगा यदि मैं अपने स्वयं के बक्से में उन रूपांतरणों को ओवरराइड कर सकता हूं।

अगर हम From / Into लिए विशेषज्ञता की अनुमति देते हैं, तो भी यह जाली समस्या के कारण सामान्य अनुमानों में मदद नहीं करेगा।

@ कृष्णनासी मुझे विश्वास नहीं है कि मामला है। उदाहरण के लिए, यह कोड काम करना चाहिए अगर 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=dugugeded= 2018 और सार = cc126b016ff62643946aebc6bab88c98

@ ठीक है, यदि आप डिफ़ॉल्ट

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

मैं दोहराऊंगा, मानक लाइब्रेरी में डिफ़ॉल्ट रूप से निहित होने के लिए Into From/Into निहितार्थ Into संभव के लिए सामान्य प्रत्यारोपण नहीं करेगा। (और यह From सामान्य प्रभाव को प्रभावित नहीं करता है)

नमस्ते, वर्तमान विशेषज्ञता कार्यान्वयन में एक गंभीर बग है। मैं इसे एक बग के रूप में लेबल करता हूं, भले ही वह एक स्पष्ट डिजाइन निर्णय था, यह हमें सबसे शक्तिशाली विशेषज्ञता सुविधाओं में से एक का उपयोग करने से रोकता है, अर्थात् "अपारदर्शी प्रकार" (यह एक औपचारिक नाम नहीं है) के निर्माण की संभावना। यह पैटर्न अन्य भाषाओं में सबसे प्राइमरी बिल्डिंग ब्लॉकों में से एक है, जो कि हॉस्कल या स्काला जैसी प्रकार की कक्षाएं प्रदान करता है।

यह पैटर्न सरल है - हम 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<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 कोड 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>> ।

इसलिए प्रत्यारोपण की जोड़ी आरएफसी से निम्नलिखित खंड

विशेषज्ञता सुनिश्चित करने के लिए सुसंगत है, हम सुनिश्चित करेंगे कि किसी भी दो के लिए I और J कि ओवरलैप हो, हमारे पास I < J या J < I । यही है, एक दूसरे से वास्तव में अधिक विशिष्ट होना चाहिए।

और यह आपके मामले में भी एक वास्तविक समस्या है क्योंकि HasLabel WithLabel<WithLabel<A>> का निहितार्थ दो तरीकों से व्याख्या किया जा सकता है।

हम इस मामले को कैसे कवर कर सकते हैं यह आरएफसी में पहले से ही

जाली नियम पते की सीमाएं विशेषज्ञता के मुख्य लक्ष्यों के अनुसार काफी हद तक गौण हैं (जैसा कि प्रेरणा में निर्धारित किया गया है), और इसलिए, चूंकि जाली नियम को बाद में जोड़ा जा सकता है, RFC अभी के लिए सरल श्रृंखला नियम से चिपक जाता है।

@qnighy , इसके बारे में सोचने के लिए धन्यवाद।

और यह आपके मामले में एक वास्तविक समस्या भी है क्योंकि WithLabel<WithLabel<A>> के हसलाबेल की व्याख्या दो तरीकों से की जा सकती है।

यह सच है कि अगर हम पर विचार नहीं करते impl<T> HasLabel for WithLabel<T> की तुलना में अधिक विशेष रूप impl<T> HasLabel for T के इनपुट के लिए WithLabel<WithLabel<A>> । आपके द्वारा चिपकाए गए आरएफसी का हिस्सा वास्तव में कवर करता है, हालांकि, मेरा मानना ​​है कि यह एक गंभीर सीमा है और मैं इस एक्सटेंशन के पहले रिलीज में इस उपयोग के मामले में फिर से समर्थन के लिए विचार करूंगा।

इस बीच, मैं 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) वे एक संरचना में सभी क्षेत्रों का प्रचार करते हैं:

मानक लाइब्रेरी में सेंड या सिंक जैसे ऑटो लक्षण, मार्कर लक्षण हैं जो स्वचालित रूप से हर प्रकार के लिए लागू किए जाते हैं, जब तक कि यह प्रकार, या एक प्रकार जिसमें यह शामिल नहीं है, ने स्पष्ट रूप से एक नकारात्मक निहितार्थ के माध्यम से चुना है।

संपादित करें
@qnighy किसी तरह मैंने अनदेखी की कि आपने खेल के मैदान के लिए एक लिंक प्रदान किया है। Much इसके लिए बहुत बहुत धन्यवाद। यह काम करता है और मैं इस बात से चकित हूं कि यह समाधान कितना आसान है। कमाल है कि हम वर्तमान में व्यक्त करने में सक्षम हैं और मुझे उम्मीद है कि भविष्य में यह संभावना गायब नहीं होगी!

ऐसी स्थिति में, 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 अलग तरीके से व्यवहार करते हैं, बस खुद को आश्वस्त करने के लिए।

शायद आप कह रहे हैं कि दो संस्करण समान हैं, केवल एक को छोड़कर और तेजी से होना चाहिए, और इसलिए आप सुनिश्चित नहीं हैं कि आपको किस संस्करण का परीक्षण करना है? उस मामले में, मैं सहमत हूं, मुझे नहीं पता कि आप उस समय कैसे परीक्षण कर सकते हैं।

आप मैक्रो का उपयोग करके परीक्षण कर सकते हैं। मैं अपनी जंग के साथ थोड़ा कठोर हूँ, लेकिन इन पंक्तियों के साथ कुछ ...

[#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 मिलेगा।

मेरे पास आरएफसी पाठ के बारे में एक प्रश्न है, उम्मीद है कि यह पूछने के लिए एक अच्छी जगह है।

पुन: उपयोग अनुभाग में , यह उदाहरण दिया गया है:

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> विवश हो सकता है? या कि एक करणीय लूप है?

@ राल्फजंग मैं मानता हूं कि गलत लगता है।

मेरे पास प्रक्रिया के बारे में एक सवाल है: यह मुद्दा कितना सार्थक है और लोगों के लिए इस सुविधा को आज़माना कितना सार्थक है? जैसा कि मैं समझता हूं कि वर्तमान कार्यान्वयन निराधार और अपूर्ण है और संभवतः पूरी तरह से चाक या कुछ और द्वारा प्रतिस्थापित किया जाएगा। अगर यह सच है, तो क्या हमें इस सुविधा और अन्य (जैसे जीएटी) को तब तक लागू करना चाहिए जब तक कि वे ठीक से फिर से तैयार नहीं हो सकते?

कृपया लागू न करें। टूटा हुआ, निराधार और अपूर्ण अभी भी प्रयोग की अनुमति देता है।

अगर यह सच है, तो क्या हमें इस सुविधा और अन्य (जैसे जीएटी) को तब तक लागू करना चाहिए जब तक कि वे ठीक से फिर से तैयार नहीं हो सकते?

कृपया न करें, PyO3 (पायथन बाइंडिंग लाइब्रेरी) वर्तमान में विशेषज्ञता पर निर्भर करता है। Https://github.com/PyO3/pyo3/issues/210 देखें

क्या std की उचित राशि इस पर भी निर्भर नहीं करती है? हालांकि मुझे याद आया कि वेक्टर और स्ट्रिंग संबंधित सामान के लिए बहुत सारे विशेष आंतरिक कार्यान्वयन देखने को मिले। ऐसा नहीं है कि डी-कार्यान्वयन को रोकना चाहिए, बस यह कि परीक्षक के संबंधित अनुभागों को हटाने के रूप में सरल नहीं होगा।

@ ल्यूक्रिएल हाँ, कई उपयोगी अनुकूलन (विशेष रूप से

उदाहरण के लिए, FusedIterator और TrustedLen विशेषज्ञता के बिना बेकार हैं।

PyO3 (पायथन बाइंडिंग लाइब्रेरी) वर्तमान में विशेषज्ञता पर निर्भर करता है

"डरावना" भागों के कारण यह डरावना है। विशेषज्ञता का गलत उपयोग करने के कारण मानक पुस्तकालय में गंभीर ध्वनि कीड़े थे। आप कैसे सुनिश्चित हैं कि आपके पास एक ही कीड़े नहीं हैं? इसके बजाय 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 71321 पीआर के बाहर अस्थिर पुस्तक के अनुसार यह उस सुविधा के लिए ट्रैकिंग मुद्दा है।

मुझे उस फीचर के बारे में ज्यादा जानकारी नहीं है, मैंने सिर्फ लिबस्टर्ड साउंडनेस फिक्स देखी है। इसे https://github.com/rust-lang/rust/pull/68970 में पेश किया गया, जो इसके बारे में कुछ और बातें बताता है।

@matthewjasper को यह समझ में आता है कि इसे थोड़ा और दस्तावेज़ किया जाए और रात के उपयोगकर्ताओं को feature(specialization) प्रवास करने के लिए कहा जाए?

ऐसा लगता है कि कम से कम एक चेतावनी होनी चाहिए। ऐसा लगता है कि यह सुविधा अपनी वर्तमान स्थिति में उपयोग करने के लिए blatantly टूटी हुई और खतरनाक है।

मुझे लगता है कि 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 किसी भी सदस्य को ओवरराइड करते हैं, तो आपको उन सभी को ओवरराइड करना होगा। हमने बाद में इस विचार का समर्थन किया, और फिर विभिन्न पुनरावृत्तियों के चारों ओर लात मारी, जैसे कि "डिफ़ॉल्ट समूह" (जो यहां भी काम करेगा), और अंत में किसी भी समाधान को नहीं अपनाया क्योंकि हमें लगा कि हम बाद में एक बार सौदा कर लेते हैं अन्य, एर, दबाने की समस्याएं (cc # 71420)।

कृपया न करें, PyO3 (पायथन बाइंडिंग लाइब्रेरी) वर्तमान में विशेषज्ञता पर निर्भर करता है। PyO3 / pyo3 # 210 देखें

यहाँ PyO3 अनुचर - हम विशेषज्ञता से दूर जाने के पक्ष में हैं ताकि हम स्थिर जंग पर पहुँच सकें। क्या बाकी विशेषज्ञता पूरी होने से पहले min_specialization स्थिर होने की संभावना होगी?

मुझे लगता है कि 2021 संस्करण की प्लानिंग लैंग डिजाइन मीटिंग (यह यूट्यूब पर है, क्षमा करें, मैं अपने फोन पर हूं, या मैं एक लिंक खोजने की कोशिश करूंगा) में min_specialization को स्थिर करने की कोशिश करने की कुछ चर्चा थी। मैं भूल गया कि उन्होंने इसके बारे में क्या कहा है

मुझे लगता है कि 2021 संस्करण की प्लानिंग लैंग डिजाइन मीटिंग (यह यूट्यूब पर है, क्षमा करें, मैं अपने फोन पर हूं, या मैं एक लिंक खोजने की कोशिश करूंगा) में min_specialization को स्थिर करने की कोशिश करने की कुछ चर्चा थी। मैं भूल गया कि उन्होंने इसके बारे में क्या कहा है

मुझे लगता है कि यह सही 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] साथ विशेषता घोषणा को चिह्नित करते हैं।

इस फाइल में मेरा सारा स्पेशलाइजेशन किया गया है और यहाँ एक विशेषज्ञता के

फीचर काम करता है और मुझे ठीक वही चाहिए जो मुझे चाहिए। यह स्पष्ट रूप से रस्टक आंतरिक मार्कर का उपयोग कर रहा है और इसलिए चेतावनी के बिना टूटने का खतरा है।

प्रतिक्रिया का एकमात्र नकारात्मक पक्ष यह है कि मुझे default मतलब नहीं लगता है। अनिवार्य रूप से अभी क्या default अर्थ है: "यह निहित विशेष है, इसलिए व्याख्या का अर्थ है कि यह एक उपसमूह को कवर करता है, जो इसे परस्पर विरोधी निहितार्थ के बजाय इसके विशेषज्ञता के रूप में दर्शाता है"। समस्या यह है कि यह बहुत ही अजीब दिखने वाला कोड है:

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

यहाँ दूसरा निहित पहले की विशेषता है लेकिन यह 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]) {
        ...
    }
}

प्रतिक्रिया के लिए धन्यवाद।

यहाँ मेरी टिप्पणी, विशेष रूप से आइटम ६, मानक पुस्तकालय में एक ठोस मामला प्रदान करता है, जहाँ एक विशेषज्ञता होना वांछनीय हो सकता है जो केवल आंशिक रूप से अधिक उपयोग योग्य हो: IndexSet एक अलग Output प्रकार की आवश्यकता होगी क्योंकि IndexSet Index बिना लागू किया जा सकता है, लेकिन हम शायद दोनों प्रकारों को अलग-अलग Output प्रकारों के साथ सह-अस्तित्व की अनुमति नहीं देना चाहते हैं। के बाद से IndexSet के मामले में एक डिफ़ॉल्ट कार्यान्वयन हो सकता था IndexMut , इसके बारे में विशेषज्ञता अनुमति देने के लिए उचित होगा index_set की विशेषज्ञता की अनुमति के बिना विधि Output ।

मेरे पास वीडियो के साथ एक कठिन समय है, इसलिए मैं लिंक किए गए वीडियो को नहीं देख सकता हूं, हालांकि, मेरे पास #[min_specialization] के बारे में एक प्रश्न है। के रूप में-है, वहाँ एक है rustc_unsafe_specialization_marker की तरह लक्षण पर विशेषता FusedIterator कि अनुकूलन संकेत प्रदान करते हैं, ताकि वे पर विशेष जा सकता है। @matthewjasper ने लिखा:

यह अस्वाभाविक है लेकिन हम इसे अल्पावधि में अनुमति देते हैं क्योंकि यह विशुद्ध रूप से सुरक्षित कोड के साथ उपयोग करने के बाद उपयोग नहीं कर सकता है क्योंकि लक्षण विधियों पर विशेषज्ञता हो सकती है।

मुझे लगता है कि यह योजना @ न्यूटन के प्रस्ताव को लागू करने और इन ( where specialize(T: FusedIterator) ) जैसे लक्षणों के लिए एक विशेषज्ञता मोडिटी जोड़ने की है। लेकिन वर्तमान में, ऐसा प्रतीत होता है कि कोई भी कोड इन लक्षणों पर विशेषज्ञ कर सकता है । यदि इसे स्थिर किया जाता है, तो लोग स्थिर विशेषज्ञताओं को लिख सकते हैं, जो इस पर निर्भर करते हैं, जिसका अर्थ है कि यह निराधारता स्थिर होगी।

क्या इन लक्षणों पर विशेषज्ञता भी मानक पुस्तकालय तक सीमित होनी चाहिए, फिर? क्या मानक पुस्तकालय उन पर विशेषज्ञ होने के लिए पर्याप्त लाभ प्राप्त करते हैं?

यदि इसे स्थिर किया जाता है, तो लोग स्थिर विशेषज्ञताओं को लिख सकते हैं, जो इस पर निर्भर करते हैं, जिसका अर्थ है कि यह निराधारता स्थिर होगी।

यह मेरी समझ है कि min_specialization रूप में-स्थिरीकरण के लिए इरादा नहीं है।

मैं दूसरे के कुछ प्रकार के मार्करों को विशेषांक लगाना चाहूंगा। सरसराहट में कोड के कुछ मामले और मानक पुस्तकालय ऐसा नहीं कर रहे हैं जो ऐसा दिखता है क्योंकि यह जानने का कोई तरीका नहीं है कि विशेषज्ञता वास्तव में हो रही है:

Copy एक अनावश्यक विशेषज्ञता:
https://github.com/rust-lang/rust/pull/72707/files#diff -3afa644e1d09503658d661130df65f59L1955

"विशेषज्ञता" जो नहीं है:
https://github.com/rust-lang/rust/pull/71321/files#diff -da456bd3af6d94a9693e625ff7303113L1589

मैक्रो द्वारा तब तक कार्यान्वित किया जाता है जब तक कि कोई ध्वज डिफ़ॉल्ट डिफ़ॉल्ट को पार नहीं कर जाता है:
https://github.com

@matthewjasper अंतिम लिंक किसी भी विशिष्ट स्निपेट से लिंक करने के लिए प्रकट नहीं होता है।

मुझे यकीन नहीं है कि यह एक स्पष्ट लक्ष्य है, लेकिन AIUI तथ्य यह है कि विशेषज्ञता के निशान चिह्नित नहीं हैं, आपको कंबल के निशान पर परिवर्तन से बचने का एक तरीका देता है। एक नया default impl<T> Trait for T डाउनस्ट्रीम के साथ संघर्ष नहीं करता है - वे सिर्फ विशेषज्ञता बन जाते हैं।

क्या इसे केवल चिन्हित करना एक चेतावनी हो सकती है?

सरसराहट में कोड के कुछ मामले और मानक पुस्तकालय ऐसा नहीं कर रहे हैं जो ऐसा दिखता है क्योंकि यह जानने का कोई तरीका नहीं है कि वास्तव में विशेषज्ञता क्या हो रही है

जावा के साथ मेरा अनुभव समान है (हालांकि बिल्कुल अनुरूप नहीं)। यह पता लगाना मुश्किल हो सकता है कि वास्तव में किस वर्ग का उपवर्ग चल रहा है ...

हम कुछ विशेष मार्करों पर कुछ मार्कर चाहते हैं, हालांकि, यह स्पष्टता के लिए भी है कि क्या सही है?

हम दोनों स्थानों पर मार्कर लगा सकते हैं, जो फिर जंग त्रुटि या चेतावनी संदेशों में सुधार करता है क्योंकि वे अब जानते हैं कि क्या विशेषज्ञता वांछित है और मौजूद होने पर दूसरी जगह को इंगित कर सकता है।

यदि एक अपस्ट्रीम टोकरा एक जोड़ जोड़ता है, तो बस उन्नयन से अलग, एक डाउनस्ट्रीम टोकरा उन चालों को नियोजित कर सकता है जो नए और पुराने दोनों संस्करणों के खिलाफ संकलन करते हैं, यह सुनिश्चित नहीं है कि यह फायदेमंद है।

मुझे लगता है कि बदलाव दिखाने के लिए यह अंतर बहुत बड़ा हो सकता है। यह इस ओर इशारा कर रहा है: https://github.com/rust-lang/rust/blob/fb818d4321dee29ec1938c002c1ff79b0e7eaadff/src/librust_span/def_id.rs#L124

पुन: कंबल निहित है, वे वैसे भी परिवर्तन तोड़ रहे हैं:

• वे आंशिक रूप से एक डाउनस्ट्रीम प्रत्यारोपण को ओवरलैप कर सकते हैं, जिसकी अनुमति नहीं है
• सुसंगतता उनके गैर-अस्तित्व को और अधिक सूक्ष्म तरीकों से ग्रहण कर सकती है (यही वजह है कि पुनर्जीवन प्रत्यारोपण आंतरिक रूप से जोड़े गए थे)
• विशेषज्ञता के निहितार्थ हमेशा लागू होते हैं, जिसका अर्थ है:
  
  
  
  • हम लोगों के प्रत्यारोपण को तोड़ते हैं (क्या min_specialization करता है)।
  
  
  • हमें आवश्यकता होती है कि हम किसी भी तरह से अपनी विशेषता सीमा को हमेशा के लिए लागू करें जहां आवश्यक हो।
  
  
  • हम उनके लिए हमेशा लागू परिवर्तन करते हैं और संभावित रूप से सूक्ष्म रनटाइम बग का परिचय देते हैं जब डिफ़ॉल्ट निहितार्थ अब लागू होता है।
  
  

@cuviper वास्तव में, मुझे लगता है कि अभी भी नए कंबल इम्प्लांट जोड़ने के आसपास के किनारे मामले थे, यहां तक ​​कि विशेषज्ञता के साथ भी। मुझे याद है कि मैं यह पता लगाने की कोशिश कर रहा था कि हमें impl<T: Copy> Clone for T { } जोड़ने की अनुमति देने के लिए यह ब्लॉग पोस्ट मैंने इसके बारे में किसी भी स्थिति में

भले ही, हम इसे #[override] एनोटेशन न करने के लिए एक लिंट चेतावनी दे सकते हैं।

उस ने कहा, अगर हम उपयोगकर्ता को यह घोषित कर सकते हैं कि वे कौन से विशेषज्ञ हैं (कोई विचार नहीं है कि हम ऐसा कैसे करेंगे), यह उनकी चीजों को सरल करेगा। अभी कंपाइलर को इम्प्लांट के बीच के रिश्तों को कम करना है और यह हमेशा थोड़ा मुश्किल है।

चाक परियोजना में हमें लंबित वस्तुओं में से एक प्रयास करना है और वापस जाना है और यह बताना है कि वहां विशेषज्ञता कैसे व्यक्त की जानी चाहिए।

सरसराहट में कोड के कुछ मामले और मानक पुस्तकालय ऐसा नहीं कर रहे हैं जो ऐसा दिखता है क्योंकि यह जानने का कोई तरीका नहीं है कि वास्तव में विशेषज्ञता क्या हो रही है

जावा के साथ मेरा अनुभव समान है (हालांकि बिल्कुल अनुरूप नहीं)। यह पता लगाना मुश्किल हो सकता है कि वास्तव में किस वर्ग का उपवर्ग चल रहा है ...

मई में वापस, मैंने 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 का उपयोग कर सकती है, क्योंकि कन्वेंशन द्वारा इस तरह के निहितार्थ के लिए 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"
}

यह फॉर्म्युलेशन अपस्ट्रीम के क्रम को चुनने के लिए अपस्ट्रीम को अधिक नियंत्रण देता है, और जैसा कि यह विशेषता / फ़ंक्शन हस्ताक्षर का हिस्सा है, यह प्रलेखन में दिखाई देगा। IMO यह जानने के लिए "इम्प्लायिंग चेज़िंग" को रोकता है कि वास्तव में कौन सी शाखा लागू है, क्योंकि रिज़ॉल्यूशन ऑर्डर स्पष्ट है।

यह शायद जीवनकाल के आसपास त्रुटियों को बना सकता है और समानता को अधिक स्पष्ट रूप से टाइप कर सकता है क्योंकि विशेषज्ञता को लागू करते समय केवल अपस्ट्रीम उन्हें मिल सकता है (चूंकि डाउनस्ट्रीम केवल "विशेषज्ञता विशेषता" को लागू कर रहा है।

इस फॉर्मूलेशन की कमियां यह हैं कि यह RFC में एक की तुलना में बहुत अलग मार्ग है, और 2016 से लागू किया जा रहा है, और यह कि कम से कम कुछ लोगों ने इस बात पर चिंता व्यक्त की कि यह वर्तमान के रूप में अभिव्यंजक और / या सहज नहीं होगा। विशेषज्ञता सुविधा (मुझे लगता है "प्रकार पर मेल" बहुत सहज है, लेकिन मैं पक्षपाती हूं क्योंकि मैं सूत्रीकरण का प्रस्ताव करता हूं)।

मैच सिंटैक्स में एक और (सिंटैक्टिकल) लाभ हो सकता है: यदि यह भविष्य में कुछ बिंदुओं पर कॉन्स्टिट्यूड-मैचेड गार्ड्स के साथ बढ़ाया गया था, तो किसी को कॉन्स्ट्रेक्ट एक्सप्रेशंस पर बाउंड सशर्त व्यक्त करने के लिए जिम्नास्टिक करने की आवश्यकता नहीं होगी। जैसे कोई size_of , align_of , needs_drop या सरणी आकार के आधार पर विशेषज्ञता लागू कर सकता है।

@dureuill जानकारी के लिए धन्यवाद! यह वास्तव में एक दिलचस्प विचार है। एक चिंता का विषय यह है कि यह जरूरी नहीं है कि विशेषज्ञता के लिए कुछ अन्य प्रत्याशित उपयोग के मामलों को हल किया जाए, विशेष रूप से "वृद्धिशील रूप से परिष्कृत व्यवहार" मामला जैसा कि इस ब्लॉग पोस्ट में @aturon द्वारा वर्णित है। फिर भी, ध्यान में रखने लायक।

@dureuill यह विचार वास्तव में दिलचस्प है और इसमें बहुत अधिक संभावनाएं हो सकती हैं, लेकिन विकल्प हमेशा समकक्ष विनिमय नहीं होता है।
मेरे विचार से इसका कारण यह नहीं है कि किसी को भी अधिक सामान्य कार्यान्वयन को पूरी तरह से बदलने का अवसर नहीं दिया गया है। एक अन्य समस्या यह भी हो सकती है कि हमारे पास वास्तव में where सिंटैक्स RFC में मौजूद सभी सुविधाओं के लिए समर्थन नहीं है, जिस पर आपका सुझाव निर्भर करता है।
सुझाव पेचीदा है, इसलिए हो सकता है कि यह विशेषज्ञता के लिए एक प्रतियोगी के बजाय एक अलग विशेषता के रूप में खुद का आरएफसी हो सकता है क्योंकि दोनों उपयोगी होंगे और मुझे कोई कारण नहीं दिखता कि वे एक साथ क्यों नहीं रह सकते।

@ the8472 @nikomatsakis , @ डार्क-लीजन: सकारात्मक प्रतिक्रिया के लिए धन्यवाद! मैं IRLO थ्रेड में आपकी कुछ टिप्पणियों का जवाब देने की कोशिश करता हूं, क्योंकि मैं ट्रैकिंग मुद्दे पर बहुत अधिक शोर नहीं करना चाहता हूं (मैं आप में से प्रत्येक के लिए माफी चाहता हूं, जिन्होंने विशेषज्ञता पर समाचार की उम्मीद की थी और बस मेरी रंबलिंग मिली: निस्तब्धता :)।

अगर मैं कुछ युवा लिखने का प्रबंधन करता हूं, तो मैं एक अलग RFC खोल सकता हूं। इस बीच, मैं लिंक किए गए IRLO थ्रेड पर प्रतिक्रिया के लिए बहुत खुला हूं। मैंने aturon के ब्लॉग पोस्ट से एक लंबा उदाहरण जोड़ा है, इसलिए उस पर टिप्पणी करने के लिए स्वतंत्र महसूस करें!

मैं भी कुछ विशेष प्रकार के मार्कर होने के पक्ष में हूं।

2021 संस्करण दृष्टिकोण, जो हमें आगे के खोजशब्दों को आरक्षित करने की अनुमति देता है (जैसे specialize )। इस सुविधा की जटिलता और इतिहास को देखते हुए, मुझे नहीं लगता कि यह 2021 संस्करण की रिलीज़ से पहले स्थिर हो जाएगा (मुझे गलत साबित करने के लिए स्वतंत्र लग रहा है) जिसका अर्थ है - मेरी राय में - (एक) नए कीवर्ड के साथ खेलना ) उचित है।

अन्यथा, केवल मौजूदा कीवर्ड जो लगता है ... अच्छी तरह से .. मार्कर के रूप में उपयुक्त है, super हो सकता है?

Https://github.com/rust-lang/rust/issues/31844#issuecomment -639977601 से @LLFourn के उदाहरण का पुन: उपयोग करके सारांश:

• 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 ) (https://github.com/rust-lang में @ssokolow द्वारा उठाया गया वैध चिंता का विषय ) / जंग / मुद्दों / 31,844 # issuecomment-690,980,762)

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 एक आरक्षित कीवर्ड है, मुझे लगता है कि यह कार्यों के लिए अभिप्रेत था, इसलिए यह एक अंतर्निहित ब्लॉक के लिए उपयोग करने योग्य हो सकता है।

विशेषज्ञ भी स्थानीय निर्भर है - एक ऑस्ट्रेलियाई के रूप में यह मेरे लिए विशेषज्ञ है, इसलिए 'कल्पना' का उपयोग करने से स्थानीय अस्पष्टता दूर हो जाती है।

विशेषज्ञ भी स्थानीय निर्भर है - एक ऑस्ट्रेलियाई के रूप में यह मेरे लिए विशेषज्ञ है, इसलिए 'कल्पना' का उपयोग करने से स्थानीय अस्पष्टता दूर हो जाती है।

वह काम करता है, सिवाय इसके कि 'स्पेसिफिकेशन' स्पेसिफिकेशन के लिए एक सामान्य संक्षिप्त नाम है, इसलिए मुझे लगता है कि स्पेशलाइजेशन के लिए 'स्पेक' का उपयोग करना भ्रमित करने वाला होगा। भले ही ऑस्ट्रेलिया में शब्दों को अलग-अलग तरीके से लिखा गया हो, फिर भी हर कोई समझ सकता है कि अगर यह शब्द 'z' या 's' के साथ वर्तनी में आता है।

एक कनाडाई के रूप में, मुझे यह कहना है कि विशेषज्ञ / विशेषज्ञ प्रोग्रामिंग में उपयोग किया जाने वाला एकमात्र शब्द नहीं है जो लोकेल के साथ बदलता रहता है।

यहां, हम "रंग" का उपयोग करते हैं, लेकिन यह हमेशा मुझे दुर्लभ अवसरों पर यात्रा करता है जब एक प्रोग्रामिंग भाषा या लाइब्रेरी "रंग" के बजाय इसका उपयोग करता है। बेहतर या बदतर के लिए, अमेरिकी अंग्रेजी एपीआई डिजाइन में एक वास्तविक मानक का एक सा है और, रंग / रंग जैसे शब्दों के साथ, दूसरे पर एक वर्तनी का पक्ष लेने के लिए चयन करना वास्तव में वंचित किए बिना अपरिहार्य है।

यह देखते हुए कि मैं "स्पेसिफिकेशन" का मतलब "स्पेसिफिकेशन" से कितनी दृढ़ता से उम्मीद करता हूं, मुझे लगता है कि यह एक और स्थिति है, जहां हमें अमेरिकी अंग्रेजी वर्तनी पर सबसे कम विकल्प चुनने पर विचार करना चाहिए।

यह डिफेक्टो हो सकता है, लेकिन इसका मतलब यह नहीं है कि उनका उपयोग करना ठीक है। मैं खुद को उदाहरण के लिए "रंग के रूप में रंग का उपयोग करता हूं" जैसे आयात कर रहा हूं। मैं हमेशा के रूप में अच्छी तरह से बनाम z पर यात्रा करते हैं। मुझे लगता है कि Rust का समावेशी और सुगमता के प्रति सकारात्मक दृष्टिकोण को देखते हुए, यह उन भाषा की शर्तों को समझ में आता है जो स्थानीय निर्भर नहीं हैं, क्योंकि छोटे उपयोगकर्ता जैसे रंग / रंग और s / z का निर्माण करते हैं।

मैं सिद्धांत रूप में सहमत हूं। मुझे इस बात पर संदेह है कि इस मामले के लिए, एक स्थानीय-तटस्थ विकल्प है, जो इसे हल करने की तुलना में अधिक समस्याओं का कारण नहीं है।

एक गैर-अंग्रेजी मूल वक्ता के रूप में, मुझे यह कुछ मनोरंजक लगता है कि देशी अंग्रेजी बोलने वाले अतिरिक्त u बारे में शिकायत करेंगे, जो कि समावेशिता के लिए एक बाधा है। ज़रा सोचिए कि ऐसा क्या होगा अगर सब कुछ थोड़ा अजीब न हो, लेकिन पूरी तरह से अलग भाषा में लिखा गया हो।

अलग तरीके से रखें: जंग में इस्तेमाल होने वाला हर शब्द स्थानीय निर्भर है।

बेहतर या बदतर के लिए, रस्ट की चीजों को अमेरिकी अंग्रेजी में वर्तनी दी जाती है। कई लोगों के लिए इसका मतलब है कि उनकी दूसरी या तीसरी भाषा में काम करना; दूसरों के लिए इसका मतलब है कि वर्तनी को थोड़ा समायोजित करना। यह वही है जो लोगों के एक पूरे समूह को एक साथ काम करने के लिए लेता है। मुझे लगता है कि अंग्रेजी के कई वेरिएंट में समान शब्दों को चुनने की कोशिश का लाभ एक असंदिग्ध शब्द चुनने की तुलना में मामूली है - और spec अस्पष्ट है जैसा कि ऊपर बताया गया है।

कीवर्ड के रूप में special उपयोग करें?

वैकल्पिक, दो खोजशब्द बनाएँ: specialize और specialise और उन्हें समतुल्य बनाएं ...

(या आप गैर-अमेरिकियों को वास्तविक वर्तनी लिखना सीख सकते हैं: हमें:-)

मैं यह नहीं बोल सकता कि अधिकांश भाषाएं क्या करती हैं, लेकिन सीएसएस अमेरिकी अंग्रेजी वर्तनी का उपयोग सब कुछ नया करने के लिए करता है। वास्तविक रूप से अमेरिकी अंग्रेजी का उपयोग प्रोग्रामिंग में भी अधिक बार किया जाता है।

@ मार्क-इम दुर्भाग्य से, यह एक फिसलन ढलान है जो तर्क के लिए अग्रणी है कि प्रत्येक प्रमुख भाषा में जंगलों में वैकल्पिक सेट होना चाहिए जो शिक्षार्थियों से आ रहे हैं।

यह भी अनावश्यक रूप से भाषा को जटिल बनाता है कि कीवर्ड के लिए कई समानार्थी शब्द हैं क्योंकि लोग और पार्सर केवल इस विचार के लिए उपयोग किए जाते हैं कि व्हाट्सएप उस तरह भिन्न हो सकता है।

(यह उल्लेख नहीं करने के लिए कि यह संभावित रूप से पुस्तकालयों में समानार्थक समानार्थी शब्द के लिए एक धक्का होगा, जो तब शुद्ध नकारात्मक होने से बचाने के लिए जंग के डिजाइन और कार्यान्वयन कार्य की आवश्यकता होगी।)

अंग्रेजी की कौन सी बोली के बारे में बहस करने के बजाय, हम चाहते हैं कि यह पहचानकर्ता अंदर हो, शायद हम इसे समझौता कर सकते हैं और इसे हिब्रू में डाल सकते हैं?

@ssokolow जबकि सामान्य रूप से फिसलन ढलान तर्क का उपयोग करने के लिए एक मजबूत तर्क नहीं है, मैं इस मामले में आपके साथ सहमत हूं। एक तर्क दे सकता है कि कई भाषाएं ठीक हैं लेकिन कम से कम दो कारण हैं कि यह क्यों नहीं है:

• अलग-अलग भाषाओं में कुछ शब्द समान दिखते हैं, लेकिन अलग-अलग चीजों का मतलब है (अभी प्रोग्रामिंग-संबंधित उदाहरण के साथ नहीं आ सकता है, लेकिन एक यादृच्छिक उदाहरण: a स्लोवाक में and अंग्रेजी में है)
• लोगों को दूसरी भाषा में कोड पढ़ने में भारी परेशानी भले ही वे भाषा जानते हों । मैं अनुभव से जानता हूं। (लंबी कहानी संक्षेप: मुझे विश्वविद्यालय शिक्षा घोटाले में मेरी "मातृ भाषा" से सीधे अंग्रेजी में अनुवादित शब्दों के साथ कुछ ग्रंथों को समझने में बड़ी परेशानी हुई।)

अब पीछे की ओर काम करते हुए, अन्य भाषाओं की नहीं, अंग्रेजी की अलग-अलग बोलियों को क्यों पसंद किया जाना चाहिए? मुझे एक बिंदु नहीं दिख रहा है। संगति (सब कुछ अमेरिकी अंग्रेजी है) सबसे सरल, समझने में आसान और कम से कम त्रुटि-प्रवण लगता है।

यह सब कहा जा रहा है, मुझे बहुत खुशी होगी "क्या आपका मतलब XXX था?" त्रुटि संदेश दृष्टिकोण। अन्य शब्द जिनके पास अन्य समस्याएं नहीं हैं, ठीक हैं।

कम से कम किसी को कोड में फुटबॉल पर चर्चा करने की आवश्यकता नहीं है। ;)

यूएस स्पेलिंग का उपयोग करने वाले देशों में लगभग 70% देशी अंग्रेजी बोलने वाले लोग रहते हैं।

इसके अलावा ..

"-इज़ स्पेलिंग को अक्सर ब्रिटेन में एक अमेरिकीवाद के रूप में गलत तरीके से देखा जाता है। 15 वीं शताब्दी के बाद से इसका उपयोग किया जाता रहा है, एक सदी से भी अधिक-से-पूर्व भविष्यवाणी की गई है। यह सीधे-ग्रीक-माइकिको-कैज़ीन और लैटिन -इज़ारे से आता है, जबकि - ise फ्रांसीसी -iser के माध्यम से आता है। ऑक्सफोर्ड इंग्लिश डिक्शनरी (OED) एक विकल्प के रूप में -ise फॉर्म की सिफारिश करता है और सूचीबद्ध करता है। "

"ऑक्सफोर्ड यूनिवर्सिटी प्रेस (OUP) द्वारा प्रकाशन-हेनरी वॉटसन फाउलर के ए डिक्शनरी ऑफ़ मॉडर्न इंग्लिश यूज़, हार्ट्स रूल्स, और द ऑक्सफ़ोर्ड गाइड टू इंग्लिश यूज़ के रूप में प्रकाशन-भी सिफारिश करते हैं। हालांकि, रॉबर्ट एलन के पॉकेट फाउलर का मॉडर्न इंग्लिश यूज़ या तो स्पेलिंग मानते हैं। कहीं भी स्वीकार्य होने के लिए लेकिन यू.एस.

संदर्भ। https://en.wikipedia.org/wiki/American_and_British_English_spelling_differences# -ise, _- ize _ (- isation, _- ization)

ऐसा प्रतीत होता है कि स्पैनिश और इतालवी में az या दो हैं, इसलिए यह निश्चित नहीं है कि फ्रेंच कहाँ से प्राप्त करता है, शायद जर्मन से?

क्या विशिष्ट कीवर्ड के आसपास आगे बढ़ते हुए और नामकरण को एक आंतरिक धागे में ले जाया जा सकता है? मैं फीचर पर प्रगति के अपडेट के लिए इस मुद्दे का अनुसरण कर रहा हूं, और इस चर्चा को थोड़ा शोर मिल रहा है।