हुज़ाह!

यहाँ इसका WIP कार्यान्वयन है: https://github.com/canndrew/rust/tree/bang_type_coerced

यह वर्तमान स्थिति है: यह पुराने-ट्रांस के साथ बनाता है और प्रयोग करने योग्य है लेकिन इसमें कुछ असफल परीक्षण हैं। कुछ परीक्षण एक बग के कारण विफल हो जाते हैं जिसके कारण if (return) {} जैसे कोड ट्रांस के दौरान क्रैश हो जाते हैं। अन्य परीक्षण लिंक-टाइम-ऑप्टिमाइज़ेशन के साथ करना है और मेरे लिए हमेशा छोटी गाड़ी रही है, इसलिए मुझे नहीं पता कि उनका मेरे परिवर्तनों से कोई लेना-देना है या नहीं।

मेरा वर्तमान रोडमैप है:

• इसे एमआईआर के साथ काम करें। उम्मीद है कि यह बहुत कठिन नहीं होगा क्योंकि इस तरह मैंने इसे कार्यान्वित करना शुरू कर दिया है, लेकिन मुझे एक समस्या है जहां एमआईआर संकलन के दौरान सेगफॉल्ट बनाता है।
• संकलक से अप्रचलित विचलन सामग्री को शुद्ध करें ( FnOutput , FnDiverging और संबंधित)।
• फीचर गेट के पीछे नए प्रकार को छिपाएं। इसका मतलब होगा, जब सुविधा अक्षम हो:
  
  
  
  • ! को केवल वापसी स्थिति में एक प्रकार के रूप में पार्स किया जा सकता है।
  
  
  • डाइवर्जिंग टाइप वेरिएबल डिफ़ॉल्ट रूप से () ।
  
  
• यह पता लगाएं कि जब किसी विशेषता को हल करने के लिए डिफ़ॉल्ट () उपयोग किया जाता है तो हम संगतता चेतावनियां कैसे बढ़ा सकते हैं। ऐसा करने का एक तरीका DefaultedUnit नामक एएसटी में एक नया प्रकार जोड़ना हो सकता है। यह प्रकार () जैसा व्यवहार करता है और कुछ परिस्थितियों में () में बदल जाएगा, लेकिन जब यह एक विशेषता को हल करता है तो चेतावनी देता है (जैसे () )। इस दृष्टिकोण के साथ समस्या यह है कि मुझे लगता है कि कार्यान्वयन के साथ सभी बगों को पकड़ना और ठीक करना मुश्किल होगा - हम लोगों के कोड को तोड़ने से बचाने के लिए लोगों के कोड को तोड़ देंगे।

क्या इस सूची में कुछ जोड़ने की जरूरत है? क्या यह सिर्फ मैं ही इस पर काम करने वाला हूं? और क्या इस शाखा को मुख्य भंडार में ले जाया जाना चाहिए?

पता लगाएँ कि जब किसी विशेषता को हल करने के लिए डिफ़ॉल्ट () उपयोग किया जाता है, तो हम संगतता चेतावनियाँ कैसे बढ़ा सकते हैं। ऐसा करने का एक तरीका DefaultedUnit नामक एएसटी में एक नया प्रकार जोड़ना हो सकता है। यह प्रकार () जैसा व्यवहार करता है और कुछ परिस्थितियों में () में बदल जाएगा, लेकिन जब यह एक विशेषता को हल करता है तो एक चेतावनी देता है (जैसे () )। इस दृष्टिकोण के साथ समस्या यह है कि मुझे लगता है कि कार्यान्वयन के साथ सभी बगों को पकड़ना और ठीक करना मुश्किल होगा - हम लोगों के कोड को तोड़ने से बचाने के लिए लोगों के कोड को तोड़ देंगे।

@eddyb , @ arielb1 , @anyone_else : इस दृष्टिकोण पर विचार? मैं इस स्तर तक काफी ऊपर हूं (कुछ असफल परीक्षणों के बिना जो मैं (बहुत धीरे-धीरे) ठीक करने की कोशिश कर रहा हूं)।

हमें किन लक्षणों को लागू करना चाहिए !? प्रारंभिक पीआर #35162 में ऑर्ड और कुछ अन्य शामिल हैं।

क्या ! स्वचालित रूप से _all_ लक्षण लागू नहीं करना चाहिए?

इस प्रकार का कोड काफी सामान्य है:

trait Baz { ... }

trait Foo {
    type Bar: Baz;

    fn do_something(&self) -> Self::Bar;
}

मुझे उम्मीद है कि ! Foo::Bar लिए प्रयोग करने योग्य होगा ताकि यह इंगित किया जा सके कि Bar वास्तव में कभी मौजूद नहीं हो सकता है:

impl Foo for MyStruct {
    type Bar = !;
    fn do_something(&self) -> ! { panic!() }
}

लेकिन यह तभी संभव है जब ! सभी लक्षणों को लागू करे।

@tomaka इसके बारे में RFC है: https://github.com/rust-lang/rfcs/pull/1637

समस्या यह है कि यदि ! Trait लागू करता है तो उसे !Trait भी लागू करना चाहिए ...

समस्या यह है कि अगर! गुण को लागू करता है उसे भी लागू करना चाहिए !विशेषता...

फिर विशेष-मामला ! ताकि यह किसी भी विशेषता आवश्यकता को अनदेखा कर दे?

@tomaka ! _all_ लक्षणों को स्वचालित रूप से लागू नहीं कर सकता क्योंकि लक्षणों में स्थिर तरीके और संबंधित प्रकार/स्थिर हो सकते हैं। यह स्वचालित रूप से उन लक्षणों को लागू कर सकता है जिनमें केवल गैर-स्थैतिक विधियां हैं (यानी विधियां जो Self लेती हैं)।

!Trait , किसी ने सुझाव दिया कि ! Trait _and_ !Trait दोनों को स्वतः कार्यान्वित कर सकता है। मुझे यकीन नहीं है कि यह ध्वनि है, लेकिन मुझे संदेह है कि नकारात्मक लक्षण बिल्कुल भी ध्वनि नहीं हैं।

लेकिन हाँ, यह अच्छा हो सकता है यदि ! उदाहरण में Baz को स्वतः कार्यान्वित कर सकता है जो आपने इस प्रकार के मामलों के लिए दिया था।

जब हम वास्तव में () / ! लिए डायवर्जिंग टाइप वैरिएबल को डिफॉल्ट करते हैं और हम पर्याप्त प्रकार की जानकारी का अनुमान लगाने में सक्षम नहीं होने के बारे में एक त्रुटि कब फेंकते हैं? क्या यह कहीं निर्दिष्ट है? मैं निम्नलिखित कोड संकलित करने में सक्षम होना चाहता हूं:

let Ok(x) = Ok("hello");

लेकिन मुझे मिलने वाली पहली त्रुटि " unable to infer enough type information about _ " है। इस मामले में मुझे लगता है कि यह _ लिए डिफ़ॉल्ट रूप से ! लिए समझ में आता है। हालाँकि जब मैं डिफ़ॉल्ट व्यवहार के आसपास परीक्षण लिख रहा था तो मुझे एक प्रकार का चर डिफ़ॉल्ट बनाना आश्चर्यजनक रूप से कठिन लगा। इसलिए ये परीक्षण इतने जटिल हैं।

मैं स्पष्ट रूप से जानना चाहता हूं कि हमारे पास यह डिफ़ॉल्ट व्यवहार क्यों है और इसे कब लागू किया जाना चाहिए।

लेकिन पहली त्रुटि मुझे मिलती है "_ के बारे में पर्याप्त प्रकार की जानकारी का अनुमान लगाने में असमर्थ"। इस मामले में मुझे लगता है कि यह _ के लिए डिफ़ॉल्ट रूप से समझ में आता है! हालाँकि जब मैं डिफ़ॉल्ट व्यवहार के आसपास परीक्षण लिख रहा था तो मुझे एक प्रकार का चर डिफ़ॉल्ट बनाना आश्चर्यजनक रूप से कठिन लगा। इसलिए ये परीक्षण इतने जटिल हैं।

मेरी राय में यह बहुत अच्छा विचार है। None लिए समान जो उदाहरण के लिए डिफ़ॉल्ट रूप से Option<!> ।

@carllerche

unit_fallback परीक्षण निश्चित रूप से इसे प्रदर्शित करने का एक अजीब तरीका है। एक कम-मैक्रो-आई संस्करण है

trait Balls: Default {}
impl Balls for () {}

struct Flah;

impl Flah {
    fn flah<T: Balls>(&self) -> T {
        Default::default()
    }
}

fn doit(cond: bool) {
    let _ = if cond {
        Flah.flah()
    } else {
        return
    };
}

fn main() {
    let _ = doit(true);
}

केवल return / break / panic!() द्वारा बनाया गया प्रकार चर किसी भी चीज़ के लिए डिफ़ॉल्ट है।

जब हम वास्तव में ()/! और हम पर्याप्त प्रकार की जानकारी का अनुमान लगाने में सक्षम नहीं होने के बारे में त्रुटि कब करते हैं? क्या यह कहीं निर्दिष्ट है?

"निर्दिष्ट" परिभाषित करें। :) इसका उत्तर यह है कि कुछ ऑपरेशन, जो कोड के बाहर कहीं भी लिखे गए नहीं हैं, के लिए आवश्यक है कि उस बिंदु पर प्रकार ज्ञात हो। सबसे आम मामला फ़ील्ड एक्सेस ( .f ) और विधि प्रेषण ( .f() ) है, लेकिन दूसरा उदाहरण deref ( *x ) है, और शायद एक या दो और हैं। इसकी आवश्यकता होने के लिए ज्यादातर अच्छे कारण हैं - आम तौर पर बोलना, आगे बढ़ने के कई अलग-अलग तरीके हैं, और हम यह जाने बिना प्रगति नहीं कर सकते कि कौन सा लेना है। (यह संभव होगा, संभावित रूप से, कोड को दोबारा करने के लिए ताकि इस आवश्यकता को "लंबित दायित्व" के रूप में पंजीकृत किया जा सके, लेकिन ऐसा करना जटिल है।)

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

https://github.com/rust-lang/rust/issues/36011
https://github.com/rust-lang/rust/issues/36038
https://github.com/rust-lang/rust/issues/35940

लंबित मुद्दों की सूची में जोड़ने के लिए कुछ बग हैं।

@canndrew वे कुछ हद तक https://github.com/rust-lang/rust/issues/12609 के समान दिखते हैं

लड़का, यह एक पुराना बग है! लेकिन हाँ, मैं कहूंगा कि मेरा # 36038 उसी का एक धोखा है (मैंने सोचा कि मैंने इसे पहले कहीं देखा होगा)। मुझे नहीं लगता कि ! को वास्तव में प्राइम टाइम के लिए माना जा सकता है जब तक कि यह तय न हो जाए।

क्या पैटर्न मिलान की थकावट को प्रभावित करने के लिए ! योजना बनाई गई है? वर्तमान, संभवतः-गलत व्यवहार का उदाहरण:

#![feature(never_type)]

fn main() {
    let result: Result<_, !> = Ok(1);
    match result {
//        ^^^^^^ pattern `Err(_)` not covered
        Ok(i) => println!("{}", i),
    }
}

@tikue हाँ, यह ऊपर सूचीबद्ध बगों में से एक है।

@lफेयरी वूप्स, इसे नहीं देखा क्योंकि यह शीर्ष पर स्थित चेकबॉक्स में सूचीबद्ध नहीं था। धन्यवाद!

क्या From<!> for T और Add<T> for ! ( ! आउटपुट प्रकार के साथ) को लागू करने की कोई योजना है? मुझे पता है कि यह वास्तव में अजीब तरह से विशिष्ट अनुरोध है-- मैं इस पीआर में दोनों का उपयोग करने की कोशिश कर रहा हूं।

From<!> for T निश्चित रूप से। Add<T> for ! शायद libs टीम के निर्णय के लिए तैयार है, लेकिन मुझे व्यक्तिगत रूप से लगता है कि ! को प्रत्येक विशेषता को लागू करना चाहिए जिसके लिए तार्किक, विहित कार्यान्वयन है।

@canndrew धन्यवाद! मुझे स्कैला के Nothing विशेषता के लिए उपयोग किया जाता है जो हर प्रकार का उप प्रकार है, और इस प्रकार कहीं भी एक मूल्य दिखाई दे सकता है। हालांकि, मैं निश्चित रूप से उन प्रभावों को समझने की इच्छा के साथ सहानुभूति रखता हूं जो impl All for ! या इसी तरह के जंग के प्रकार प्रणाली पर होंगे, विशेष रूप से नकारात्मक विशेषता सीमाओं और इसी तरह के विषय में।

प्रति https://github.com/rust-lang/rfcs/issues/1723#issuecomment -241595070 From<!> for T में सुसंगतता के मुद्दे हैं।

आह ठीक है, हाँ। हमें इसके बारे में कुछ करने की जरूरत है।

यह अच्छा होगा यदि विशेषता संकेत स्पष्ट रूप से बता सकें कि वे अन्य विशेषता निहितार्थों से अधिक हैं। कुछ इस तरह:

impl<T> From<T> for T
    overridden_by<T> From<!> for T
{ ... }

impl<T> From<!> for T { ... }

क्या यह विशेषज्ञता के दायरे में नहीं आता? संपादित करें: मेरा मानना ​​​​है कि यह जाली का नियम है।

क्या निर्जन प्रकारों के लिए यथासंभव विशेष सहायता से बचने के लिए यह एक व्यवहार्य विकल्प है?

ये सभी match (res: Res<A, !>) { Ok(a) /* No Err */ } , Result लिए विशेष तरीके बहुत ही काल्पनिक लगते हैं, जैसे सुविधाओं के लिए सुविधाएँ, और प्रयास और जटिलता के लायक नहीं लगते हैं।
मैं समझता हूं कि ! एक @canndrew की पालतू विशेषता है और वह इसे और विकसित करना चाहता है, लेकिन हो सकता है कि शुरुआत से ही यह गलत दिशा हो और #12609 कोई बग भी नहीं है?

@petrochenkov # 12609 नेवर टाइप के लिए कोई विशेष विशेषता नहीं है। कुछ स्पष्ट रूप से पहुंच योग्य कोड का पता लगाने के लिए यह सिर्फ एक बग फिक्स है।

@petrochenkov ! भूल जाओ और बस एनम को देखो।

अगर मेरे पास दो प्रकारों के साथ एक एनम है तो मैं उस पर दो मामलों से मेल खा सकता हूं:

enum Foo {
    Flim,
    Flam,
}

let foo: Foo = ...;
match foo {
    Foo::Flim => ...,
    Foo::Flam => ...,
}

यह किसी भी n के लिए काम करता है, सिर्फ दो के लिए नहीं। इसलिए यदि मेरे पास शून्य वेरिएंट वाला एनम है तो मैं उस पर शून्य मामलों के साथ मेल कर सकता हूं।

enum Void {
}

let void: Void = ...;
match void {
}

अब तक सब ठीक है। लेकिन देखो क्या होता है हम नेस्टेड पैटर्न पर मिलान करने का प्रयास करते हैं। यहां Result अंदर दो-संस्करण वाले एनम पर मिलान किया जा रहा है।

enum Foo {
    Flim,
    Flam,
}

let result_foo: Result<T, Foo> = ...;
match result_foo {
    Ok(t) => ...,
    Err(Flim) => ...,
    Err(Flam) => ...,
}

हम बाहरी पैटर्न के अंदर आंतरिक पैटर्न का विस्तार कर सकते हैं। दो Foo प्रकार हैं, इसलिए Err लिए दो मामले हैं। हमें Result और Foo पर मिलान करने के लिए अलग-अलग मिलान विवरणों की आवश्यकता नहीं है। यह किसी भी प्रकार के वेरिएंट के साथ काम करता है... _सिवाय शून्य_।

enum Void {
}

let result_void: Result<T, Void> = ...;
match result_void {
    Ok(t) => ...,
    // ERROR!
}

यह काम क्यों नहीं करना चाहिए? मैं इसे निर्जन प्रकारों के लिए "विशेष समर्थन" जोड़ने को ठीक नहीं कहूंगा, मैं इसे एक असंगति को ठीक करना कहूंगा।

@petrochenkov शायद आप जो कह रहे थे उसे गलत समझा। #12609 सूत्र में दो प्रश्नों पर चर्चा की गई है:

(0) क्या इस कोड को संकलित करने की अनुमति दी जानी चाहिए?

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
}

(1) क्या इस कोड को संकलित करने की अनुमति दी जानी चाहिए?

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
    Err(_) => ...,
}

जैसा कि वर्तमान में लागू किया गया है, उत्तर क्रमशः "नहीं" और "हां" हैं। #12609 (1) के बारे में विशेष रूप से मुद्दे में ही बात करता है लेकिन जब मैंने जवाब दिया तो मैं (0) के बारे में सोच रहा था। जहां तक ​​उत्तर _ should_ होना चाहिए, मुझे लगता है कि (0) निश्चित रूप से "हां" होना चाहिए, लेकिन (1) के लिए मुझे भी यकीन नहीं है।

@canndrew
निर्जन प्रकारों की परवाह किए बिना (1), यानी अगम्य पैटर्न, एक लिंट और एक कठिन त्रुटि बनाना उचित हो सकता है, RFC 1445 में इसके अधिक उदाहरण हैं कि यह क्यों उपयोगी हो सकता है।

के संबंध में (0) मैं आपके स्पष्टीकरण से कमोबेश आश्वस्त हूं। मुझे पूरी तरह से खुशी होगी अगर यह योजना संकलक में पैटर्न की जाँच के कार्यान्वयन पर स्वाभाविक रूप से निहित है और जोड़ने की तुलना में अधिक विशेष कोड को हटा देता है।

वैसे, मैंने यहां (0) को आजमाने और ठीक करने के लिए एक पीआर किया है: https://github.com/rust-lang/rust/pull/36476

मुझे पूरी तरह से खुशी होगी अगर यह योजना संकलक में पैटर्न की जाँच के कार्यान्वयन पर स्वाभाविक रूप से निहित है और जोड़ने की तुलना में अधिक विशेष कोड को हटा देता है।

ऐसा नहीं है, अजीब तरह से। लेकिन यह संभवत: जिस तरह से मैंने इसे मौजूदा कोड में हैक किया है, उसके बजाय यह एक शानदार तरीका नहीं है।

मुझे लगता है कि मैक्रोज़ के लिए यह उपयोगी है (1) एक कठिन त्रुटि नहीं है।

मुझे लगता है कि (1) को डिफ़ॉल्ट रूप से संकलित करना चाहिए, लेकिन उसी लिंट से यहां चेतावनी दें:

fn a() -> u32 {
    return 4;
    5
}

warning: unreachable expression, #[warn(unreachable_code)] on by default

जबकि हम इस पर हैं, क्या ! के सामने कुछ पैटर्न को अकाट्य बनाने का कोई मतलब है?

let res: Result<u32, !> = ...;
let Ok(value) = res;

मैं मानता हूं कि गैर-विस्तृत मिलान एक त्रुटि है, लेकिन पहुंच योग्य नहीं है यानी अनावश्यक पैटर्न केवल एक चेतावनी समझ में आता है।

मेरे पास कुछ पीआर सड़ांध इकट्ठा करने के लिए कुछ समय के लिए बैठे हैं। क्या इनकी समीक्षा करने में सहायता के लिए मैं कुछ कर सकता हूं? शायद उन पर कुछ चर्चा होनी चाहिए। मैं #36476, #36449 और #36489 की बात कर रहा हूँ।

मैं भिन्न प्रकार (या प्रकार सिद्धांत में "नीचे" प्रकार) सोचने के विचार के खिलाफ खाली enum प्रकार (या प्रकार सिद्धांत में "शून्य" प्रकार) के समान है। वे अलग-अलग जीव हैं, हालांकि दोनों का कोई मूल्य या उदाहरण नहीं हो सकता है।

मेरी राय में, एक निचला प्रकार केवल किसी भी संदर्भ में प्रकट हो सकता है जो रिटर्न प्रकार का प्रतिनिधित्व करता है। उदाहरण के लिए,

fn(A,B)->!
fn(A,fn(B,C)->!)->!

लेकिन आपको नहीं कहना चाहिए

let g:! = panic!("whatever");

या

fn(x:!) -> !{
     x
}

या और भी

type ID=fn(!)->!;

चूंकि किसी भी चर का प्रकार ! नहीं होना चाहिए, और इसलिए किसी भी इनपुट चर का प्रकार ! नहीं होना चाहिए।

खाली enum इस मामले में अलग है, आप कह सकते हैं

enum Empty {}

impl Empty {
    fn new() -> Empty {
         panic!("empty");
    }
}

फिर

 match Empty::new() {}

कहने का तात्पर्य यह है कि, ! और Empty बीच एक मूलभूत अंतर है: आप ! टाइप करने के लिए किसी भी चर की घोषणा नहीं कर सकते, लेकिन Empty लिए ऐसा कर सकते हैं .

@earthengine दो प्रकार के निर्जन प्रकारों के बीच (मेरी नज़र में पूरी तरह से कृत्रिम) अंतर को पेश करने का क्या फायदा है?

इस तरह के अंतर के न होने के कई कारण सामने आए हैं - उदाहरण के लिए, Result<!, E> लिखने में सक्षम होने के कारण, यह अलग-अलग कार्यों के साथ अच्छी तरह से बातचीत करता है, जबकि अभी भी Result पर मोनैडिक संचालन का उपयोग करने में सक्षम है। map और map_err ।

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

कहने का तात्पर्य यह है कि, ! और Empty बीच एक मूलभूत अंतर है: आप ! टाइप करने के लिए किसी भी वेरिएबल की घोषणा नहीं कर सकते, लेकिन Empty लिए ऐसा कर सकते हैं .

यही RFC ठीक कर रहा है। ! वास्तव में एक "प्रकार" नहीं है यदि आप इसे एक प्रकार की तरह उपयोग नहीं कर सकते हैं।

@ राल्फजंग
वे अवधारणाएं रैखिक तर्क से हैं https://en.wikipedia.org/wiki/Linear_logic

जैसा कि इस पोस्ट के पिछले पाठ में कुछ गलतियाँ हैं, मैंने उन्हें हटा दिया। एक बार जब मैं इसे सही कर लूंगा तो इसे अपडेट कर दूंगा।

top एक मूल्य है जिसका उपयोग किसी भी संभावित तरीके से किया जा सकता है

सबटाइपिंग में इसका क्या अर्थ है? कि यह किसी भी प्रकार का हो सकता है? क्योंकि वह तब bottom ।

@eddyb मैंने कुछ गलतियाँ की हैं, कृपया मेरे नए अपडेट की प्रतीक्षा करें।

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

एफएफएस दोस्तों

@canndrew अर्घ, मुझे इसके लिए खेद है। =(मैं आज भी आपके पीआर को r+' करने की योजना बना रहा था...

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

यह देखते हुए कि अपवाद टाइप सिस्टम में एक तार्किक और आवश्यक छेद हैं, मैं सोच रहा था कि क्या किसी ने उन्हें औपचारिक रूप से संभालने की दिशा में आगे बढ़ने के लिए गंभीर विचार दिए हैं!

एक उदाहरण और संदर्भ बिंदु के रूप में https://is.gd/4EC1Dk का उपयोग करना, क्या होगा यदि हम उससे आगे निकल गए, और।

1) किसी भी फ़ंक्शन का इलाज करें जो घबरा सकता है लेकिन कोई त्रुटि या परिणाम नहीं लौटाता है, इसका प्रकार हस्ताक्षर -> Foo से -> Result<Foo,!> 2) any परिणाम में स्पष्ट रूप से बदल जाता हैtypes would have their Error types implicitly be converted to एनम AnonMyErrWrapper { डाई (!), एरर} ```
3) चूंकि ! शून्य आकार का विज्ञापन रहने योग्य नहीं है, प्रकारों के बीच रूपांतरण के लिए शून्य लागत होगी, और इसे पीछे की ओर संगत बनाने के लिए अंतर्निहित रूपांतरण जोड़ा जा सकता है।

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

मुझे एहसास है कि यह ... एक समुदाय के दृष्टिकोण से गैर-तुच्छ होगा, यदि तकनीकी रूप से नहीं। :)

साथ ही, यह संभवत: संभावित भावी प्रभाव प्रणाली के साथ ओवरलैप होता है।

@tupshin कम से कम जिमनास्टिक का एक बहुत बिना एक तोड़ने परिवर्तन है कि,। यदि आप स्पष्टता चाहते हैं तो मैं अनइंडिंग को अक्षम करने और मैन्युअल रूप से "परिणाम" का उपयोग करने की सलाह देता हूं। [और बीटीडब्ल्यू, यह मुद्दा वास्तव में ऐसी चीज लाने की जगह नहीं है --- ! का डिज़ाइन ऐसा कुछ नहीं है जिसे आप प्रश्न में बुला रहे हैं, इसलिए यह पूरी तरह से भविष्य का काम है।]

मुझे एहसास है कि इसे तोड़ना कितना महत्वपूर्ण होगा, कम से कम महत्वपूर्ण जिमनास्टिक के बिना, और इसके बारे में उचित बिंदु पूरी तरह से भविष्य का काम होगा। और हाँ, जो योजना बनाई गई है उससे मैं काफी खुश हूँ! जहाँ तक, जहाँ तक जाता है। :)

@nikomatsakis लंबित मुद्दों के संबंध में, इन दोनों पर

• # 35162 से कोड सफाई, expr_ty को कॉल करने के बजाय रिटर्न स्थिति के माध्यम से टाइपेक को थ्रेड प्रकारों में थोड़ा सा पुन: व्यवस्थित करें
• माचिस में निर्जन प्रकार के उपचार का समाधान

मैं इस पर एक और दरार शुरू करने जा रहा हूँ:

• () पर भरोसा करने वाले लोगों के लिए चेतावनियों को कैसे लागू करें: ट्रेट फॉलबैक जहां भविष्य में वह व्यवहार बदल सकता है?

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

@canndrew

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

ठीक है अच्छा है!

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

मेरा मतलब है कि मैं TyTuple एक बूल जोड़ रहा हूँ

TyTuple(&'tcx Slice<Ty<'tcx>>, bool),

जो इंगित करता है कि यदि हम इस पर कुछ लक्षणों का चयन करने का प्रयास करते हैं तो हमें इस (इकाई) टपल पर चेतावनी देनी चाहिए। यह एक और TyDefaultedUnit जोड़ने के मेरे मूल दृष्टिकोण से अधिक सुरक्षित है।

उम्मीद है कि हमें केवल एक चेतावनी चक्र के लिए उस बूल को इधर-उधर रखने की जरूरत है।

uninitialized / transmute / MaybeUninitialized मुद्दे के संबंध में मुझे लगता है कि कार्रवाई का एक समझदार तरीका होगा:

• जोड़े MaybeUninitialized मानक पुस्तकालय के लिए, के तहत mem
• uninitialized पर एक चेक जोड़ें कि यह किस प्रकार का है, जिसे आबाद माना जाता है। चेतावनी दें अन्यथा एक नोट के साथ यह कहते हुए कि यह भविष्य में एक कठिन त्रुटि होगी। इसके बजाय MaybeUninitialized उपयोग करने का सुझाव दें।
• transmute पर एक चेक जोड़ें कि यह "से" प्रकार का है, केवल निर्जन है यदि यह "से" प्रकार भी है। इसी तरह एक चेतावनी उठाएँ जो एक कठिन त्रुटि बन जाएगी।

विचार?

थकावट में हाल के परिवर्तनों पर यह धागा देखें:

• https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602

&! के शब्दार्थ के बारे में कुछ असहमति प्रतीत होती है। #39151 के बाद, never_type फीचर गेट सक्षम होने के साथ इसे मैचों में निर्जन माना जाता है।

यदि ! लिए स्वचालित विशेषता का अर्थ नहीं होगा, तो कम से कम std से उपयुक्त लक्षणों को लागू करना बहुत मददगार होगा। void::Void एक बड़ी सीमा यह है कि यह std बाहर रहता है और इसका मतलब है कि कंबल impl<T> From<Void> for T असंभव है और यह त्रुटि प्रबंधन को सीमित करता है।

मुझे लगता है कि कम से कम From<!> को सभी प्रकार के लिए लागू किया जाना चाहिए और Error , Display और Debug को ! लिए लागू किया जाना चाहिए।

मुझे लगता है कि कम से कम From<!> सभी प्रकार के लिए लागू किया जाना चाहिए

यह दुर्भाग्य से From<T> for T impl के साथ विरोध करता है।

यह दुर्भाग्य से From<T> for T impl के साथ विरोध करता है।

कम से कम जब तक जाली इम्प्लांट स्पेशलाइजेशन लागू नहीं किया जाता है।

अच्छे अंक। मुझे उम्मीद है कि एक दिन मैं इसे पूरा होते हुए देखूंगा।

क्या [T; 0] एक [!; 0] &[T] उप-प्रकार और &[!] ? यह मेरे लिए सहज लगता है कि उत्तर "हां" होना चाहिए, लेकिन वर्तमान कार्यान्वयन अन्यथा सोचता है।

[!; 0] बसा हुआ है और इसलिए &[!] इसलिए मैं नहीं कहूंगा। इसके अलावा, हम इस बार सबटाइपिंग का उपयोग नहीं कर रहे हैं।

दोनों [!; 0] और &[!] निर्जन नहीं होने चाहिए, दोनों प्रकार के मान [] (या &[] ) को स्वीकार कर सकते हैं।

किसी ने नहीं कहा कि वे निर्जन हैं या रहने चाहिए।

let _: u32 = unsafe { mem::transmute(return) };
सिद्धांत रूप में यह ठीक हो सकता है, लेकिन संकलक शिकायत करता है "0 बिट्स और 32 बिट्स के बीच संचारण"।

हालांकि ! -> () को ट्रांसमिट करने की अनुमति है। मेरे पास इसे इंगित करने का कोई विशेष कारण नहीं है; यह एक असंगति है, लेकिन मैं इसके साथ एक व्यावहारिक या सैद्धांतिक समस्या के बारे में नहीं सोच सकता।

मैं सबटाइपिंग की अपेक्षा नहीं करूंगा और संकलक में सभी प्रकार के तर्क को जटिल बनाने से बचने के आधार पर इसका विरोध करूंगा। मैं उप-टाइपिंग नहीं चाहता जो मूल रूप से क्षेत्रों या क्षेत्र बाध्यकारी से संबंधित नहीं है।

क्या Fn , FnMut और FnOnce को ! के लिए इस तरह कार्यान्वित करना संभव है कि यह सभी इनपुट और आउटपुट प्रकारों पर सामान्य हो?

मेरे मामले में मेरे पास एक सामान्य निर्माता है जो एक कार्य कर सकता है, जिसे निर्माण करते समय लागू किया जाएगा:

struct Builder<F: FnOnce(Input) -> Output> {
    func: Option<F>,
}

के रूप में func एक है Option , एक निर्माता का उपयोग कर None के प्रकार के अनुमान नहीं लगा सकता F । इसलिए fn new कार्यान्वयन को बैंग का उपयोग करना चाहिए:

impl Builder<!> {
    pub fn new() -> Builder<!> {
        Builder {
            func: None,
        }
    }
}

बिल्डर का func फ़ंक्शन कुछ इस तरह दिखना चाहिए जिसे Builder<!> और Builder<F> दोनों पर लागू किया जा सके:

impl<F: FnOnce(Input) -> Output> Builder<F> {
    pub fn func<F2: FnOnce(Input) -> Output>(self, func: F) -> Builder<F2> {
        Builder {
            func: func,
        }
    }
}

अब समस्या: वर्तमान में Fn* लक्षण ! लिए लागू नहीं किए गए हैं। इसके अतिरिक्त, आपके पास लक्षणों के लिए एक सामान्य संबद्ध प्रकार नहीं हो सकता है (उदाहरण के लिए Output में Fn )। तो क्या Fn* विशेषता परिवार को ! के लिए इस तरह कार्यान्वित करना संभव है कि यह सभी इनपुट और आउटपुट प्रकारों पर सामान्य है?

यह विरोधाभासी लगता है। क्या <! as Fn>::Output को एक ही प्रकार से हल करने की आवश्यकता नहीं है?

<! as Fn>::Output ! , है ना?

सिद्धांत रूप में <! as Fn>::Output होना चाहिए ! , लेकिन वर्तमान प्रकार का चेकर चाहता है कि संबंधित प्रकार बिल्कुल मेल खाएं: https://is.gd/4Mkxfm

@SimonSapin इसे एक ही प्रकार से हल करने की आवश्यकता है, इसलिए मैं अपना प्रश्न उठाता हूं। भाषा की दृष्टि से यह पूरी तरह से सही व्यवहार है। लेकिन पुस्तकालय के दृष्टिकोण से सामान्य कार्यों के संदर्भ में ! का उपयोग बहुत सीमित होगा यदि वर्तमान व्यवहार रखा जाता है।

निम्नलिखित कोड चाहिए

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    #[allow(unreachable_code)]
    *with_print(10,&return)
}

10 प्रिंट करता है? अभी यह कुछ भी नहीं छापता है। या कोई अन्य वर्कअराउंड जो प्रिंट होने तक return देरी करेगा?

मेरा मतलब है, जैसा कि मैंने पहले कहा, वास्तव में दो अलग-अलग प्रकार के ! प्रकार हैं: एक आलसी है और एक उत्सुक है। सामान्य संकेतन एक उत्सुक व्यक्ति को दर्शाता है, लेकिन कभी-कभी हमें आलसी की आवश्यकता हो सकती है।

जैसा कि @RalfJung पिछले संस्करण में रुचि &return का उपयोग करता है, मैंने कोड को फिर से समायोजित किया। और फिर, मेरा कहना है कि हमें बाद में return में देरी करने में सक्षम होना चाहिए। हम यहां क्लोजर का उपयोग कर सकते हैं लेकिन मैं केवल return उपयोग कर सकता हूं, न कि break या continue आदि का।

उदाहरण के लिए, यह अच्छा होगा यदि हम लिख सकें

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    for i in 1..10 {
        if i==5 { with_print(i, /* delay */break) }
        with_print(i, i);
    }
}

ब्रेक के साथ 5 मुद्रित होने तक देरी हुई।

@earthengine नहीं-- जो निश्चित रूप से कुछ भी प्रिंट नहीं करना चाहिए। ! निर्जन है, जिसका अर्थ है कि ! प्रकार का कोई भी मान नहीं बनाया जा सकता है। इसलिए यदि आपके पास ! प्रकार के मान का संदर्भ है, तो आप एक मृत कोड ब्लॉक के अंदर हैं।

कारण यह है कि return का प्रकार ! है क्योंकि यह विचलन करता है। कोड जो return अभिव्यक्ति के परिणाम का उपयोग करता है उसे कभी भी निष्पादित नहीं किया जा सकता क्योंकि return कभी भी "समाप्त" नहीं होता है।

o मुझे नहीं पता था कि आप &return लिख सकते हैं। इसका कोई मतलब नहीं है, आपको return का पता लेने की अनुमति क्यों दी जानी चाहिए?^^

लेकिन, वैसे भी, @earthengine आपके कोड में, तर्कों का मूल्यांकन quit_with_print से पहले किया जाता है। दूसरे तर्क का मूल्यांकन return चलाता है, जो कार्यक्रम को समाप्त करता है। यह ऐसा कुछ लिखने जैसा है जैसे foo({ return; 2 }) -- foo कभी निष्पादित नहीं किया जाता है।

@RalfJung return ! प्रकार की अभिव्यक्ति है, जैसे break या continue । इसका एक प्रकार है, लेकिन इसका प्रकार निर्जन है।

! को क्रियान्वित किया गया है और अब एक वर्ष से रात्रि में काम कर रहा है। मैं जानना चाहता हूं कि इसे स्थिरीकरण की ओर ले जाने के लिए क्या करने की आवश्यकता है।

एक बात जिसका समाधान नहीं हुआ है, वह यह है कि उन आंतरिक तत्वों के बारे में क्या किया जाए जो ! (यानी uninitialized , ptr::read और transmute ) वापस कर सकते हैं। uninitialized , पिछली बार मैंने सुना था कि एक आम सहमति थी कि इसे MaybeUninit प्रकार और संभावित भविष्य &in , &out , &uninit पक्ष में हटा दिया जाना चाहिए। पहले का uninitialized पदावनत करने का प्रस्ताव रखा है जो एक नया Inhabited विशेषता लागू नहीं करते हैं। शायद उस RFC को खत्म कर दिया जाना चाहिए और "बहिष्कृत uninitialized " और " MaybeUninit " RFCs से बदल दिया जाना चाहिए?

ptr::read , मुझे लगता है कि इसे यूबी के रूप में छोड़ना ठीक है। जब कोई ptr::read पर कॉल करता है तो वे दावा करते हैं कि जो डेटा वे पढ़ रहे हैं वह मान्य है, और ! के मामले में यह निश्चित रूप से नहीं है। हो सकता है कि किसी के पास इस पर अधिक बारीक राय हो?

transmute को ठीक करना आसान है - बस इसे एक निर्जन प्रकार (आईसीईइंग के बजाय जैसा कि वर्तमान में करता है) में ट्रांसमिट करने में त्रुटि करें। इसे ठीक करने के लिए एक पीआर था लेकिन इसे इस कारण से बंद कर दिया गया था कि हमें अभी भी एक बेहतर विचार की आवश्यकता है कि कैसे अप्रारंभीकृत डेटा का इलाज किया जाए।

तो इस समय हम इनके साथ कहाँ हैं? (/cc @nikomatsakis)? क्या हम uninitialized को पदावनत करने और MaybeUninit प्रकार जोड़ने के साथ आगे बढ़ने के लिए तैयार होंगे? अगर हम ! साथ कॉल करने पर इन आंतरिक चीजों को आतंकित करते हैं, तो क्या यह एक उपयुक्त स्टॉप-गैप उपाय होगा जो हमें ! को स्थिर करने की अनुमति देगा?

सूचीबद्ध लंबित मुद्दे भी हैं:

! लिए हमें कौन से गुण लागू करने चाहिए? प्रारंभिक पीआर #35162 में Ord और कुछ अन्य शामिल हैं। यह शायद एक टी-लिब्स मुद्दा है, इसलिए मैं उस टैग को इस मुद्दे में जोड़ रहा हूं।

वर्तमान में काफी बुनियादी चयन है: PartialEq , Eq , PartialOrd , Ord , Debug , Display , Error । इसके अलावा Clone , जिसे निश्चित रूप से उस सूची में जोड़ा जाना चाहिए, मैं किसी अन्य को नहीं देख सकता जो बेहद महत्वपूर्ण हैं। क्या हमें इस पर स्थिरीकरण को रोकने की जरूरत है? अगर हम फिट दिखते हैं तो हम बाद में और अधिक इम्प्लांट जोड़ सकते हैं।

(): Trait फ़ॉलबैक पर भरोसा करने वाले लोगों के लिए चेतावनियों को कैसे कार्यान्वित करें जहां भविष्य में वह व्यवहार बदल सकता है?

resolve_trait_on_defaulted_unit चेतावनी लागू है और पहले से ही स्थिर है।

जबरदस्ती में ! लिए वांछित शब्दार्थ (#40800)
किस प्रकार के वेरिएबल को ! (#40801) पर वापस आना चाहिए

ये असली अवरोधकों की तरह लगते हैं। @nikomatsakis : क्या आपके पास इनके बारे में क्या करना है इसके बारे में कोई ठोस विचार है जो अभी लागू होने की प्रतीक्षा कर रहे हैं?

क्या यह ! लिए Sync और Send को भी लागू करने के लिए समझ में आता है? ऐसे कई मामले हैं जहां त्रुटि प्रकारों में Sync और/या Send सीमाएं हैं, जहां ! को "असफल नहीं हो सकता" के रूप में उपयोग करना उपयोगी होगा।

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

@Kixunil यहां https://doc.rust-lang.org/beta/std/intrinsics/fn.unreachable.html का उपयोग करना अधिक स्पष्ट नहीं होगा?

@ राल्फजंग यह होगा, लेकिन यह अस्थिर है। मुझे याद दिलाता है कि निर्जन प्रकारों में ट्रांसमिट करने से मना करना एक महत्वपूर्ण बदलाव होगा।

@jsgf क्षमा करें, हाँ, ! सभी मार्कर लक्षणों ( Send , Sync , Copy , Sized ) को भी दर्शाता है।

@ किक्सुनिल हम्म, यह शर्म की बात है। हालांकि unreachable आंतरिक को स्थिर करना बेहतर होगा।

स्थिरीकरण-अवरोधक नहीं (क्योंकि पूर्ण, शब्दार्थ नहीं), लेकिन ऐसा लगता है कि Result<T, !> एनम लेआउट या मैच कोडजेन में ! निर्जनता का उपयोग नहीं कर रहा है: https://github.com /जंग-लंग/जंग/मुद्दे/43278

यह इतना अस्पष्ट विचार है कि मैं इसे यहां छोड़ने के लिए लगभग दोषी महसूस करता हूं, लेकिन:

क्या चाक संभवतः !: Trait कार्यान्वयन के संबंध में कुछ कठिन सवालों के जवाब देने में मदद कर सकता है?

@ExpHP मुझे ऐसा नहीं लगता। उन लक्षणों के लिए !: Trait स्वतः-कार्यान्वयन करना जिनके पास संबद्ध प्रकार/आधार नहीं हैं और केवल गैर-स्थैतिक विधियों को ध्वनि माना जाता है। यह सिर्फ एक बात है कि हम इसे करना चाहते हैं या नहीं। अन्य लक्षणों के लिए स्वतः-कार्यान्वयन वास्तव में समझ में नहीं आता है क्योंकि संकलक को संबंधित प्रकारों/स्थलों के लिए मनमानी मान डालने की आवश्यकता होगी और अपनी मनमानी स्थिर विधि का आविष्कार करना होगा।

rustc में पहले से ही resolve-trait-on-defaulted-unit एक प्रकार का वृक्ष है। क्या संबंधित आइटम पर सही का निशान लगाया जाना चाहिए?

@canndrew क्या संबद्ध प्रकारों को ! ?

@taralx यह अस्वस्थ नहीं है, लेकिन यह वैध कोड को काम करने से रोकेगा। ध्यान दें कि निम्नलिखित कोड आज संकलित है:

trait Foo {
    type Bar;
    fn make_bar() -> Self::Bar;
}

impl Foo for ! {
    type Bar = (i32, bool);
    fn make_bar() -> Self::Bar { (42, true) }
}

@lफेयरी यह आपकी राय पर निर्भर करता है कि "वैध" कोड क्या है। मेरे लिए, मैं खुशी-खुशी स्वीकार करूंगा कि आपने जो कोड दिया है वह "अमान्य" है, क्योंकि आपको ! से कुछ भी प्राप्त करने में सक्षम नहीं होना चाहिए।

@earthengine मुझे वह बिंदु नहीं दिख रहा है जिसे आप बनाने की कोशिश कर रहे हैं। आप बिना किसी उदाहरण के किसी प्रकार पर स्थिर विधि को कॉल कर सकते हैं। आप ! से "कुछ भी प्राप्त" कर सकते हैं या नहीं, इसका इससे कोई लेना-देना नहीं है।

ऐसा कोई कारण नहीं है कि आप ! प्रकार से कुछ भी प्राप्त करने में सक्षम न हों। आप एक से कुछ भी नहीं मिल सकता है ! हालांकि, जिसके कारण पर गैर स्थिर तरीकों ! प्रोग्रामर पर कोई भी निर्णय के लिए मजबूर कर के बिना प्राप्त किया जा सकता है।

मुझे लगता है कि नियम याद रखने में सबसे आसान किसी भी विशेषता को लागू करना होगा जिसके लिए बिल्कुल 1 वैध कार्यान्वयन है (उन लोगों को छोड़कर जो ! पहले से ही दायरे में अधिक विचलन जोड़ते हैं)।

हम जिस किसी भी चीज़ के साथ जाते हैं वह उसके साथ समान या अधिक रूढ़िवादी होना चाहिए (जो कि कोई भी स्वचालित निहितार्थ भी फिट नहीं बैठता)।

@ Ericson2314 मुझे समझ में नहीं आता कि इसका क्या अर्थ है, क्या आप कुछ उदाहरण दे सकते हैं?

@SimonSapin "नो panic!() या loop { } , लेकिन एक v: ! जो पहले से ही दायरे में है, ठीक है। ऐसे भावों के साथ जिन्हें खारिज कर दिया गया है, कई लक्षणों के लिए केवल एक ही संभावित निहितार्थ होता है ! वह टाइप-चेक। (दूसरों के पास एक अनौपचारिक अनुबंध हो सकता है जो 1 निहितार्थ को छोड़कर सभी को रद्द कर देता है, लेकिन हम उनसे स्वचालित रूप से निपट नहीं सकते हैं।)

// two implementations: constant functions returning true and false.
// And infinitely more with side effects taken into account.
trait Foo { fn() -> bool }

// Exactly one implementation because the body is unreachable no matter what.
trait Bar { fn(Self) -> Self }

गणितीय रूप से बोलते हुए, ! एक "प्रारंभिक तत्व" है, जिसका अर्थ है कि एक प्रकार के हस्ताक्षर के लिए जिसके तर्कों में ! है, वास्तव में एक कार्यान्वयन है, यानी, सभी कार्यान्वयन बराबर हैं - जब बाहर से देखा गया। ऐसा इसलिए है क्योंकि उन सभी को नहीं बुलाया जा सकता है।

वास्तव में इसे स्थिरीकरण से क्या रोक रहा है? क्या यह केवल mem::uninitialized स्थिति है या कुछ और?

@ arielb1 : मुझे लगता है कि यह #40800 और #40801 भी है। क्या आप जानते हैं कि इन पर क्या स्थिति है?

इस पर क्या दस्तावेज़ लिखे गए हैं, या लोग इसके लिए लिखने की योजना बना रहे हैं? एसटीडी डॉक्स (#43529, #43560) में आदिम प्रकार के पृष्ठों में हाल के परिवर्धन के साथ, ! टाइप करें वहाँ एक पेज प्राप्त करें? संदर्भ शायद अपडेट भी होना चाहिए, अगर यह पहले से नहीं है।

क्या यह निर्दिष्ट करने की कोई योजना है कि एएसएम विचलन कर रहा है ताकि हम चीजें लिख सकें?

#[naked]
unsafe fn error() -> !{
  asm!("hlt");
}

टाइप चेकर को खुश करने के लिए loop{} का उपयोग किए बिना?

संपादित करें: हालांकि मुझे लगता है कि core::intrinsics::unreachable का उपयोग बहुत निम्न स्तर के कोड में स्वीकार्य हो सकता है।

@ Eoc33 जब ! एक प्रकार है, तो आप यह कर सकते हैं:

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");
  std::mem::uninitialized()
}

तब तक आप यह कर सकते हैं:

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");

  enum Never {}
  let never: Never = std::mem::uninitialized();
  match never {}
}

@Kixunil ! रात में एक प्रकार है जिसका आपको उपयोग करने की आवश्यकता है asm! । यह आमतौर पर इस प्रकार किया जाता है:

#[naked]
unsafe fn error() -> ! {
    asm!("hlt");
    std::intrinsics::unreachable();
}

@Kixunil इसे std::intrinics::unreachable() का उपयोग करके अधिक आसानी से किया जा सकता है जो वास्तव में निर्दिष्ट करता है कि पहले कोड अलग हो रहा है।

@Kixunil उपरोक्त चर्चा से std::mem::uninitialized ! वापस करने में सक्षम होने के बावजूद परिवर्तन के अधीन प्रतीत होता है? जब तक मैंने इसे गलत नहीं समझा?

उपरोक्त चर्चा से std::mem::uninitialized ! वापस करने में सक्षम होने के बावजूद परिवर्तन के अधीन प्रतीत होता है? जब तक मैंने इसे गलत नहीं समझा?

मुझे लगता है कि uninitialized को अंततः पूरी तरह से हटा दिया जाएगा और, स्टॉप गैप के रूप में, ! साथ उपयोग किए जाने पर रनटाइम पर घबराने के लिए बनाया जाएगा (हालांकि यह इस मामले को प्रभावित नहीं करेगा)।

मुझे यह भी लगता है कि हमें std::intrinsics::unreachable को libcore में कहीं और स्थिर करना होगा और इसे unchecked_unreachable या unreachable! मैक्रो से अलग करने के लिए कुछ नाम देना होगा। मैं इसके लिए एक आरएफसी लिखने का मतलब रहा हूं।

@eddyb आह, हाँ, भूल गए कि asm!() अस्थिर है, इसलिए std::intrinsics::unreachable() भी उपयोग किया जा सकता है।

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

@ Eroc33 मेरी समझ यह है कि कुछ लोग इसे करने का सुझाव देते हैं, लेकिन यह केवल सुझाव है, निश्चित निर्णय नहीं। और मैं इस तरह के सुझाव के खिलाफ खड़ा हूं क्योंकि यह पिछड़ी संगतता को तोड़ देगा, जंग को 2.0 बनने के लिए मजबूर कर देगा। मुझे नहीं लगता कि इसका समर्थन करने में कोई बुराई है। यदि लोग बग के बारे में चिंतित हैं, तो एक प्रकार का वृक्ष अधिक उपयुक्त होगा।

@canndrew आपको क्यों लगता है कि uninitialized को पदावनत कर दिया जाएगा? मैं ऐसी बात पर विश्वास नहीं कर सकता। मुझे यह बेहद उपयोगी लगता है, इसलिए जब तक कोई बहुत अच्छा प्रतिस्थापन मौजूद न हो, मुझे ऐसा करने का कोई कारण नहीं दिखता।

अंत में, मैं दोहराना चाहूंगा कि मैं सहमत हूं कि intrinsics::unreachable() मौजूदा हैक्स से बेहतर है। कहा जा रहा है, मैं उन हैक्स को मना करने या यहां तक ​​​​कि बहिष्कृत करने का विरोध करता हूं जब तक कि पर्याप्त प्रतिस्थापन न हो।

अप्रारंभ के लिए प्रतिस्थापन संघ है { !, T }। आप द्वारा अगम्य हो सकते हैं
ptr::read::<*const !>()ing और इसी तरह के कई अन्य तरीके।

अगस्त 8, 2017 अपराह्न 3:58 पर, "मार्टिन हबोवेटियाक" नोटिफिकेशन @github.com
लिखा था:

@eddyb https://github.com/eddyb आह, हाँ, भूल गया कि asm!() is
अस्थिर, इसलिए std::intrinsics::unreachable() का भी उपयोग किया जा सकता है।

@tbu- https://github.com/tbu- निश्चित रूप से, मैं इसके बजाय एक को बहुत पसंद करता हूं
निर्जन प्रकार का निर्माण। मुद्दा यह है, यह अस्थिर है, इसलिए यदि यह था
किसी भी तरह से कोड की शाखा को पहुंच से बाहर के रूप में चिह्नित करना असंभव है, यह नहीं होगा
केवल मौजूदा कोड को तोड़ें, लेकिन इसे अपरिवर्तनीय भी बनाएं। मुझे ऐसा लगता है
जंग की प्रतिष्ठा को गंभीर रूप से नुकसान पहुंचाएगा (विशेषकर मुख्य डेवलपर्स पर विचार करते हुए
गर्व से इसे स्थिर होने का दावा करते हैं)। मुझे रस्ट से जितना प्यार है, उतनी बात होगी
मुझे यह उपयोगी भाषा होने पर पुनर्विचार करें।

@Eroc33 https://github.com/eroc33 मेरी समझ यह है कि कुछ लोग
इसे करने का सुझाव दें, लेकिन यह केवल सुझाव है, निश्चित निर्णय नहीं। और मैं
इस तरह के सुझाव के खिलाफ खड़े हो जाओ क्योंकि यह पिछड़ी संगतता को तोड़ देगा,
जंग को 2.0 बनने के लिए मजबूर करना। मुझे नहीं लगता कि इसका समर्थन करने में कोई बुराई है।
यदि लोग बग के बारे में चिंतित हैं, तो एक प्रकार का वृक्ष अधिक उपयुक्त होगा।

@canndrew https://github.com/canndrew आपको अप्रारंभीकृत क्यों लगता है?
पदावनत किया जाएगा? मैं ऐसी बात पर विश्वास नहीं कर सकता। मुझे यह बेहद उपयोगी लगता है,
इसलिए जब तक कोई बहुत अच्छा प्रतिस्थापन मौजूद न हो, मुझे इसका कोई कारण नहीं दिखता
ऐसा करने से।

अंत में, मैं दोहराना चाहूंगा कि मैं सहमत हूं कि इंट्रिनिक्स :: अगम्य ()
वर्तमान हैक्स से बेहतर है। कहा जा रहा है, मैं मना करने का विरोध करता हूं या यहां तक ​​कि
पर्याप्त प्रतिस्थापन होने तक उन हैक्स को बहिष्कृत करना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/35121#issuecomment-320948013 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AApc0iEK3vInreO03Bt6L3EAByBHQCv9ks5sWFt3gaJpZM4JYi9D
.

@ नगीसा धन्यवाद! ऐसा लगता है कि इससे तकनीकी स्तर पर समस्या का समाधान हो जाएगा।

क्या इसका एक सबसेट बनाना संभव होगा ताकि ! को रिटर्न प्रकारों में टाइप पैरामीटर के रूप में इस्तेमाल किया जा सके? अभी यदि आपके पास एक स्थिर कार्य है

fn foo() -> ! { ··· }

और ? का उपयोग करना चाहते हैं, आप सामान्य परिवर्तन नहीं कर सकते

fn foo() -> io::Result<!> { ··· }

क्या कांटेदार जबरदस्ती और टाइप पैरामीटर डिफ़ॉल्ट प्रश्न उस मामले को प्रभावित करते हैं?

match , देखें https://public.etherpad-mozilla.org/p/rust-compiler-design-sprint-paris-2017-ucg

40801 पर टिक किया जा सकता है।

! स्थिर करने से पहले हमें #43061 को ठीक करने का प्रयास करना चाहिए।

मुझे कोई भी खुला I-unsound समस्या दिखाई नहीं दे रही थी, जिसमें कभी नहीं_टाइप का उल्लेख किया गया था, इसलिए मैंने इसके लिए एक नया दायर किया: #47563। चीजें मानती हैं कि [!; 0] निर्जन है लेकिन मैं एक साधारण [] साथ एक बना सकता हूं।

@dtolnay ने हेडर जारी करने के लिए जोड़ा

@canndrew आप समय के लिए कैसे हैं? मैं ! उपयोग का एक सबसेट देखना चाहता हूं जो स्थिर हो जाए (जो संपूर्ण है उसके आसपास के नियमों को छोड़कर)। हालाँकि, हम जहाँ हैं, उसका सूत्र खो चुके हैं और मुझे लगता है कि इसे एक चैंपियन की जरूरत है। क्या आपके पास वह व्यक्ति बनने का समय है?

@nikomatsakis मुझे यकीन है कि मुझे इस सामान पर काम करने के लिए कुछ समय मिल सकता है। यद्यपि वास्तव में क्या करने की आवश्यकता है? क्या यह सिर्फ इस मुद्दे पर जुड़ी हुई बग है?

ऐसा लगता है कि @varkor के पास पहले से ही शेष मुद्दों को ठीक करने के लिए

हालांकि एक और बात: क्या हम रन-टाइम पर mem::uninitialized::<!>() आतंकित करना चाहते हैं (यह वर्तमान में यूबी का कारण बनता है)? या क्या हमें इस तरह के बदलावों को अभी के लिए छोड़ देना चाहिए? असुरक्षित कोड दिशानिर्देश सामग्री के साथ क्या हो रहा है, इसके साथ मैं अप-टू-स्पीड नहीं हूं।

मुझे लगता है कि योजना अभी भी https://github.com/rust-lang/rfcs/pull/1892 है , जिसे मैंने अभी देखा है कि आपने लिखा है। :)

@ राल्फजंग क्या विशेष रूप से इसे अवरुद्ध करने में कुछ भी है? मैं आज जो कहते हैं एक जनसंपर्क लिख सकता है MaybeUninit और deprecates uninitialized ।

@canndrew चूंकि कई परियोजनाएं सभी तीन रिलीज चैनलों का समर्थन करना चाहती हैं और uninitialized स्थिर पर उपलब्ध है, स्थिर चैनल पर प्रतिस्थापन उपलब्ध होने के बाद केवल नाइटली पर बहिष्करण चेतावनियां शुरू करना बेहतर होता है। डॉक्टर-टिप्पणियों के माध्यम से नरम बहिष्करण ठीक है।

मैंने ! को स्थिर करने के लिए एक पीआर बनाया है: https://github.com/rust-lang/rust/pull/47630। मुझे नहीं पता कि क्या हम इसे अभी तक मर्ज करने के लिए तैयार हैं। हमें कम से कम यह देखने के लिए इंतजार करना चाहिए कि क्या @varkor के पीआर शेष खुले मुद्दों को ठीक करते हैं।

मुझे यह भी लगता है कि हमें https://github.com/rust-lang/rfcs/pull/1699 पर फिर से जाना चाहिए ताकि लोग ! लिए सुरुचिपूर्ण विशेषता impls लिखना शुरू कर सकें।

@canndrew : हालांकि उस आरएफसी को स्वीकार नहीं किया गया था, यह उल्लेखनीय रूप से https://github.com/rust-lang/rust/issues/20021 में प्रस्ताव के समान दिखता है

https://github.com/rust-lang/rust/issues/36479 को शायद इश्यू हेडर में भी जोड़ा जाना चाहिए।

@varkor यह बहुत समान है। अपने अगम्य कोड कार्य के साथ क्या आपने इस तरह के कोड के साथ कोई समस्या देखी है जिसे अब अगम्य के रूप में चिह्नित किया जा रहा है ?:

impl fmt::Debug for ! {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        *self    // unreachable!
    }
}

क्योंकि इसके लिए उन जैसे किसी प्रकार के प्रस्ताव को स्वीकार करने की काफी आवश्यकता होगी।

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

इसका एक हिस्सा उन मामलों का परीक्षण करने के लिए संकेत होगा जो प्रश्न में व्यवहार का प्रदर्शन करते हैं।

क्या आपको लगता है कि आप ऐसा कुछ बनाने की कोशिश कर सकते हैं? यदि आप किसी प्रकार की "रूपरेखा" के बारे में पसंद करते हैं, तो हम एक साथ थोड़ी बातचीत कर सकते हैं -- या शायद मैं इसे स्केच करने का प्रयास कर सकता हूं।

संबंधित प्रश्न: क्या हमें स्थिर होने से पहले https://github.com/rust-lang/rust/issues/46325 को हल करने का प्रयास करना चाहिए? शायद कोई फर्क नहीं पड़ता।

@nikomatsakis मैं किसी भी चेतावनी की प्रतीक्षा न करने के लिए वोट

@canndrew : मुझे नहीं लगता कि मैंने वास्तव में इस तरह के किसी भी मामले को देखा है, हालांकि मुझे निश्चित रूप से लगता है कि असंभव कार्यान्वयन को छोड़ने में सक्षम होने पर ! स्थिर होने पर बहुत जरूरी होगा।

@nikomatsakis

क्या आपको लगता है कि आप ऐसा कुछ बनाने की कोशिश कर सकते हैं? यदि आप किसी प्रकार की "रूपरेखा" के बारे में पसंद करते हैं, तो हम एक साथ थोड़ी बातचीत कर सकते हैं -- या शायद मैं इसे स्केच करने का प्रयास कर सकता हूं।

मैं कम से कम एक मसौदा लिख ​​सकता था और आप मुझे बता सकते थे कि क्या आपके मन में यही है। मैं इसे अगले दो दिनों में पूरा करने की कोशिश करूंगा।

@nikomatsakis ऐसा कुछ?

सारांश मुद्दा - ! स्थिरीकरण

क्या स्थिर किया जा रहा है

• ! अब एक पूर्ण प्रकार है और अब इसे किसी भी प्रकार की स्थिति (जैसे RFC 1216 ) में उपयोग किया जा सकता है। ! प्रकार किसी भी अन्य प्रकार में ज़बरदस्ती कर सकता है, उदाहरण के लिए https://github.com/rust-lang/rust/tree/master/src/test/run-fail/adjust_never.rs देखें।

• प्रकार निष्कर्ष अब स्वेच्छापूर्ण प्रकार चर लागू हो जाएगी ! के बजाय () । resolve_trait_on_defaulted_unit लिंट को हटा दिया गया है। यह कहां आता है इसका एक उदाहरण यह है कि यदि आपके पास कुछ ऐसा है:

  // We didn't specify the type of `x`. Under some circumstances, type inference
  // will pick a type for us rather than erroring
  let x = Deserialize::deserialize(data);
  

  पुराने नियमों के तहत यह एक () को डिसेरिएलाइज़ करेगा, जबकि नए नियमों के तहत यह एक ! को डिसेरिएलाइज़ करेगा।

• never_type फीचर गेट स्थिर है, हालांकि इसके कुछ व्यवहार अब नए exhaustive_patterns फीचर गेट के पीछे रहते हैं (नीचे देखें)।

क्या स्थिर नहीं हो रहा है

• निर्जन प्रकारों के लिए संपूर्ण पैटर्न-मिलान। उदाहरण के लिए

  let x: Result<u32, !> = ...;
  let Ok(y) = x;
  

  यह कोड अभी भी शिकायत करेगा कि Ok(_) एक खंडन योग्य पैटर्न है। इसे exhaustive_patterns फीचर गेट का उपयोग करके ठीक किया जा सकता है। इस मुद्दे पर प्रगति के लिए RFC 1872 देखें। टेस्टकेस के लिए https://github.com/rust-lang/rust/tree/master/src/test/ui/feature-gate-exhaustive-patterns.rs देखें जो पुष्टि करता है कि यह व्यवहार अभी भी गेटेड है।

क्या हमें स्थिर होने से पहले #46325 को हल करने का प्रयास करना चाहिए?

इस तरह हर ढीले सिरे को साफ करना जितना अच्छा होगा, यह वास्तव में अवरोधक जैसा नहीं लगता।

@canndrew

कुछ इस तरह?

हाँ, धन्यवाद! एक दम बढ़िया।

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

@canndrew

इस तरह हर ढीले सिरे को साफ करना जितना अच्छा होगा, यह वास्तव में अवरोधक जैसा नहीं लगता।

ठीक है, इसका मतलब है कि हम नए कोड को सक्षम करेंगे जो व्यवहार को तुरंत बदलने वाला है (उदाहरण के लिए, let x: ! = ... क्या मुझे लगता है कि कुछ अभिव्यक्तियों के लिए अलग व्यवहार होगा)। अगर हम कर सकते हैं तो हल करना सबसे अच्छा लगता है। हो सकता है कि आपके द्वारा खोले गए पीआर पर आप इसे एक कठिन त्रुटि बना सकते हैं और हम इसे पीआर पर चलने वाले मौजूदा क्रेटर के साथ जोड़ सकते हैं?

@nikomatsakis मैंने कुछ लिंक और उदाहरणों के साथ उस सारांश मुद्दे को फिर से अपडेट किया है। इसके अलावा, खेद है कि मुझे इस तक पहुंचने में थोड़ा समय लगा, मैं पिछले सप्ताह बहुत व्यस्त रहा हूं।

हो सकता है कि आपके द्वारा खोले गए पीआर पर आप इसे एक कठिन त्रुटि बना सकते हैं और हम इसे पीआर पर चलने वाले मौजूदा क्रेटर के साथ जोड़ सकते हैं?

किया हुआ।

@rfcbot fcp मर्ज

मेरा प्रस्ताव है कि हम ! प्रकार -- या उसके कम से कम हिस्से को स्थिर करें, जैसा कि यहां बताया गया है । पीआर यहाँ है ।

एक बिट डेटा जो मैं चाहूंगा वह है क्रेटर रन। मैं https://github.com/rust-lang/rust/pull/47630 को फिर से बेस करने की प्रक्रिया में हूं (चूंकि

टीम के सदस्य @nikomatsakis ने इसे मर्ज करने का प्रस्ताव दिया है। अगला चरण बाकी टैग की गई टीमों द्वारा समीक्षा है:

• [x] @किमुंडी
• [एक्स] @ एलेक्सक्रिचटन
• [ ] @ अटुरॉन
• [एक्स] @ क्रैमर्टज
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [एक्स] @ एनआरसी
• [ ] @pkfelix
• [x] @sfackler
• [x] @ नावों के बिना

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

एक बार जब अधिकांश समीक्षकों ने स्वीकृति दे दी (और कोई आपत्ति नहीं), तो यह अपनी अंतिम टिप्पणी अवधि में प्रवेश करेगा। अगर आपको कोई बड़ा मुद्दा नज़र आता है जिसे इस प्रक्रिया में किसी भी बिंदु पर नहीं उठाया गया है, तो कृपया बोलें!

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए

ओह, कुछ बातें जो मुझे अभी-अभी याद आईं:

• हमें इसे नए युग में ही स्थिर करने के विचार पर विचार करना चाहिए। विशेष रूप से, फ़ॉलबैक नियमों में परिवर्तन बैकवर्ड असंगत हैं - क्रेटर रन हमें फॉलआउट पर किसी प्रकार का निचला बाउंड देगा, लेकिन यह केवल एक निचला बाउंड है। लेकिन हो सकता है कि जब तक आप नए युग में न हों, हम पुराने फॉलबैक नियमों को ही रख सकते हैं।
• दूसरा, मेरा मानना ​​​​है कि यहां योजना का एक हिस्सा यह भी था कि ! लिए एक विशेषता को लागू करना उचित हो, इसके लिए कुछ दिशानिर्देश हों। टीएल; डीआर यह है कि यह ठीक है यदि विशेषता में विधियां पहले ! मूल्य की आपूर्ति के बिना अनुपयोगी हैं - इसलिए Clone को ! लिए लागू करना ठीक है, मुझे लगता है , लेकिन Default को लागू करना नहीं है। एक और तरीका रखो, अगर इम्प्लांट को लागू करने के लिए आपको अंधाधुंध रूप से panic! आवश्यकता होगी, तो यह एक बुरा संकेत है। =)

@nikomatsakis क्या हम एक नए युग में फ़ॉलबैक नियम बदल सकते हैं लेकिन फिर भी 2015 के युग में उपलब्ध प्रकार के रूप में ! ?

@nikomatsakis

हमें इसे नए युग में ही स्थिर करने के विचार पर विचार करना चाहिए।

पिछली बार हमने एक क्रेटर रन किया था (जो बहुत समय पहले था) फॉलबैक नियमों को बदलने से नतीजा काफी कम था। हम उस कोड का भी विरोध कर रहे हैं जो कुछ समय के लिए परिवर्तन से प्रभावित हो सकता है।

दूसरा, मेरा मानना ​​​​है कि यहां योजना का एक हिस्सा यह भी था कि ! लिए एक विशेषता को लागू करना उचित हो, इसके लिए कुछ दिशानिर्देश हों।

! लिए डॉक्स में इसका उल्लेख किया

@SimonSapin

क्या हम एक नए युग में फ़ॉलबैक नियम बदल सकते हैं लेकिन फिर भी बना सकते हैं ! 2015 के युग में उपलब्ध एक प्रकार के रूप में?

हां

@canndrew

पिछली बार हमने एक क्रेटर रन किया था (जो बहुत समय पहले था) फॉलबैक नियमों को बदलने से नतीजा काफी कम था। हम उस कोड का भी विरोध कर रहे हैं जो कुछ समय के लिए परिवर्तन से प्रभावित हो सकता है।

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

टीएल; डीआर यह है कि यह ठीक है यदि विशेषता में विधियां पहले ! मूल्य की आपूर्ति किए बिना अनुपयोगी हैं

यह सिर्फ सामान्य नियम है - जब आप इसे एक समझदार तरीके से कार्यान्वित कर सकते हैं, तो आप एक इम्प्लांट जोड़ते हैं, जहां "इसे एक समझदार तरीके से कार्यान्वित करें" घबराहट को छोड़कर, लेकिन अमान्य डेटा की उपस्थिति में "पूर्व झूठा" यूबी शामिल है।

@ arielb1 हां, लेकिन किसी कारण से लोग इस तरह की चीजों के बारे में ! की उपस्थिति में भ्रमित हो जाते हैं, इसलिए यह स्पष्ट रूप से कॉल करने लायक लगता है।

हो सकता है कि यह एक सुरक्षित विधि fn absurd(x: !) -> ! जो कि पहुंचने योग्य कोड को व्यक्त करने का एक सुरक्षित तरीका होने के लिए प्रलेखित है या तो कहीं libstd में? मुझे लगता है कि उसके लिए एक आरएफसी था ... या कम से कम एक आरएफसी मुद्दा: https://github.com/rust-lang/rfcs/issues/1385

@RalfJung क्या वह absurd फ़ंक्शन केवल identity ? यह उपयोगी क्यों है?

यह unsafe fn unreachable() -> ! आंतरिक जैसा नहीं है जो कोई तर्क नहीं लेता है और बहुत अपरिभाषित-व्यवहार है।

खैर, हाँ, यह ज्यादातर है। मैं "समाप्त नहीं होता" के अर्थ में ! वापसी प्रकार का उपयोग कर रहा था। (सामान्य प्रकार का absurd fn absurd<T>(x: !) -> T , लेकिन यह जंग में भी उपयोगी नहीं लगता है।)

मैं सोच रहा था कि शायद यह " ! की उपस्थिति में लोगों को इस तरह की चीजों के बारे में भ्रमित होने में मदद करेगा - कहीं कुछ दस्तावेज होने पर "पूर्व झूठा" तर्क एक चीज है।

ऐसा लगता है कि मुझे भी गलत मुद्दा मिला है ... मैंने सोचा था कि इस तरह के "एक्स फाल्सो" समारोह के बारे में कहीं चर्चा हुई थी। ऐसा लगता है कि मैं गलत हूँ।

fn absurd<T>(x: !) -> T को match x {} भी लिखा जा सकता है, लेकिन अगर आपने इसे पहले नहीं देखा है तो इसका पता लगाना मुश्किल है। यह कम से कम रस्टडॉक और किताब में इंगित करने लायक है।

एफएन बेतुका(x: !) -> T को मैच x {} भी लिखा जा सकता है, लेकिन अगर आपने इसे पहले नहीं देखा है तो इसका पता लगाना मुश्किल है।

ठीक है, इसलिए मैंने libstd में कहीं एक विधि सुझाई है। हालांकि सुनिश्चित नहीं है कि सबसे अच्छी जगह कहां है।

absurd बारे में अच्छी बात यह है कि आप इसे उच्च-क्रम के कार्यों में पास कर सकते हैं। मुझे यकीन नहीं है कि यह हमेशा जरूरी है कि कैसे! रिट व्यवहार करता है। एकीकरण, यद्यपि।

fn absurd<T>(x: !) -> T को match x {} भी लिखा जा सकता है

इसे केवल x (AFAIK) के रूप में भी लिखा जा सकता है - यदि आपके पास खाली enum तो आपको केवल match enum ।

एक absurd(x: !) -> T फ़ंक्शन उच्च-क्रम वाले फ़ंक्शंस को पास करने के लिए उपयोगी होगा। मुझे इसकी आवश्यकता है (उदाहरण के लिए) वायदा का पीछा करते समय, जिनमें से एक में त्रुटि प्रकार ! और दूसरी त्रुटि प्रकार T । भले ही प्रकार की अभिव्यक्ति ! मजबूर कर सकते हैं T कि इसका मतलब यह नहीं है कि ! और T एकजुट करेंगे, तो कभी कभी आप फिर भी मैन्युअल की जरूरत है प्रकार परिवर्तित करें।

इसी तरह, मुझे लगता है कि Result -जैसे प्रकारों में .infallible() विधि होनी चाहिए जो Result<T, !> को Result<T, E> परिवर्तित करती है।

परिणाम जैसे प्रकारों में एक .infallible() विधि होनी चाहिए जो परिणाम को परिवर्तित करती हैनतीजे पर.

मुझे उम्मीद है कि इस तरह की विधि Result<T, !> -> T टाइप करेगी।

मुझे इस तरह की विधि से परिणाम टाइप करने की उम्मीद होगी-> टी.

क्या यह unwrap जैसा ही नहीं है? Err मामला पहुंच से बाहर होने के बाद से घबराहट को दूर किया जाएगा।

@Amanieu मुद्दा यह है कि शुरू करने के लिए कोई घबराहट नहीं है। मुझे पैनिक लिंट पसंद है, और अगर हम ऑप्टिमाइज़ेशन पर भरोसा करते हैं तो यह ट्रिप हो जाएगा। यहां तक ​​​​कि लिंट के बिना, unwrap का उपयोग करके रिफैक्टर के दौरान एक फ़ुटगन जोड़ता है, कम आतंक एक बार फिर से लाइव कोड बन जाता है।

unwrap पढ़ता है जैसे assert - "रन-टाइम चेक फॉरवर्ड" (आईआईआरसी का नाम बदलने के प्रस्ताव भी थे लेकिन वे बहुत देर से आए ... दुख की बात है)। यदि आप नहीं चाहते हैं और रन-टाइम चेक की आवश्यकता है, तो infallible यह स्पष्ट कर देगा।

:घंटी: उपरोक्त समीक्षा के अनुसार, यह अब अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । घंटी:

@rfcbot FCP रद्द करें

@aturon और @pkfelix ने अपने बॉक्स चेक नहीं किए हैं.

@cramertj प्रस्ताव रद्द कर दिया गया।

@rfcbot fcp मर्ज

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

टीम के सदस्य @cramertj ने इसे मर्ज करने का प्रस्ताव दिया है। अगला चरण बाकी टैग की गई टीमों द्वारा समीक्षा है:

• [एक्स] @ एलेक्सक्रिचटन
• [x] @ एट्यूरॉन
• [एक्स] @ क्रैमर्टज
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [एक्स] @ एनआरसी
• [ ] @pkfelix
• [x] @sfackler
• [x] @ नावों के बिना

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

एक बार जब अधिकांश समीक्षकों ने स्वीकृति दे दी (और कोई आपत्ति नहीं), तो यह अपनी अंतिम टिप्पणी अवधि में प्रवेश करेगा। अगर आपको कोई बड़ा मुद्दा नज़र आता है जिसे इस प्रक्रिया में किसी भी बिंदु पर नहीं उठाया गया है, तो कृपया बोलें!

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए

:घंटी: उपरोक्त समीक्षा के अनुसार, यह अब अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । घंटी:

हमने आज की बैठक में इस पर चर्चा की। मैं इस बात को लेकर फटा हुआ रहता हूं कि फॉलबैक को अभी बदलूं या केवल नए युग में। यहाँ विभिन्न बिंदु हैं।

परिवर्तन का अपेक्षित प्रभाव छोटा है। तो वास्तव में यह किसी भी तरह से ज्यादा फर्क नहीं पड़ता है। आप यहां पूरा विश्लेषण देख सकते हैं , लेकिन सारांश यह है:

और वह सिर्फ दो वास्तविक प्रतिगमन छोड़ देता है: oplog-0.2.0 (वास्तव में यह इसकी निर्भरता bson-0.3.2 है जो टूटा हुआ है) और rspec-1.0.0-beta.4। ये दोनों पुराने फॉलबैक व्यवहार पर भरोसा कर रहे हैं, हालांकि सौभाग्य से वे संकलन समय पर टूट रहे हैं, रन टाइम नहीं। मैं इन क्रेटों को ठीक करने के लिए पीआर जमा करूंगा।

लेकिन यह अभी भी तकनीकी रूप से एक महत्वपूर्ण परिवर्तन है (और एक स्वैच्छिक)। वहाँ कोई विशेष कारण प्रकार चर के लिए वापस आने को बदलने के लिए, सिवाय इसके कि है कि हम है () एक अकेले गरीब विकल्प है और यह बहुत दुर्लभ है कोड उस पर भरोसा करने के लिए के लिए। इसको लेकर हम भी काफी समय से आगाह कर रहे हैं।

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

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

मुझे पता है कि मैं पक्षपाती हूं, लेकिन मैं dyn Trait और catch जैसे सामान की तुलना में फ़ॉलबैक व्यवहार को एक बगफिक्स के रूप में बदल रहा हूं।

इसके अलावा, अगर कोई इस पर कूदना चाहता है और कहता है, "आह हा! जंग पीछे की संगतता को तोड़ देती है! 1.0 हिट होने पर स्थिरता का उनका वादा झूठ था!" तो इस मुद्दे पर बहुत ही विचारशील चर्चा से पता चलता है कि निर्णय हल्के ढंग से नहीं किया गया था, यहां तक ​​​​कि नगण्य व्यावहारिक प्रभाव भी था।

ठीक है, मैं कहता हूँ चलो इसे बदल देते हैं।

एक समझौते के रूप में, मैं उन त्रुटियों के लिए एक उपयोगी नोट देना चाहूंगा जो लोगों को सूचित करती हैं कि व्यवहार बदल गया है - प्रशंसनीय लगता है। विचार कुछ इस तरह होगा:

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

अंतिम टिप्पणी अवधि अब पूरी हो गई है।

क्या शीर्ष पोस्ट में लंबित चेक बॉक्स अभी चेक नहीं किए गए हैं? क्या उस सूची में कुछ पूर्ववत है?

@earthengine मुझे नहीं लगता कि जो दो मैं देख रहा हूं वे विशेष रूप से प्रासंगिक हैं - शीर्ष आइटम के लिए, इम्प्लांट्स के सेट के बारे में, मुझे लगता है कि अब समय के लिए तय किया गया है।

मूल रूप से एक बहुत ही न्यूनतम सेट होना।

@nikomatsakis मैंने अभी यहां सारांश मुद्दा बनाया है: https://github.com/rust-lang/rust/issues/48950

क्या ! एक ऐसा पैटर्न बनाने पर विचार किया गया है जो ! प्रकार के मानों से मेल खाता हो? (मैंने इस मुद्दे और मूल आरएफसी मुद्दे के माध्यम से एक त्वरित grep किया है, लेकिन कुछ भी प्रासंगिक नहीं मिला)।

मुझे यह StreamFuture जैसे प्रकारों के लिए उपयोगी लगेगा ! पैटर्न का उपयोग करके map_err , यदि भविष्य में किसी बिंदु पर त्रुटि प्रकार बदलता है, तो संभावित रूप से कुछ अलग करने के बजाय map_err कॉल संकलन बंद कर देगा।

एक उदाहरण के रूप में दिया गया

let foo: Result<String, (!, String)> = Ok("hello".to_owned());

यह अधिक स्पष्ट लिखने की अनुमति देगा

let bar: Result<String, String> = foo.map_err(|(!, _)| unreachable!());

संभावित त्रुटि-प्रवण के बजाय

let bar: Result<String, String> = foo.map_err(|_| unreachable!());

या थोड़ा कम त्रुटि-प्रवण

let bar: Result<String, String> = foo.map_err(|(e, _)| e);

संपादित करें: https://github.com/rust-lang/rfcs/pull/1872 को फिर से पढ़ना टिप्पणियों में ! पैटर्न को पेश करने का उल्लेख है। यह पूरी तरह से match अभिव्यक्तियों के संदर्भ में है, मुझे यकीन नहीं है कि यह बंद/कार्य तर्कों को सामान्यीकृत करता है या नहीं।

@ निमो157

बनाने का कोई विचार किया गया है ! एक पैटर्न जो के मूल्यों से मेल खाता है! प्रकार?

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

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

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(bar?)
}

यह आज भी विस्तारित होगा (_मैं 100% निश्चित नहीं हूं कि यह सही विस्तार है, लेकिन काफी करीब लगता है_)

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(match Try::into_result(bar) {
        Result::Ok(e) => e,
        Result::Err(e) => return Try::from_err(From::from(e)),
    })
}

लेकिन Result::Err शाखा को चेक नहीं किया जाएगा और आपको आज मिलने वाली the trait bound `std::string::String: std::convert::From<(!, std::string::String)>` is not satisfied त्रुटि नहीं मिलेगी।

मुझे नहीं लगता कि यह आरएफसी 1872 के प्रस्ताव के साथ संगत है, क्योंकि एक स्पष्ट हाथ है जो उथला मैच कर रहा है, यह जरूरी नहीं कि ! मूल्य की वैधता पर निर्भर हो, और संभावित रूप से हो सकता है संबद्ध शाखा को "सुरक्षित रूप से" तब तक चलाएं जब तक कि वह शाखा e.0 बिल्कुल भी उपयोग न करे।

! एक सकारात्मक प्रकार है, जैसे bool , इसलिए कई शाखाओं को अनुमति देने के लिए क्लोजर सिंटैक्स को विस्तारित किए बिना क्लोजर तर्क सूची में उस पर पैटर्न-मिलान करना असंभव है। उदाहरण के लिए हो सकता है कि हम क्लोजर bool -> u32 को (बदसूरत काल्पनिक सिंटैक्स) [~ |false| 23, |true| 45 ~] -> u32 जैसा कुछ लिखने की अनुमति दे सकें, फिर किसी भी खाली प्रकार से u32 को बंद करने के लिए बस [~ ~] -> u32 लिखा जा सकता है

अपने मूल उदाहरण लिखें, आप foo.map_err(|_: (!, _)| unreachable!()) लिख सकते हैं, हालांकि मैं foo.map_err(|(e, _)| e) पसंद करता हूं क्योंकि यह unreachable! का उपयोग करने से बचता है।

! एक सकारात्मक प्रकार है

सकारात्मक प्रकार से आप क्या समझते हैं ?

कई शाखाओं को अनुमति देने के लिए क्लोजर सिंटैक्स को विस्तारित किए बिना क्लोजर तर्क सूची में पैटर्न-मिलान करना असंभव है

तर्क सूचियाँ पहले से ही अकाट्य उप-पैटर्न का समर्थन करती हैं, उदाहरण के लिए

let foo: Result<String, ((), String)> = Ok("hello".to_owned());
let bar: Result<String, String> = foo.map_err(|((), s)| s);

मैं केवल ! पैटर्न को एक अकाट्य पैटर्न के रूप में मानूंगा जो ! प्रकार के सभी 0 मानों से मेल खाता है, जैसा कि () एक अकाट्य पैटर्न है जो सभी 1 मानों से मेल खाता है () प्रकार।

मैं सिर्फ विचार करेंगे! पैटर्न एक अकाट्य पैटर्न के रूप में है जो सभी 0 मानों से मेल खाता है! प्रकार, जैसा कि () एक अकाट्य पैटर्न है जो () प्रकार के सभी 1 मानों से मेल खाता है।

ठीक है, लेकिन 0 != 1.;) ! पर मिलान करने के बाद भी कोई कोड लिखना व्यर्थ है - उदाहरण के लिए यदि तर्क प्रकार (!, i32) , तो |(!, x)| code_goes_here मूर्खतापूर्ण है क्योंकि वह कोड वैसे भी मर चुका है। मैं शायद लिखते थे |(x, _)| match x {} यह बहुत स्पष्ट है कि बनाने के लिए x का एक तत्व है ! । या, ऊपर प्रस्तावित absurd फ़ंक्शन का उपयोग करके, |(x, _)| absurd(x) । या शायद |(x, _)| x.absurd() ?

कोई एक अलग सिंटैक्स की कल्पना कर सकता है जो किसी को कोई कोड @canndrew ने ऊपर लिखा था। match में कितनी भी शाखाएं हैं, इसलिए विशेष रूप से कोई शाखा

बहुत बुरा हम अभी impl<T> From<!> for T नहीं जोड़ सकते। (यह From<T> for T साथ ओवरलैप होता है, जब तक कि कुछ विशेषज्ञता न हो?) हम शायद इसे बाद में नहीं जोड़ सकते। ( ! स्थिर होने के बाद रिलीज चक्र में, कुछ टोकरा From<!> for SomeConcreteType लागू कर सकता है।)

@SimonSapin अच्छा बिंदु! यह कई चीजों के लिए बहुत उपयोगी बिल्डिंग ब्लॉक है, और मैं इसे हमेशा के लिए खोना पसंद नहीं करूंगा। मैं दोनों उदाहरणों को अनुमति देने के लिए एक बार की हैक पर गंभीरता से विचार करता हूं। वे अतिव्यापी मामले में शब्दार्थ से मेल खाते हैं, इसलिए कोई "परिचालन असंगति" नहीं है।

मैं गंभीरता से एकबारगी हैक पर विचार करूंगा

फिर उस हैक को अगले कुछ दिनों में उतरना होगा। (या बीटा के दौरान बैकपोर्ट किया जा सकता है।)

@SimonSapin ऐसी हैक कितनी जल्दी/आसानी से जोड़ी जा सकती है? यह वास्तव में कभी भी From<!> for T प्राप्त करने में सक्षम नहीं होगा।

वैकल्पिक रूप से, हम From<!> for SomeConcreteType को लागू करने के खिलाफ तुरंत चेतावनी दे सकते हैं।

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

दुर्भाग्य से, विशेषज्ञता:

• From::from को default fn बदलने की आवश्यकता होगी, जो कि एसटीडी के बाहर "दृश्यमान" होगा। मुझे नहीं पता कि क्या हम इसे एसटीडी लक्षणों में करना चाहते हैं, जब तक कि विशेषज्ञता अस्थिर है।
• जैसा कि आरएफसी 1210 में स्वीकार किया गया है, विशेष रूप से उस भाषा सुविधा का समर्थन नहीं करता है जिसके बारे में मैं सोच रहा था (दो अतिव्यापी अर्थों को अलग करना जहां न तो चौराहे के लिए तीसरा इम्प्लांट लिखकर दूसरे की तुलना में अधिक विशिष्ट है)।

यहां दो इम्प्लांट बिल्कुल वही काम करते हैं। अगर हम कोहेरेंस चेक को बंद कर देते हैं तो यह निर्धारित करना मुश्किल होगा कि कौन सा इम्प्लांट इस्तेमाल किया जाता है, जो आम तौर पर बेतहाशा अस्वस्थ होता है, लेकिन इस मामले में ठीक है। संकलन में कुछ घबराहट की यात्रा कर सकते हैं जैसे कि एक परिणाम की उम्मीद है लेकिन हम उसके आसपास हैक कर सकते हैं।

दूसरे शब्दों में, मुझे लगता है कि किसी भी विशेषज्ञता को तेज करने की तुलना में यह बहुत आसान है, शुक्र है।

क्या इसे औपचारिक रूप देने के लिए कोई मौजूदा RFC है "यदि इसमें शामिल सभी निहितार्थ अप्राप्य हैं तो मनमाने ढंग से ओवरलैप की अनुमति दें" विचार? विचार करने के लिए एक दिलचस्प दृष्टिकोण की तरह लगता है।

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

केवल समस्या #49593 का उल्लेख करना जो इसका कारण हो सकता है ! बेहतर खोज योग्यता के लिए फिर से अस्थिर होने के लिए।

मुझे आश्चर्य है कि T: From<!> अलावा और कौन से निहितार्थ ! के स्थिर होने के बाद नहीं जोड़े जा सकते ! लिए इम्प्लांट से अलग है, जहां ऐसी कोई जल्दी नहीं है।

इस टिप्पणी से क्रॉस-पोस्टिंग:

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

उस परिवर्तन के परिणामस्वरूप कई प्रतिगमन हुए हैं और मुझे कहना होगा कि मैं इसके साथ पूरी तरह से सहज नहीं हूं:

• @SimonSapin वर्णन करता है कि कैसे कुछ असुरक्षित कोड वापस आ गए और अस्वस्थ हो गए । यह एक अनबाउंड प्रकार के पैरामीटर के कारण था जो वापस गिरकर ! पर आ गया था, लेकिन वास्तव में, मृत कोड नहीं था। यह वर्तमान योजना की ज्ञात विफलता है, यह तब होता है जब आपके पास match foo { P1 => ..., P2 => return } । रिटर्न "फॉल बैक टू ! टाइप वेरिएबल" उत्पन्न करता है जो दूसरे हाथ से एकीकृत हो जाता है। इसे ठीक करना काफी कठिन साबित हुआ है; उदाहरण देखें https://github.com/rust-lang/rust/issues/40801।
• @mitsuhiko ने यह टिप्पणी उठाई

(इस बिंदु पर लैंग-टीम चर्चा के लिए नामांकन।)

बैठक के दौरान, हमने यहां कुछ विकल्पों को पीछे छोड़ दिया - मैं बदलाव करने में अनिच्छुक महसूस कर रहा हूं, ज्यादातर इसलिए कि यह कुछ कोने के मामलों में मौजूदा कोड के शब्दार्थ को बदल देता है, और यह स्पष्ट नहीं है कि नए नियम बेहतर हैं । लेकिन ज्यादातर मुझे लगता है कि हमने फैसला किया कि प्रत्येक डिजाइन के पेशेवरों/विपक्षों को फिर से इकट्ठा करना और इकट्ठा करना बहुत अच्छा होगा ताकि हम एक और पूरी चर्चा कर सकें। मैं उपयोग के मामलों के साथ-साथ नुकसान की एक सूची देखना चाहता हूं। @क्रैमर्टज ने Ok(33) में एक प्रकार है जो Result<i32, !> वापस आ जाता है, त्रुटि के बजाय यह आज करेगा; मुझे लगता है कि वे तो कह रहे थे कि से वापस आने रखने return के रूप में () तरह के एक परिवर्तन के साथ असंगत होगा (हालांकि वे ओर्थोगोनल), और सड़क के नीचे संघर्ष बना सकता है। यह न्यायसंगत है।

Err फीडबैक (#40801) के साथ चुनौती यह है कि वहां भी किनारे के मामले हैं, जैसे:

let mut x = Ok(22);
x = Err(Default::default());

जहां x का प्रकार अंततः अनुमान लगाया जाता है Result<T, !> ।

(? और शायद चेतावनी दी है या त्रुटि) मैं एक अलग योजना मैं कोशिश करें और देखें कि हम यह समझ सकते हैं कि क्या करना पड़ा याद आ रहा है ! , यह काफी कठिन साबित कर दिया है, हालांकि यह लगता है - वापस आने कभी "प्रभावित" लाइव कोड जैसे हम अभ्यास में कई मामलों को लिंट कर सकते हैं (उदाहरण के लिए, वह एक, और शायद @SimonSapin का मामला)।

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

FYI करें, इस सुविधा के कारण 1.26: #49932 . में प्रतिगमन हुआ

(https://github.com/rust-lang/rust/issues/35121#issuecomment-368669041 प्रति लेबल सेट करना।)

क्या ! में जबरदस्ती के बारे में चेकलिस्ट आइटम इस मुद्दे को संदर्भित करने के बजाय https://github.com/rust-lang/rust/issues/50350 पर इंगित किया जाना चाहिए?

अगर मैं इसे जल्द से जल्द स्थिर करना चाहता हूं, तो मेरी ऊर्जा को निर्देशित करने के लिए सबसे अच्छी जगह कहां है?

@remexre मुझे लगता है कि समस्या का सबसे अच्छा विवरण जो स्थिरीकरण को वापस https://github.com/rust-lang/rust/issues/49593 पर है

तो क्या एक उप-प्रकार के रूप में विशेष-केस बॉक्स के लिए एक व्यावहारिक समाधान होगा
डिब्बा? क्या कोई ऑब्जेक्टसेफ लक्षण हैं जिन्हें इस तरह से संभाला नहीं जा सकता है?

सूर्य पर, जुलाई 8, 2018, 8:12 पूर्वाह्न राल्फ जंग नोटिफिकेशन @github.com ने लिखा:

@remexre https://github.com/remexre मुझे लगता है कि इसका सबसे अच्छा विवरण है
समस्या जो पूर्ववत स्थिरीकरण की ओर ले जाती है वह #49593 . पर है
https://github.com/rust-lang/rust/issues/49593

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/35121#issuecomment-403286892 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEAJtcnsEaFmHrrlHhuQeVOkR8Djzt50ks5uEgVLgaJpZM4JYi9D
.

>

धन्यवाद,
नाथन

उस चर्चा को वास्तव में https://github.com/rust-lang/rust/issues/49593 में जाना चाहिए, लेकिन इसका एक महत्वपूर्ण हिस्सा यह है कि Box::<T>::new लिए T: Sized , लेकिन वह new कहा जाता है कि वापसी प्रकार के आधार पर T = Error (एक विशेषता डीएसटी) होने का अनुमान है।

एक विशेष मामले की सुंदरता के अलावा, क्या विशेष-आवरण Box::new लिए कोई समस्या है:

Box::new : T -> Box<U>
where T <: U,
      T: Sized

या

Box::new : T -> Box<U>
where Box<T> <: Box<U>,
      T: Sized

सबसे पहले हमें यह सोचना चाहिए कि ! का आकार क्या होना चाहिए। गणितज्ञ Inf जैसा कुछ प्रस्तावित करेंगे, लेकिन वास्तव में यह usize::MAX , इसलिए हम यह सुनिश्चित कर रहे हैं कि इस प्रकार के लिए स्थान आवंटित करने का कोई भी प्रयास विफल हो जाएगा या कम से कम panic ।

यदि ! Sized तो, हमें Box::new(x as !) को संकलित करने से कोई रोक नहीं सकता है, लेकिन यह मूल रूप से panic! एक और तरीका है, क्योंकि कोई मेमोरी मॉडल वास्तव में नहीं हो सकता है usize::MAX बाइट्स आवंटित करें।

यह मुझे स्पष्ट नहीं लगता है कि ! में अनंत/ usize::MAX आकार बनाम ZST होना चाहिए?

use std::mem::size_of;
enum Void {}
fn main() { println!("{}", size_of::<Void>()); }

वर्तमान में 0 है।

प्रस्तुत पाठ में तर्क समझाया गया था।

bool : दो मान्य मान => लॉग(2)/लॉग(2) = 1 बिट
() : 1 मान्य मान => लॉग (1)/लॉग (2) = 0 बिट
! : 0 मान्य मान => लॉग(0)/लॉग(2) = इंफ बिट्स

जैसा कि कोई प्रासंगिक सिद्धांत में पारंगत नहीं है, मैं log(x)/log(y) फॉर्मूले का पालन करता हुआ देखता हूं, जहां तक ​​​​व्यावहारिक उपयोग की हानि के लिए एक सैद्धांतिक मॉडल की शान का पीछा करना है। (एकेए अपने स्वयं के भले के लिए बहुत चालाक है)

सहज रूप से, ऐसा लगता है कि ! भी शून्य-आकार का होना चाहिए क्योंकि:

• bool : टाइप सिस्टम के अलावा दो मान्य मानों => लॉग (2)/लॉग (2) = 1 बिट के बीच अंतर करने के लिए स्थान की आवश्यकता है
• () : एक वैध मान में अंतर करने के लिए स्थान की आवश्यकता है => प्रकार प्रणाली से परे किसी स्थान की आवश्यकता नहीं है
• ! : कोई मान्य मान भेद करने के लिए स्थान की आवश्यकता नहीं => प्रकार प्रणाली से परे किसी स्थान की आवश्यकता नहीं है

वैसे यह -इनफिनिटी वास्तव में है, जो समझ में आता है, जैसे ! एक क्षेत्र के रूप में एक संरचना में अनिवार्य रूप से संरचना को ! साथ ही (c + -inf = -inf)। इसलिए चूंकि हम उपयोग के साथ काम कर रहे हैं, 0 इसका प्रतिनिधित्व करने के लिए निकटतम मूल्य है। (मुझे लगता है कि rustc में वास्तविक कार्यान्वयन -inf का भी उपयोग करता है)।

सहज रूप से, ऐसा लगता है कि ! भी शून्य-आकार का होना चाहिए

! को आकार की बिल्कुल भी आवश्यकता नहीं है, क्योंकि उस प्रकार के साथ कभी भी कोई मान नहीं बनाया जाएगा। यह एक अप्रासंगिक प्रश्न है।

0 मान्य मान => लॉग(0)/लॉग(2) = इंफ बिट्स

लॉग (0) अपरिभाषित है; यह अनंत नहीं है।

दूसरी ओर, usize::MAX आकार का होना निर्वासन को लागू करने का एक कठिन तरीका है। इस बात से सहमत?

@CryZe @varkor

यह उस अवधारणा के साथ भी फिट बैठता है जिसकी मैं वैधता का कारण जानने की कोशिश कर रहा था, जहां मेरा अंतर्ज्ञान ! को "पूरे स्तर पर ZST" के रूप में देखना चाहता है। (यानी ! टाइप सिस्टम के लिए है क्योंकि () मेमोरी आवंटन के लिए है।)

@CryZe
आपका सूत्र -Inf + c == -Inf समझ में आता है, लेकिन जब -Inf को 0usize प्रतिस्थापित किया जाता है तो यह और अधिक नहीं रहता है।

दूसरी ओर, यदि अंकगणित "कैप्ड" है: कोई भी अतिप्रवाह usize::MAX गणना करता है तो usize::MAX सूत्र को पूरी तरह से फिट करता है।

मस्तिष्क मॉडल: यदि आपके पास ! प्रकार की वस्तु है, तो उस संरचना को आवंटित करने के लिए जिसमें यह शामिल है, आपको ! से भी बड़ी संरचना की आवश्यकता है, लेकिन आपके द्वारा छवि की जा सकने वाली सबसे बड़ी संरचना आकार usize::MAX . तो आपको जिस स्थान की आवश्यकता है वह अभी भी usize::MAX ।

क्यों न केवल किसी भी प्रकार के आकार को "क्लैंप" करें जिसमें एक शून्य प्रकार ( ! , या उपयोगकर्ता द्वारा परिभाषित enum Void {} ) से size=0,alignment=0 ? यह मेरे लिए बहुत अधिक अर्थपूर्ण रूप से समझदार लगता है ...

@remexre
क्योंकि यह काम नहीं करता है। उदाहरण: sizeof(Result<usize,!>) == sizeof(usize) ।

खैर, Result<usize, !> ! सीधे sizeof(Result::Ok(usize)) == 8 , sizeof(Result::Err(!)) == 0

नहीं, मेरे प्रस्ताव में sizeof(Result::Err(!)) == usize::MAX , क्योंकि Result::Err(!) :: Result<!,!> ।

नियम यह होना चाहिए: enum s में, ! आकार को अन्य सभी आकार मानों से कम माना जाता है, लेकिन structs , यह अब तक की छवि का अधिकतम आकार है।

निष्कर्ष:

• ! डीएसटी नहीं है। डीएसटी Sized नहीं हैं क्योंकि उनका आकार नहीं है, बल्कि इसलिए कि आकार की जानकारी छिपी हुई है। लेकिन ! हम इसके बारे में सब कुछ जानते हैं।
• ! का आकार होना चाहिए और इसलिए Box::new(x as !) को कम से कम संकलित करने की अनुमति दी जानी चाहिए।
• struct s में शामिल है ! का आकार इस तरह होना चाहिए जैसे कि यह ! , enum s में ! सीधे एक प्रकार के रूप में होना चाहिए यदि वह संस्करण मौजूद नहीं है।

या तो हम sizeof(!)==0 या sizeof(!)==usize::MAX , हमें उपरोक्त की अनुमति देने के लिए कुछ विशेष अंकगणित पेश करने होंगे:

sizeof(!)==0 : स्ट्रक्चर्स में, 0 + n = 0 : चिंतित:, एनम में, max(0,n) = n : ब्लश:।
sizeof(!)==usize::MAX : स्ट्रक्चर्स में, usize::MAX + n =usize::MAX :neutral_face:, enums में, max(usize::MAX,n) = n : flushed:.

हालांकि usize::MAX लिए एक लाभ है: यह तकनीकी रूप से किसी भी प्रयास को रोकता है, यहां तक ​​कि unsafe वाले भी, ऐसी वस्तु का निर्माण करने के लिए, क्योंकि यह किसी भी वास्तविक प्रणाली में संभव नहीं है।

हालांकि, उपयोग करने के लिए एक लाभ है :: मैक्स हालांकि: यह तकनीकी रूप से किसी भी प्रयास को रोकता है, यहां तक ​​​​कि असुरक्षित लोगों को भी, ऐसी वस्तु का निर्माण करने के लिए, क्योंकि यह किसी भी वास्तविक प्रणाली में संभव नहीं है।

मेरा मतलब है, अगर unsafe शेंगेनियों की अनुमति है: *transmute::<Box<usize>, Box<!>>(Box::new(0)) मुझे इसके आकार की परवाह किए बिना ! । usize::MAX यह अधिक संभावना बनाता है कि अगर कोई std::mem::zeroed<!>() करने का प्रयास करता है तो संकलक त्रुटि करेगा, मुझे लगता है, लेकिन मैं उस व्यक्ति पर डाल दूंगा जो गणित के बजाय असुरक्षित कोड लिख रहा है ऊपर विचित्रता।

ध्यान दें कि ! का आकार _actually_ 0 -- न तो MAX और न ही -INF -सेचुरेटेड-टू-0 - को आंशिक आरंभीकरण को संभालने की आवश्यकता है, जैसा कि था https://github.com/rust-lang/rust/issues/49298#issuecomment -380844923 (और https://github.com/rust-lang/rust/pull/50622 में कार्यान्वित) में पाया गया।

यदि आप यह बदलना चाहते हैं कि यह कैसे काम करता है, तो कृपया उसके लिए एक नया मुद्दा या पीआर बनाएं; यह जगह नहीं है।

@remexre

Box::new : T -> Box<U>
where T <: U,
      T: Sized

Box (ज्यादातर) एक पुस्तकालय प्रकार है और इसकी new विधि को src/liballoc/boxed.rs में रस्ट सिंटैक्स में परिभाषित किया गया है। आपका विवरण एक <: ऑपरेटर मानता है जो जंग में मौजूद नहीं है। ऐसा इसलिए है क्योंकि रस्ट में सबटाइपिंग केवल आजीवन मापदंडों के माध्यम से मौजूद है। यदि आप अधिक पढ़ना या देखना चाहते हैं:

• https://doc.rust-lang.org/nomicon/subtyping.html
• https://www.youtube.com/watch?v=fI4RG_uq-WU

! को किसी भी प्रकार के लिए ज़बरदस्ती किया जा सकता है, लेकिन यह किसी भी प्रकार के होने की तुलना में कमजोर है। (उदाहरण के लिए, किसी भी 'a के लिए Vec<&'static Foo> भी Vec<&'a Foo> , लेकिन Vec<!> से Vec<Foo> कोई अंतर्निहित रूपांतरण नहीं है: http:/ /play.rust-lang.org/?gist=82d1c1e1fc707d804a57c483a3e0198f&version=nightly&mode=debug&edition=2015)

मुझे लगता है कि विचार यह है कि आप unsafe मोड में जो कुछ भी उचित समझते हैं वह कर सकते हैं, लेकिन यदि आप इसे बुद्धिमानी से नहीं करते हैं तो आपको यूबी का सामना करना होगा। यदि ! का आधिकारिक आकार usize::MAX , तो इससे उपयोगकर्ता को पर्याप्त रूप से सचेत होना चाहिए कि इस प्रकार को कभी भी त्वरित नहीं किया जाना चाहिए।

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

@स्कॉटएबी
मैं यह सुनिश्चित करने के लिए इस मुद्दे पर ध्यान केंद्रित कर रहा हूं कि Box::new(x as !) में परेशानी न हो, इसलिए हम इसे स्थिर करने के लिए आगे बढ़ सकते हैं। प्रस्तावित तरीका ! का आकार बनाना है। यदि ZST मानक है तो यह ठीक होना चाहिए। मैं अब और बहस नहीं कर रहा हूं। बस इस तरह लागू करें कि sizeof(!)==0 करेगा।

इसके संरेखण को भी उपयोग करना स्वाभाविक है::MAX

usize::MAX दो की शक्ति नहीं है, इसलिए एक वैध संरेखण नहीं है। साथ ही, LLVM 1 << 29 से अधिक के संरेखण का समर्थन नहीं करता है। और ! वैसे भी बड़ा संरेखण नहीं होना चाहिए, क्योंकि let x: (!, i32); x.1 = 4; को केवल 4 बाइट्स स्टैक लेना चाहिए, गीगाबाइट्स-या-अधिक नहीं।

यदि आप इसे जारी रखना चाहते हैं, तो कृपया इस चर्चा के लिए एक नया सूत्र @earthengine बनाएं ।

यहां जो समस्या होती है वह यह है कि Box::new(!) एक Box<$0> जहां हम Box<Error> अपेक्षा करते हैं। पर्याप्त प्रकार के एनोटेशन के साथ, हमें Box<$0> को Box<Error> लिए मजबूर करने की आवश्यकता होगी, जो बाद में हमें $0 डिफ़ॉल्ट रूप से ! साथ छोड़ देगा।

हालांकि, $0 एक प्रकार का चर है, इसलिए जबरदस्ती नहीं की जाती है और फिर हमें $0 = Error ।

चीजें ठीक करने के लिए एक hacky विकल्प खोजने की जाएगी है कि हम एक बाधा $0: Sized (उपप्रकार निम्नलिखित?) और एक बलात्कार उस पर keyed डालने, ताकि Box अभी भी प्रकार पर कहा जाता है।

हम पहले से ही पता लगाने के लिए कुछ इस तरह करते हैं Fn बंद में है, इसलिए इस तरह के एक खिंचाव नहीं होगा। अभी भी बदसूरत।

यही है, अगर जबरदस्ती के दौरान हम फॉर्म के दायित्व का सामना करते हैं $0: Unsize<Y> जहां Y निश्चित रूप से आकार में नहीं है और $0 निश्चित रूप से आकार में है, तो इसे एक अस्पष्टता के रूप में न मानें, बल्कि इसे "ठीक" के रूप में मानें और बिना आकार के जबरदस्ती के साथ आगे बढ़ें।

@ एरियलब1

तो यह कैसे Box::new(()) से Box<Debug> जबरदस्ती से अलग है? std::error::Error एक विशेषता है जैसे Debug , न कि [u8] जैसे प्रकार। दूसरी ओर std::io::Error एक प्रकार है, लेकिन यह Sized ।

हमें निम्नलिखित में से कभी भी परेशानी नहीं होती है:

use std::fmt::Debug;

fn f(x:()) -> Box<Debug> {
    Box::new(x)
}

fn main() {
}

@earthengine इस मुद्दे और आपके कोड के बीच का अंतर है:

| लिखित | Box::new(!): Box<Debug> | Box::new(()): Box<Debug> |
| ------ | ------ | ------- |
| प्रदर्शन किया | Box::new(! as Debug): Debug | (Box::new(()) as Box<Debug>): Debug |

अनिवार्य रूप से, क्योंकि ! कुछ भी करने के लिए मजबूर कर सकते हैं, यह करने के लिए मजबूर कर रहा है Debug करने के लिए कॉल करने से पहले Box::new । यह () साथ कोई विकल्प नहीं है, इसलिए दूसरे मामले में कोई समस्या नहीं है - Box::new बाद वहां जबरदस्ती होती है।

@ राल्फजंग

मेरा दिमागी मॉडल यह है कि डीएसटी जंगली में मौजूद नहीं हो सकते - उन्हें कुछ और ठोस प्रकारों से आना पड़ता है। यह तब भी सच है जब हम डीएसटी को पैरामीटर स्थिति में अनुमति देते हैं - यदि रिटर्न स्थिति में नहीं। उस ने कहा, जब तक वास्तविक मूल्य पहले से ही एक सूचक के पीछे रखा जा रहा है, यह एक डीएसटी के साथ तालमेल करने में सक्षम नहीं होना चाहिए, यहां तक ​​​​कि यह ! ।

उदाहरण के लिए निम्नलिखित को संकलित नहीं करना चाहिए:

let v: str = !;
let v: [u8] = !;
let v: dyn Debug = !;

सिर्फ इसलिए कि आप ! को किसी भी मौजूदा रस्ट एक्सप्रेशन के साथ कंपाइल करने के लिए प्रतिस्थापित नहीं कर सकते।

संपादित करें

यह () के साथ एक विकल्प नहीं है

तो क्या कोई समझा सकता है क्यों? यदि () as dyn Debug संकलित नहीं होता है, तो ! as dyn Debug नहीं होगा और इसके विपरीत। &() as &Debug संकलित करता है, इसलिए &! as &Debug , कोई समस्या नहीं है। यदि () as dyn Debug किसी दिन संकलित हो जाता है, तो आज हमारे पास जो समस्या है, वह () लिए दोहराई जाएगी, इसलिए DST RFC कार्यान्वयनकर्ताओं को इसके कारण भुगतान करना होगा, और इसलिए यह उसी समस्या का समाधान करेगा जो हमारे पास है ! ।

! किसी भी चीज़ के लिए ज़बरदस्ती करता है क्योंकि उसका अस्तित्व असंभव है। "पूर्व फालो क्वोडलिबेट"। तो आपके सभी उदाहरणों को संकलित

यह "डीटीएस मौजूद नहीं हो सकता" का भी उल्लंघन नहीं करता है क्योंकि ! मौजूद नहीं हो सकता है। :)

() as dyn Debug संकलित नहीं करता है

मुझे नहीं पता कि अनसाइज़्ड रैल्यूज़ के लिए क्या योजनाएँ हैं, लेकिन मुझे लगता है कि वे इस संकलन को बना सकते हैं?
मुद्दा यह है कि ! ऐसा करने के लिए हमें अनसाइज़्ड रैल्यूज़ को लागू करने की आवश्यकता नहीं है क्योंकि यह केवल डेड कोड में ही हो सकता है।

हालांकि, हो सकता है कि आप यहां एक संभावित समाधान की ओर इशारा कर रहे हों (और हो सकता है कि @ arielb1 ने ऊपर भी यही सुझाव दिया हो): क्या ! जबरदस्ती को केवल तभी लागू करना संभव है जब लक्ष्य प्रकार (ज्ञात होने के लिए जाना जाता है) आकार का हो ? ऐसा करने का कोई अच्छा सैद्धांतिक कारण नहीं है, लेकिन एक व्यावहारिक है। :D अर्थात्, यह इस समस्या को हल करने में मदद कर सकता है।

जब मैंने कहा "डीटीएस मौजूद नहीं हो सकता" मेरा मतलब वाक्य रचनात्मक में है। उदाहरण के लिए, str टाइप किया गया स्थानीय चर होना संभव नहीं है।

दूसरी ओर, ! मौजूद नहीं हो सकता शब्दार्थ है। तुम लिख सकते हो

let v = exit(0);

संदर्भ में v वाक्य रचनात्मक रूप से ! टाइप करने के लिए, लेकिन बाध्यकारी भी नहीं चलेगा और इसलिए यह वास्तविक दुनिया में बाहर नहीं निकलता है।

तो यहां कारण है: हम किसी भी प्रकार के लिए ! जबरदस्ती की अनुमति देते हैं, केवल जब आप एक ही प्रकार की अभिव्यक्ति लिख सकते हैं। यदि कोई प्रकार वाक्यात्मक रूप से भी मौजूद नहीं हो सकता है, तो इसकी अनुमति नहीं दी जानी चाहिए।

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

उदाहरण के लिए, टाइप किया गया स्थानीय वैरिएबल str होना संभव नहीं है।

यह वर्तमान कार्यान्वयन की एक सीमा है: https://github.com/rust-lang/rust/issues/48055

@ राल्फजंग

यह यहाँ समस्या नहीं है।

दोबारा, मान लीजिए कि हम उस स्थिति में हैं जहां Box::new(!: $0): Box<dyn fmt::Debug> जहां $0 एक प्रकार चर है।

तब संकलक काफी आसानी से यह अनुमान लगा सकता है कि $0: Sized (क्योंकि $0 Box::new के प्रकार पैरामीटर के बराबर है, जिसमें T: Sized बाध्य है)।

समस्या तब आती है जब संकलक को यह पता लगाने की आवश्यकता होती है कि Box<$0> को Box<dyn fmt::Debug> बदलने के लिए किस प्रकार के जबरदस्ती का उपयोग करना है। "स्थानीय" पीओवी से, 2 समाधान हैं:

1. CoerceUnsized जबरदस्ती करें, जिसके लिए Box<$0>: CoerceUnsized<Box<dyn fmt::Debug>> आवश्यकता होती है। यह $0 = ! लिए एक वैध प्रोग्राम है और डिफॉल्ट करने से यह उसी के लिए संकलित हो जाएगा।
2. $0 = dyn fmt::Debug साथ एक पहचान ज़बरदस्ती करें। यह $0: Sized आवश्यकता के साथ असंगत है।

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

तो इस पीओवी से इस पर विचार करते हुए, सही विचार यह हो सकता है कि एक अनसाइज़्ड ज़बरदस्ती को ट्रिगर किया जाए यदि

1. अनसाइज़्ड ज़बरदस्ती स्व-संगत है (यह वर्तमान नियम होंगे, सिवाय इसके कि अस्पष्टता ठीक है)।
2. अनसाइज़्ड ज़बरदस्ती को ट्रिगर नहीं करना असंगत है। हमें यह देखना होगा कि बड़े कार्यों पर प्रदर्शन को बर्बाद किए बिना इसकी गणना की जा सकती है।

$0 = dyn fmt::Debug के साथ एक पहचान ज़बरदस्ती करें। यह $0: आकार की आवश्यकता के साथ असंगत है।

मैं शायद ही यह देख सकूं कि हमें let v: str=! अनुमति क्यों देनी चाहिए लेकिन let v: str; । यदि आप एक विशिष्ट प्रकार के साथ एक चर घोषित भी नहीं कर सकते हैं, तो आप इसके लिए एक (शायद असंभव) मान क्यों बांध सकते हैं?

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

तो मेरा निष्कर्ष यह है कि Box::new(!) as Box<Error> समस्या आकारहीन प्रतिद्वंद्विता के लिए एक अवरुद्ध मुद्दा है, न कि ! प्रकार के लिए। ! जबरदस्ती के नियम होने चाहिए:

आप let v: T लिख सकते हैं, यदि और केवल यदि आप let v: T = ! लिख सकते हैं।

थिया वास्तविक अर्थ तब भाषा के साथ मूल्यांकन करेगा। विशेष रूप से, हमारे पास अनसाइज़्ड प्रतिद्वंद्विता होने के बाद, हमारे पास Box::new(! as dyn Debug) लेकिन इससे पहले, मैं कहूंगा कि नहीं।

तो हम आगे बढ़ने के लिए क्या कर सकते हैं?

कोड पर एक फीचर गेट जोड़ें जो अनसाइज़्ड ज़बरदस्ती को ट्रिगर करता है, अगर अनसाइज़्ड रैवेल्यू चालू है, तो इस ज़बरदस्ती का प्रयास करें, अन्यथा, इसे छोड़ दें। यदि यह एकमात्र उपलब्ध जबरदस्ती है, तो त्रुटि संदेश "विशेषता बाध्य str: std::marker::Sized संतुष्ट नहीं है" होना चाहिए, जैसे कि इसी तरह के मामलों में। इसलिए

हमें यह देखना होगा कि बड़े कार्यों पर प्रदर्शन को बर्बाद किए बिना इसकी गणना की जा सकती है।

संबोधित किया गया है: बस एक साधारण सुविधा जाँच।

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

दिलचस्प।

इस

fn main() {
    let _:str = *"";
}

संकलित करता है, लेकिन

fn main() {
    let v:str = *"";
}

नहीं। यह ! प्रकार से भी संबंधित नहीं है। क्या मैं इसके लिए कोई मुद्दा बनाऊं?

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

पहले उदाहरण में, _ पैटर्न इस मायने में विशेष है कि यह न केवल किसी भी चीज़ से मेल खाता है (जैसे स्थानीय चर बाइंडिंग), लेकिन यह एक चर भी नहीं बनाता है। तो वह कोड समान है fn main() { *""; } बिना let । एक संदर्भ (यहां तक ​​​​कि डीएसटी) को संदर्भित करना और फिर परिणाम के साथ कुछ भी नहीं करना उपयोगी नहीं है, लेकिन ऐसा लगता है कि यह मान्य है और मुझे विश्वास नहीं है कि यह अमान्य होना चाहिए।

सही। लेकिन यह वास्तव में भ्रमित करने वाला है, विशेष रूप से निम्नलिखित

fn main() {
    let _v:str = *"";
}

संकलित भी नहीं करता है। आपके सिद्धांत के साथ _ यह वही होना चाहिए सिवाय इसके कि हम अप्रयुक्त चीज़ को _v बजाय _ ।

मुझे जो याद है, उससे _v और v बीच एकमात्र अंतर यह है कि प्रमुख अंडरस्कोर अप्रयुक्त मूल्यों के बारे में चेतावनियों को दबा देता है।

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

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

सही। आपने जो कहा उसके ऊपर, let _ = foo() ओर जाता है drop को तुरंत बुलाया जा रहा है, जबकि _v केवल तभी गिराया जाता है जब यह दायरे से बाहर हो जाता है (जैसे v )

वास्तव में, " _ विशेष है" से मेरा यही मतलब है।

तो अब ऐसा लगता है कि जंगली में सभी अनसाइज़्ड रैल्यूज़ (जब तक कि फीचर "अनसाइज़्ड रैल्यूज़" चालू नहीं हो जाता) को नकारना एक ब्रेकिंग बदलाव होगा, हालाँकि मुझे लगता है कि प्रभाव बहुत कम होगा।

मैं तब भी सुझाव देता हूं कि ! लेकर अनसाइज्ड रैल्यूज तक जबरदस्ती को रोकने के लिए एक फीचर गेट होना चाहिए। यह let _:str = return; जैसे कोड को अस्वीकार कर देगा, लेकिन मुझे नहीं लगता कि कोई भी इसे कोड में उपयोग करेगा।

जब तक ! प्रकार अस्थिर है, हम उस स्थान पर ब्रेकिंग परिवर्तन कर सकते हैं जहां इसे ज़बरदस्ती किया जा सकता है या नहीं।

सवाल यह है कि अगर हम https://github.com/rust-lang/rust/issues/49593 को ठीक करने के लिए डीएसटी के साथ जबरदस्ती के बिना इसे स्थिर करते हैं, तो क्या हम बाद में इस तरह के जबरदस्ती को बहाल करना चाहेंगे जब हम अनसाइज़्ड रैल्यूज़ जोड़ते हैं और क्या हम https://github.com/rust-lang/rust/issues/49593 फिर से तोड़े बिना ऐसा करने में सक्षम हो?

मेरे पिछले प्रस्ताव में यह शामिल है। # 49593 अनसाइज़्ड प्रतिद्वंद्विता के लिए एक अवरुद्ध मुद्दा होना चाहिए।

अंतिम समाधान के लिए मेरा व्यक्तिगत सुझाव है, Box::new (इसमें कुछ अन्य महत्वपूर्ण तरीके भी शामिल हो सकते हैं) को अनसाइज़ किए गए मापदंडों को स्वीकार करने दें, और समान स्थितियों में अस्पष्टता की अनुमति दें।

FWIW, _ एक विशेष चर नाम जैसा कुछ नहीं है । यह एक पूरी तरह से अलग पैटर्न सिंटैक्स है जो मिलान किए जा रहे स्थान के लिए कुछ भी नहीं करता है । पैटर्न-मिलान स्थानों पर काम करता है, मूल्यों पर नहीं।
वेरिएबल बाइंडिंग के सबसे करीब ref _x , लेकिन फिर भी आपको इसके परिणामस्वरूप परस्पर विरोधी उधार से बचने के लिए शायद NLL की आवश्यकता है। यह बीटीडब्ल्यू काम करता है:

// The type `str` is the type of the place being matched. `x` has type `&str`.
let ref x: str = *"foo";
// Fully equivalent to this:
let x: &str = &*"foo";

@eddyb

आपको मेरी बात समझ में नहीं आई। मेरी धारणा यह है कि रस्ट में वर्तमान में कोई भी अनसाइज़्ड रैल्यूज़ कोड में बिल्कुल भी दिखाई नहीं दे सकता है। हालांकि यह पता चला है कि वे let _:str = *"" में दिखाई देते हैं। हालांकि ऐसा मूल्य कुछ समय के लिए नहीं रह सकता है, वाक्यात्मक स्तर में यह रहता है। भूत जैसा कुछ...

इसके बजाय आपके उदाहरण तकनीकी रूप से पूरी तरह कानूनी हैं और यह बात नहीं है। str है, लेकिन &str आकार में है।

हालांकि यह पता चला है कि वे let _:str = *"" में दिखाई देते हैं। हालांकि ऐसा मूल्य कुछ समय के लिए नहीं रह सकता है, वाक्यात्मक स्तर में यह रहता है। भूत जैसा कुछ...

&*foo जैसी अभिव्यक्ति में एक समान "भूत" होता है। पहले आप foo डीरेफरेंस करें और फिर परिणाम को बिना हिलाए उसका पता लें । तो यह & { *foo } जैसा नहीं है, उदाहरण के लिए।

@earthengine @SimonSapin वहां कोई अनसाइज़्ड रैल्यूज़ ("वैल्यू एक्सप्रेशन") मौजूद नहीं है। केवल अंतराल ("स्थान अभिव्यक्ति") करते हैं। *"foo" एक जगह है , और पैटर्न-मिलान के लिए किसी मान की आवश्यकता नहीं है, केवल एक जगह है।

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

आपके उदाहरणों में, let x = *"foo"; , इसे x से बाँधने के लिए मान आवश्यक है।
इसी तरह, &*"foo" एक जगह अभिव्यक्ति बनाता है और फिर उसे उधार लेता है, बिना किसी आकार के मूल्य बनाने की आवश्यकता के, जबकि {*"foo"} हमेशा एक मूल्य अभिव्यक्ति है और इस प्रकार असीमित प्रकारों की अनुमति नहीं देता है।

https://github.com/rust-lang/rust/pull/52420 में मैंने वह मारा

let Ok(b): Result<B, !> = ...;
b

अब काम नहीं करता है। क्या यह जानबूझकर है?

AFAIK हाँ - अचूक पैटर्न कहानी जटिल है और इसमें ! से अलग फीचर गेट है। https://github.com/rust-lang/rfcs/pull/1872 और https://github.com/rust-lang/rust/issues/48950 भी देखें

@ Ericson2314 विशेष रूप से वह सुविधा जिसे आपको liballoc में जोड़ने की आवश्यकता होगी वह है exhaustive_patterns ।

धन्यवाद!!

इंटर्नल पर एक दिलचस्प बातचीत:

• __समस्या:__ हम लिख नहीं सकते
  rust fn make_iter() -> impl Iterator<Item=u32> { unimplemented!() // Error: ! does not implement Iterator }
  क्योंकि ! मनमाने ढंग से जुड़े प्रकारों के लिए संभवतः Iterator को लागू नहीं कर सका।
• __प्रस्ताव:__ आइए <! as Trait>::Assoc एक प्रकार का अनुमान चर बनाते हैं ।
  
  
  
  • __नोट:__ यह सुनिश्चित करने के लिए टाइप सिस्टम में एक्सटेंशन आवश्यक होंगे कि उदाहरण के लिए fn foo<T:Trait>() -> (T::Assoc, T::Assoc) एक ही प्रकार के दो उत्पादन करने की गारंटी है।
  
  
• __प्रति उदाहरण:__ typemap टोकरा खराब हो जाएगा।

यदि आप ऐसा करने जा रहे हैं, तो इलाज क्यों नहीं! खुद को एक अनुमान चर के रूप में?

आइटम प्रकार को स्पष्ट करने के लिए बस ! साथ PhandomData साथ एक रैपर बनाएं।

https://github.com/rust-lang/rust/issues/49593 अब ठीक कर दिया गया है। पिछले स्थिरीकरण की वापसी का यही कारण था। पिछली स्थिरीकरण रिपोर्ट यहाँ है । आइए इसे फिर से आजमाएं!

@rfcbot fcp मर्ज

मुझे लगता है कि rfcbot एक से अधिक का समर्थन कर सकता है FCP एक ही मुद्दे में. आइए स्थिरीकरण के इस दौर के लिए एक नया मुद्दा खोलें?

https://github.com/rust-lang/rust/pull/50121 न केवल वापस स्थिरीकरण बल्कि फॉलबैक शब्दार्थ भी। क्या यह ऐसी चीज है जिस पर हम फिर से विचार करना चाहते हैं?

समस्या विवरण में शेष अनियंत्रित चेकबॉक्स है:

! लिए हमें कौन से लक्षण लागू करने चाहिए? प्रारंभिक पीआर #35162 में Ord और कुछ अन्य शामिल हैं। यह शायद एक टी-लिब्स मुद्दा है, इसलिए मैं उस टैग को इस मुद्दे में जोड़ रहा हूं।

हम बाद में इम्प्लांट्स जोड़ सकते हैं, है ना? या यह अवरोधक है?

@SimonSapin ने https://github.com/rust-lang/rust/issues/57012 खोला ! फॉलबैक फिर से सक्षम किया जाएगा, हां (हालांकि आइए स्थिरीकरण मुद्दे पर चर्चा करें)।

क्रॉस-रेफ़रेंसिंग: https://github.com/rust-lang/rust/issues/58184

जाहिरा तौर पर फीचर गेट के पीछे कभी भी टाइप नहीं होने में बग/छेद है, और इसे स्थिर पर संदर्भित करना संभव है: https://github.com/rust-lang/rust/issues/33417#issuecomment -467053097

संपादित करें: https://github.com/rust-lang/rust/issues/58733 दायर किया

ऊपर लिंक किए गए कोड उदाहरण में प्रकार का उपयोग जोड़ना:

trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

fn main() {
    let _a: Void;
}

यह जंग 1.12.0 में संकलित है जो मुझे लगता है कि https://github.com/rust-lang/rust/pull/35162 के साथ पहला है

error: the trait bound `fn() -> !: MyTrait` is not satisfied [--explain E0277]
  --> a.rs:12:13
   |>
12 |>     let _a: Void;
   |>             ^^^^
help: the following implementations were found:
help:   <fn() -> T as MyTrait>

error: aborting due to previous error

इस की क्या स्थिति है?

जहां तक ​​मुझे पता है कि https://github.com/rust-lang/rust/issues/57012#issuecomment -467889706 में मेरे सारांश के बाद से स्थिति में कोई खास बदलाव नहीं आया है।

इस की क्या स्थिति है?

@hosunrise : वर्तमान में https://github.com/rust-lang/rust/issues/67225 पर अवरुद्ध है

मैं यहां से दूर हो सकता हूं, लेकिन विशिष्ट मुद्दे जो लिंट चर्चा (https://github.com/rust-lang/rust/issues/66173) का उल्लेख करते हैं, दोनों ही हल करने योग्य लगते हैं यदि प्रत्येक एनम में ! शाखा है प्रकार प्रणाली?

मैं ध्यान दूंगा कि https://github.com/rust-lang/rust/issues/67225 के ओपी में उल्लिखित मुद्दे पर लागू नहीं होता है, जो अभी भी एक मुद्दा होगा।

मैं यहां से दूर हो सकता हूं, लेकिन विशिष्ट मुद्दे जो कि लिंट चर्चा (# 66173) का उल्लेख करते हैं, दोनों ही हल करने योग्य लगते हैं यदि प्रत्येक एनम की टाइप सिस्टम में ! शाखा है?

वास्तव में, प्रत्येक एनम को खतरा हो सकता है क्योंकि अनंत संख्या में वेरिएंट थे जो कभी नहीं हो सकते हैं, और इस प्रकार वे सभी उल्लेख के लायक नहीं हैं।