मैं इसे RFC पर चर्चा में याद कर सकता हूं, लेकिन क्या मैं यह सोचने में सही हूं कि यूनियन वेरिएंट के विध्वंसक कभी नहीं चलते हैं? इस उदाहरण में Box::new(1) लिए विनाशकारी होगा?

union Foo {
    f: i32,
    g: Box<i32>,
}

let mut f = Foo { g: Box::new(1) };
f.g = Box::new(2);

@sfackler मेरी वर्तमान समझ यह है कि f.g = Box::new(2) _will_ विध्वंसक चलाते हैं लेकिन f = Foo { g: Box::new(2) } _not_। यही है, Box<i32> lvalue को असाइन करने से हमेशा की तरह एक बूंद हो जाएगी, लेकिन Foo lvalue को असाइन करने से नहीं होगा।

तो एक संस्करण के लिए एक असाइनमेंट एक जोर की तरह है कि क्षेत्र पहले "वैध" था?

@sfackler Drop प्रकारों के लिए, हाँ, यह मेरी समझ है। यदि वे पहले वैध नहीं थे, तो आपको Foo कंस्ट्रक्टर फॉर्म या ptr::write । एक त्वरित grep से, ऐसा नहीं लगता कि RFC इस विवरण के बारे में स्पष्ट है, हालांकि। मैं इसे सामान्य नियम की तात्कालिकता के रूप में देखता हूं कि Drop lvalue लिखने से विध्वंसक कॉल होता है।

ड्रॉप वेरिएंट के साथ एक और म्यूट यूनियन को एक लिंट होना चाहिए?

शुक्रवार, 8 अप्रैल 2016 को, स्कॉट ओल्सन सूचनाएं @github.com ने लिखा:

@sfackler https://github.com/sfackler ड्रॉप प्रकारों के लिए, हाँ, यह मेरी है
समझ। यदि वे पहले मान्य नहीं थे, तो आपको फू का उपयोग करने की आवश्यकता है
कंस्ट्रक्टर फॉर्म या ptr :: लिखना। एक त्वरित grep से, ऐसा नहीं लगता है
RFC हालांकि इस विवरण के बारे में स्पष्ट है।

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

8 अप्रैल 2016 को 3:36:22 PM PDT, स्कॉट ओल्सन नोटिफिकेशन @github.com ने लिखा:

@sfackler Drop प्रकारों के लिए, हाँ, यह मेरी समझ है। यदि वे
पहले मान्य नहीं थे आपको Foo कंस्ट्रक्टर फॉर्म का उपयोग करने की आवश्यकता है या
ptr::write । एक त्वरित grep से, ऐसा नहीं लगता कि RFC है
हालांकि इस विवरण के बारे में स्पष्ट है।

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

हाँ, यह दृष्टिकोण मुझे थोड़ा कम खतरनाक लगता है।

यूनियन फील्ड में असाइन करने पर ड्रॉपिंग f.g = Box::new(2) let p = &mut f.g; *p = Box::new(2) से अलग तरीके से काम नहीं करेगी, क्योंकि आप बाद के केस _not_ ड्रॉप नहीं कर सकते। मुझे लगता है कि मेरा दृष्टिकोण कम आश्चर्यजनक है।

यह कोई नई समस्या नहीं है; unsafe प्रोग्रामर को पहले से ही अन्य स्थितियों से निपटना पड़ता है जहाँ foo = bar UB होता है यदि foo uninitialized और Drop ।

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

मैं भी यूनियनों में ड्रॉप प्रकारों का उपयोग करने का इरादा नहीं करता हूं, इसलिए जब तक यह सुसंगत है, तब तक कोई रास्ता नहीं है।

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

शुक्रवार, 8 अप्रैल 2016 को, पीटर एटशियान नोटिफिकेशन @github.com ने लिखा:

मैं भी यूनियनों में ड्रॉप प्रकारों का उपयोग करने का इरादा नहीं रखता, इसलिए कोई रास्ता नहीं है
जब तक यह सुसंगत है मेरे लिए मायने रखता है।

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

ऐसा लगता है कि एक अनसुलझे सवाल के रूप में एक अच्छा मुद्दा है। मुझे अभी तक यकीन नहीं है कि मुझे कौन सा दृष्टिकोण पसंद है।

@nikomatsakis जितना मुझे यह अजीब लगता है कि ड्रॉप के साथ एक प्रकार के एक संघ क्षेत्र को असाइन करने के लिए उस क्षेत्र की पिछली वैधता की आवश्यकता होती है, उल्लेखित मामले @tsion लगभग अपरिहार्य लगता है। मुझे लगता है कि यह सिर्फ एक कोड से जुड़ा हो सकता है जो जानबूझकर एक संघ में ड्रॉप के साथ एक प्रकार डालने के लिए एक प्रकार का वृक्ष को निष्क्रिय करता है। (और इसका एक संक्षिप्त विवरण उस लिंट के लिए व्याख्यात्मक पाठ में होना चाहिए।)

और मैं दोहराना चाहूंगा कि unsafe प्रोग्रामर को पहले से ही पता होना चाहिए कि a = b मतलब drop_in_place(&mut a); ptr::write(&mut a, b) सुरक्षित कोड लिखने के लिए है। नहीं छोड़ने वाले संघ क्षेत्रों को __ अधिक सीखना होगा_ सीखने के लिए अपवाद, कम नहीं।

(एनबी: ड्रॉप तब नहीं होता है जब a _statically_ पहले से ही अनैतिक रूप से जाना जाता है, जैसे let a; a = b; ।)

लेकिन मैं यूनियनों में Drop वेरिएंट के खिलाफ एक डिफ़ॉल्ट चेतावनी होने का समर्थन करता हूं जो लोगों को #[allow(..)] क्योंकि यह एक काफी गैर-स्पष्ट विवरण है।

@ सिटियन यह a = b लिए सच नहीं है और शायद कभी-कभी a.x = b लिए भी सही है लेकिन *a = b लिए निश्चित रूप से सच है। इस अनिश्चितता ने मुझे इसके बारे में संकोच कर दिया। उदाहरण के लिए, यह संकलन:

fn main() {
  let mut x: (i32, i32);
  x.0 = 2;
  x.1 = 3;
}

(हालांकि x प्रिंट करने की कोशिश बाद में विफल हो जाती है, लेकिन मुझे लगता है कि एक बग)

@nikomatsakis यह उदाहरण मेरे लिए नया है। मुझे लगता है कि मैंने इसे एक बग माना होगा कि उदाहरण संकलन करता है, मेरे पिछले अनुभव को देखते हुए।

लेकिन मुझे यकीन नहीं है कि मुझे उस उदाहरण की प्रासंगिकता दिखाई देती है। मैंने जो कहा है वह a = b लिए सही नहीं है और केवल कभी-कभी a.x = b ?

कहो, यदि x.0 में एक विध्वंसक के साथ एक प्रकार होता है, तो निश्चित रूप से उस विध्वंसक को कहा जाता है:

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called before writing new value
}

हो सकता है कि इस तरह के लेखन के खिलाफ सिर्फ एक संकेत?

मेरा कहना केवल इतना है कि = _always_ को विध्वंसक नहीं चलाते हैं; यह
कुछ ज्ञान का उपयोग करता है कि क्या लक्ष्य के लिए जाना जाता है
प्रारंभ।

Tue, अप्रैल 12, 2016 को 04:10:39 अपराह्न -0700 पर, स्कॉट ओल्सन ने लिखा:

@nikomatsakis मेरे लिए नया उदाहरण है। मुझे लगता है कि मैंने इसे एक बग माना होगा कि उदाहरण संकलन करता है, मेरे पिछले अनुभव को देखते हुए।

लेकिन मुझे यकीन नहीं है कि मुझे उस उदाहरण की प्रासंगिकता दिखाई देती है। मैंने a = b और केवल कभी-कभी 'ax = b' के लिए सही क्यों नहीं कहा?

कहो, यदि x.0 में एक विध्वंसक के साथ एक प्रकार होता है, तो निश्चित रूप से उस विध्वंसक को कहा जाता है:

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called
}

@nikomatsakis

यह विध्वंसक चलाता है अगर ड्रॉप फ्लैग सेट है।

लेकिन मुझे लगता है कि इस तरह का लेखन वैसे भी भ्रामक है, तो क्यों न सिर्फ इसे मना किया जाए? आप हमेशा *(&mut u.var) = val ।

मेरा कहना केवल इतना है कि = _always_ को विध्वंसक नहीं चलाते हैं; यह इस बारे में कुछ ज्ञान का उपयोग करता है कि क्या लक्ष्य को आरंभिक रूप से जाना जाता है।

@nikomatsakis मैंने पहले ही उल्लेख किया है कि:

(एनबी: ड्रॉप तब नहीं होता है जब एक को पहले से ही अनधिकृत रूप से जाना जाता है, जैसे a; a = b।;)

लेकिन मैं ड्रॉप झंडे की गतिशील जाँच के लिए जिम्मेदार नहीं था, इसलिए यह निश्चित रूप से मेरे विचार से अधिक जटिल है।

@tsion

ड्रॉप फ़्लैग केवल अर्ध-गतिशील होते हैं - शून्य ड्रॉप छोड़ने के बाद, वे कोडगेन का एक हिस्सा होते हैं। मैं कहता हूं कि हम उस तरह के लेखन को मना करते हैं क्योंकि यह अच्छे से अधिक भ्रम पैदा करता है।

क्या यूनियनों में Drop प्रकारों को भी अनुमति दी जानी चाहिए? अगर मैं चीजों को सही ढंग से समझ रहा हूं, तो Rust में यूनियनों के होने का मुख्य कारण C कोड के साथ इंटरफेस करना है, जिसमें यूनियन्स हैं, और C के पास विध्वंसक भी नहीं हैं। अन्य सभी उद्देश्यों के लिए, ऐसा लगता है कि रस्ट कोड में enum का उपयोग करना बेहतर है।

NoDrop प्रकार को लागू करने के लिए एक संघ का उपयोग करने के लिए एक वैध उपयोग मामला है जो ड्रॉप को रोकता है।

साथ ही drop_in_place या समान के माध्यम से ऐसे कोड को मैन्युअल रूप से लागू करना।

मेरे लिए किसी फ़ील्ड मान को लिखते समय छोड़ना निश्चित रूप से गलत है क्योंकि पिछला विकल्प प्रकार अपरिभाषित है।

क्या क्षेत्र के निवासियों को रोकना संभव होगा लेकिन पूर्ण संघ प्रतिस्थापन की आवश्यकता है? इस स्थिति में यदि यूनियन पूर्णरूपेण गिरा देता है, तो अपेक्षित मूल्य के बदले पूर्ण संघ ड्रॉप कहा जाएगा।

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

चर्चा के लिए, मैं यूनियनों में क्षेत्रों के लिए परस्पर संदर्भों को उजागर करने का इरादा रखता हूं _ और_ मनमाने ढंग से डालते हैं (संभवतः Drop ) उनमें टाइप करते हैं। मूल रूप से, मैं कस्टम स्पेस-कुशल एनम लिखने के लिए यूनियनों का उपयोग करना चाहूंगा। उदाहरण के लिए,

union SlotInner<V> {
    next_empty: usize, /* index of next empty slot */
    value: V,
}

struct Slot<V> {
    inner: SlotInner<V>,
    version: u64 /* even version -> is_empty */
}

@nikomatsakis मैं वर्तमान में यहां अनसुलझे के रूप में सूचीबद्ध प्रश्न का एक ठोस जवाब देना चाहता हूं।

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

क्या इस व्यवहार को प्रलेखित करने के लिए RFC1444 में संशोधन करके RFC पुल अनुरोध प्रदान करने का कोई मतलब होगा?

@joshtriplett चूँकि @nikomatsakis छुट्टी पर है, मैं जवाब दूंगा: मुझे लगता है कि इस तरह के प्रश्नों को हल करने के लिए एक संशोधन RFC दायर करना बहुत अच्छा है। हम उपयुक्त होने पर अक्सर ऐसे RFC PRs को फास्ट ट्रैक करेंगे।

@ न्यूटन धन्यवाद। मैंने नया RFC PR https://github.com/rust-lang/rfcs/issues/1663 इन स्पष्टीकरणों के साथ दायर किया है। RFC1444 में, इस समस्या को हल करने के लिए।

_{( @ न्यूटन आप अब उस अनसुलझे प्रश्न को जांच सकते हैं।)}

मेरा https://github.com/petrochenkov/rust/tree/union में कुछ प्रारंभिक कार्यान्वयन है

स्थिति: कार्यान्वित (modulo बग), PR सबमिट किया गया (https://github.com/rust-lang/rust/pull/p107107)।

@petrochenkov बहुत बढ़िया! अब तक बहुत अच्छा लग रहा है।

मुझे यकीन नहीं है कि कैसे चालन परीक्षक में गैर Copy फ़ील्ड के साथ यूनियनों का इलाज किया जाए।
मान लीजिए कि u union U { a: A, b: B } का आरंभिक मूल्य है और अब हम उनमें से एक क्षेत्र से बाहर चले गए हैं:

1) A: !Copy, B: !Copy, move_out_of(u.a)
यह सरल है, u.b को भी असमान अवस्था में डाल दिया जाता है।
Sanity check: union U { a: T, b: T } को बिलकुल struct S { a: T } + फ़ील्ड की तरह व्यवहार करना चाहिए।

2) A: Copy, B: !Copy, move_out_of(u.a)
माना जाता है कि u.b को अभी भी आरंभीकृत किया जाना चाहिए, क्योंकि move_out_of(u.a) केवल memcpy और किसी भी तरह से u.b नहीं बदलता है।

2) A: !Copy, B: Copy, move_out_of(u.a)
यह सबसे अजीब मामला है; माना जाता है कि u.b को Copy होने के बावजूद भी असमान अवस्था में डाल दिया जाना चाहिए। Copy मानों का अनैतिक रूप से उपयोग किया जा सकता है (जैसे let a: u8; ), लेकिन उनके राज्य को प्रारंभिक से बदलकर एकतरफा बनाना कुछ नया है, AFAIK।

@ retep998
मुझे पता है कि यह पूरी तरह से एफएफआई जरूरतों के लिए अप्रासंगिक है :)
अच्छी खबर यह है कि यह एक अवरोधक नहीं है, मैं जो भी व्यवहार सरल है उसे लागू करने जा रहा हूं और इस सप्ताह के अंत में पीआर प्रस्तुत करूंगा।

@petrochenkov मेरी वृत्ति यह है कि संघ एक "बिट-बकेट" हैं, अनिवार्य रूप से। आप यह ट्रैक करने के लिए ज़िम्मेदार हैं कि डेटा इनिशियलाइज़ है या नहीं और यह सही प्रकार क्या है। यह कच्चे सूचक के संदर्भ के समान है।

यही कारण है कि हम आपके लिए डेटा नहीं छोड़ सकते हैं, और यह भी कि खेतों तक कोई पहुंच असुरक्षित क्यों है (भले ही, कहें, एक ही संस्करण है)।

इन नियमों से, मैं उम्मीद करूंगा कि यदि यूनियनों को उनके लिए कॉपी लागू की गई तो Copy लागू होगा। हालांकि, स्ट्रक्चर / एनम के विपरीत, कोई आंतरिक पवित्रता जांच नहीं होगी: यदि आप चाहें तो आप हमेशा यूनियन प्रकार के लिए कॉपी लागू कर सकते हैं।

मुझे स्पष्ट करने के लिए कुछ उदाहरण दें:

union Foo { ... } // contents don't matter

यह मिलन शालीन है, क्योंकि Copy लागू नहीं किया गया है।

union Bar { x: Rc<String> }
impl Copy for Bar { }
impl Clone for Bar { fn clone(&self) -> Self { *self } }

यह संघ प्रकार Bar कॉपी है, क्योंकि Copy लागू किया गया है।

ध्यान दें कि यदि Bar एक struct थे, यह एक त्रुटि होगा लागू करने के लिए Copy क्षेत्र के प्रकार की वजह से x ।

हुह, मुझे लगता है कि मैं वास्तव में आपके प्रश्न का उत्तर नहीं दे रहा हूं, हालांकि अब मैं इसे फिर से पढ़ रहा हूं। =)

ठीक है, इसलिए, मुझे एहसास हुआ कि मैं आपके सवाल का जवाब नहीं दे रहा था। इसलिए मुझे फिर से कोशिश करने दें। "बिट बकेट" सिद्धांत के बाद, मैं _still_ को उम्मीद होगी कि हम इच्छानुसार संघ से बाहर जा सकते हैं। लेकिन निश्चित रूप से एक और विकल्प यह होगा कि हम एक *mut T इलाज करें, और आपको ptr::read का उपयोग करने की आवश्यकता होगी।

संपादित करें: मुझे वास्तव में पूरा यकीन नहीं है कि हम इस तरह के कदमों पर रोक क्यों लगाएंगे। इसे w / मूविंग ड्रॉप करना पड़ सकता है - या शायद सिर्फ इसलिए कि गलती करना आसान है और इसे "स्पष्ट" करना अधिक बेहतर लगता है? मुझे यहां के इतिहास को याद करने में परेशानी हो रही है।

@nikomatsakis

मेरी वृत्ति यह है कि संघ एक "बिट-बकेट" हैं, अनिवार्य रूप से।

हा, मैं, इसके विपरीत, संघ की सामग्री के बारे में कई गारंटी देना चाहूंगा क्योंकि हम ऐसे खतरनाक निर्माण के लिए कर सकते हैं।

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

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

वास्तव में, मैं इसे और भी रूढ़िवादी बनाना चाहूंगा, जैसा कि https://github.com/rust-lang/rust/pull/36016#issuecomment -242810887 में वर्णित है

@petrochenkov

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

ध्यान दें कि असुरक्षित कोड हमेशा शामिल होता है, जब एक संघ के साथ काम करते हैं, क्योंकि किसी क्षेत्र में हर पहुंच असुरक्षित होती है।

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

इसलिए मुझे मूल रूप से एक निहित (और असुरक्षित) दावे के रूप में some_union.field का कोई भी उपयोग दिखाई देता है कि मान्य वेरिएंट के सेट में वर्तमान में field । यह उधार-चेकर एकीकरण कैसे काम करता है के साथ संगत लगता है; यदि आप x उधार लेते हैं और फिर y का उपयोग करने का प्रयास करते हैं, तो आपको एक त्रुटि मिल रही है क्योंकि आप मूल रूप से कह रहे हैं कि डेटा एक साथ x और y (और यह उधार है)। (इसके विपरीत, एक नियमित रूप से एनम के साथ , एक समय में एक से अधिक वेरिएंट को प्राप्त करना संभव नहीं है, और आप

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

रूढ़िवादी होने का खतरा यह है कि हम असुरक्षित कोड को अच्छी तरह से नियंत्रित कर सकते हैं जो अन्यथा समझ में आता है और मान्य होगा। लेकिन मैं तंग शुरू करने और बाद में ढीला करने का फैसला करने के साथ ठीक हूं।

हमें इस बात पर चर्चा करनी चाहिए कि एक संघ पर Copy लागू करने के लिए किन शर्तों की आवश्यकता है - इसके अलावा, हमें यह सुनिश्चित करना चाहिए कि स्थिरीकरण से पहले हम इन ग्रे क्षेत्रों की पूरी सूची सुनिश्चित करें कि हम पते और दस्तावेज़ को सुनिश्चित करने के लिए ऊपर सूचीबद्ध हैं!

मूल रूप से एक संघ एक एनम की तरह है लेकिन यह एक साथ एक से अधिक प्रकार में हो सकता है।

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

हमें यह सुनिश्चित करना चाहिए कि हमारे पास इन ग्रे क्षेत्रों की पूरी सूची है

मैं यूनियन RFC को कुछ दूरगामी भविष्य में संशोधित करने जा रहा हूँ! "एनम" की व्याख्या के बहुत मजेदार परिणाम हैं।

संकलित समय पर प्रसारण आम तौर पर खराब होता है (जब तक हम संकलक को किसी प्रकार के आंशिक लक्ष्य एमुलेटर में बदलने की कोशिश कर रहे हैं)

@petrochenkov यह मेरे मिरी प्रोजेक्ट के लक्ष्यों में से एक है। मिरी पहले से ही ट्रांसमिशन और विभिन्न कच्चे सूचक शेंनिगन कर सकते हैं। मिरी हैंडल यूनियनों (कच्ची मेमोरी हैंडलिंग साइड पर कुछ भी नया नहीं) बनाने के लिए यह एक छोटी राशि का काम होगा।

और @eddyb जंगी स्थिरांक मूल्यांकन को मिरी के एक संस्करण के साथ बदलने पर जोर दे रहा है।

@petrochenkov

"एक से अधिक प्रकार की व्याख्या" के विरूद्ध एक तर्क यह है कि संघ निरंतर अभिव्यक्तियों में कैसे व्यवहार करता है ...

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

मेरी व्याख्या यह है कि रनटाइम में निष्क्रिय वेरिएंट अभी भी निष्क्रिय हैं लेकिन अगर वे संघ के सक्रिय संस्करण के साथ संगत लेआउट हैं तो एक्सेस किया जा सकता है

हम्म, मैं यह सोचने की कोशिश कर रहा हूं कि यह कहने से कैसे अलग है कि संघ उन सभी प्रकारों के साथ-साथ है। मैं वास्तव में अभी तक एक अंतर नहीं देखता हूं। :)

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

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

मैं यूनियन RFC को कुछ दूरगामी भविष्य में संशोधित करने जा रहा हूँ! "एनम" की व्याख्या के बहुत मजेदार परिणाम हैं।

ऐसा आत्मविश्वास! आप कोशिश करने जा रहे हैं;)

ध्यान रखें कि आपके मन में कौन से ठोस परिवर्तन हैं, इस पर कुछ और जानकारी दें?

ध्यान रखें कि आपके मन में कौन से ठोस परिवर्तन हैं, इस पर कुछ और जानकारी दें?

कार्यान्वयन का अधिक विस्तृत विवरण (अर्थात बेहतर प्रलेखन), कुछ छोटे विस्तार (जैसे खाली संघ और .. संघ पैटर्न में), संघ के विकास के दो मुख्य (विरोधाभासी) विकल्प - अधिक असुरक्षित और कम प्रतिबंधात्मक "खरोंच स्थान" व्याख्या और अधिक सुरक्षित और अधिक प्रतिबंधात्मक "अज्ञात अज्ञात भेदभाव के साथ दुश्मनी" व्याख्या - और चाल / आरंभीकरण चेकर के लिए उनके परिणाम, Copy निहित है, unsafe फ़ील्ड का उपयोग, आदि।

निष्क्रिय संघ क्षेत्र तक पहुँचते समय परिभाषित करना भी उपयोगी होगा, जैसे कि यूबी

union U { a: u8, b: () }
let u = U { b: () };
let a = u.a; // most probably an UB, equivalent to reading from `mem::uninitialized()`

लेकिन यह एक असीम मुश्किल क्षेत्र है।

लगता है कि संभावना है, क्रॉस-फील्ड शब्दार्थ मूल रूप से एक सूचक कास्ट सही हैं?
_ (_) के रूप में * u8)

गुरुवार, 1 सितंबर 2016 को वादिम पेट्रोचेनकोव नोटिफिकेशन @
लिखा था:

निष्क्रिय संघ क्षेत्र तक पहुँचने पर इसे परिभाषित करना भी उपयोगी होगा
यूबी है, उदा

यूनियन U {a: u8, b: ()}
चलो यू = यू {बी: ()};
चलो एक = ua; // सबसे शायद एक यूबी, mem::uninitialized() से पढ़ने के बराबर

लेकिन यह एक असीम मुश्किल क्षेत्र है।

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

क्या फील्ड एक्सेस हमेशा असुरक्षित नहीं है?

गुरुवार, 1 सितंबर 2016 को वादिम पेट्रोचेनकोव नोटिफिकेशन @
लिखा था:

ध्यान रखें कि आपके मन में कौन से ठोस परिवर्तन हैं, इस पर कुछ और जानकारी दें?

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

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

क्या फील्ड एक्सेस हमेशा असुरक्षित नहीं है?

इसे कभी-कभी सुरक्षित किया जा सकता है, जैसे

• तुच्छ-विनाशकारी संघ क्षेत्रों के लिए असाइनमेंट सुरक्षित है।
• union U { f1: T, f2: T, ..., fN: T } (यानी सभी क्षेत्रों का एक ही प्रकार) के क्षेत्रों में कोई भी पहुंच "अज्ञात विवेकहीन व्याख्या" के साथ सुरक्षित है।

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

वर्तमान में गिट से नवीनतम जंग में यूनियनों के लिए समर्थन का परीक्षण। मैंने जो भी कोशिश की है वह पूरी तरह से काम करता है।

मैं डेड फील्ड चेकर में एक दिलचस्प मामले में भाग गया। निम्नलिखित कोड का प्रयास करें:

#![feature(untagged_unions)]

union U {
    i: i32,
    f: f32,
}

fn main() {
    println!("{}", std::mem::size_of::<U>());
    let u = U { f: 1.0 };
    println!("{:#x}", unsafe { u.i });
}

आपको यह त्रुटि मिलेगी:

warning: struct field is never used: `f`, #[warn(dead_code)] on by default

ऐसा लगता है कि dead_code चेकर ने आरंभीकरण को नोटिस नहीं किया।

(मैंने पहले से ही "संरचनात्मक क्षेत्र" के उपयोग के बारे में पीआर # 36252 दायर किया था, इसे केवल "फ़ील्ड" में बदल दिया।)

यूनियनों में वर्तमान में गतिशील रूप से आकार के फ़ील्ड नहीं हो सकते हैं, लेकिन RFC इस व्यवहार को किसी भी तरह से निर्दिष्ट नहीं करता है:

#![feature(untagged_unions)]

union Foo<T: ?Sized> {
  value: T,
}

आउटपुट:

error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> <anon>:4:5
  |
4 |     value: T,
  |     ^^^^^^^^ trait `T: std::marker::Sized` not satisfied
  |
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: only the last field of a struct or enum variant may have a dynamically sized type

प्रासंगिक कीवर्ड मॉड्यूल / टोकरा रूट संदर्भ के बाहर काम नहीं करता है:

fn main() {
    // all work
    struct Peach {}
    enum Pineapple {}
    trait Mango {}
    impl Mango for () {}
    type Strawberry = ();
    fn woah() {}
    mod even_modules {
        union WithUnions {}
    }
    use std;

    // does not work
    union Banana {}
}

एक सुंदर गंदा स्थिरता मस्सा की तरह लगता है।

@nagisa
क्या आप दुर्घटना से जंग के कुछ पुराने संस्करण का उपयोग कर रहे हैं?
मैंने सिर्फ playpen पर आपके उदाहरण की जाँच की है और यह काम करता है (modulo "खाली यूनियन" त्रुटियां)।
इस विशिष्ट स्थिति के लिए एक रन-पास परीक्षण जाँच भी है - https://github.com/rust-lang/rust/blob/master/src/test/run-pass/union/union-backcomp.rs।

@petrochenkov आह, मैंने play.rlo का उपयोग किया है, लेकिन ऐसा लगता है कि यह stable या कुछ और हो सकता है। कभी मन करता है तो कभी।

मुझे लगता है कि यूनियनों को अंततः इस प्रस्ताव से असुरक्षित क्षेत्रों के दुष्ट जुड़वाओं _safe फ़ील्ड_ का समर्थन करने की आवश्यकता होगी।
cc https://github.com/rust-lang/rfcs/issues/381#issuecomment -248707010

मुझे लगता है कि विभिन्न मानदंडों के आधार पर "सुरक्षित यूनियनों" को घोषित करने का एक तरीका होगा।

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

@joshtriplett आपको यह भी सुनिश्चित करने की आवश्यकता होगी कि उन प्रकारों में कोई "छेद" न हो, एकतरफा डेटा पढ़ सकते थे। जैसा कि मैं कहना चाहता हूं: "गैर-संगठित डेटा या तो अप्रत्याशित यादृच्छिक डेटा या आपकी SSH निजी कुंजी है, जो भी बदतर है।"

क्या &T कॉपी और नॉन-ड्रॉप नहीं है? usize "

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

मुझे लगता है कि यह केवल एक ऑफ-द-कफ उदाहरण है, एक गंभीर प्रस्ताव नहीं है, लेकिन यहां कुछ उदाहरण दिए गए हैं कि यह कैसे चाल है:

• u8 और bool का आकार समान है, लेकिन अधिकांश u8 मान bool लिए अमान्य हैं और इस ट्रिगर को अनदेखा कर रहा है UB
• &T और &U एक ही आकार है और कर रहे हैं Copy + !Drop के लिए सभी T और U (दोनों या न रहे, जब तक कि Sized )
• uN / iN और fN बीच संप्रेषण वर्तमान में केवल असुरक्षित कोड में संभव है। मेरा मानना ​​है कि इस तरह के प्रसारण हमेशा सुरक्षित होते हैं लेकिन यह सुरक्षित भाषा को बड़ा करता है इसलिए यह विरोधाभासी हो सकता है।
• गोपनीयता का उल्लंघन करना (जैसे struct Foo(Bar); और Bar बीच का धूर्तता) स्वागत के रूप में कोई बड़ी संख्या नहीं है, क्योंकि गोपनीयता का उपयोग सुरक्षा के लिए प्रासंगिक आक्रमणकारियों को बनाए रखने के लिए किया जा सकता है।

@Amanieu जब मैं लिख रहा था कि, मैं किसी भी आंतरिक पैडिंग नहीं होने के बारे में एक नोट शामिल करना चाहता था, और किसी तरह ऐसा करना भूल गया। उस पकड़ने के लिए धन्यवाद।

@cuviper मैं "सादे पुराने डेटा" को परिभाषित करने की कोशिश कर रहा था, जैसा कि शून्य पॉइंटर्स में कुछ है। आप सही हैं, परिभाषा को संदर्भों को बाहर करने की आवश्यकता होगी। संभवत: उन प्रकारों के अनुमत प्रकारों और संयोजनों का एक सेट व्हाइटलाइनिस्ट के लिए आसान है।

@rkruppe

u8 और बूल का आकार समान है, लेकिन अधिकांश u8 मान बूल के लिए अमान्य हैं और इस ट्रिगर को अनदेखा करते हैं UB

अच्छी बात; यही मुद्दा एनमों पर लागू होता है।

& T और U का आकार एक जैसा है और सभी + और U (जब तक दोनों ही आकार के नहीं हैं) के लिए Copy + Drop हैं।

मैं वह भूल गया था।

यूएन / आईएन और एफएन के बीच प्रसारण वर्तमान में केवल असुरक्षित कोड में संभव है। मेरा मानना ​​है कि इस तरह के प्रसारण हमेशा सुरक्षित होते हैं लेकिन यह सुरक्षित भाषा को बड़ा करता है इसलिए यह विरोधाभासी हो सकता है।

दोनों बिंदुओं पर सहमति; यह अनुमति देने के लिए स्वीकार्य लगता है।

गोपनीयता का उल्लंघन करना (जैसे कि संरचना फू (बार) और बार के बीच चकाचौंध) एक बड़ी संख्या में स्वागत योग्य नहीं है, क्योंकि सुरक्षा के लिए प्रासंगिक आक्रमणकारियों को बनाए रखने के लिए गोपनीयता का उपयोग किया जा सकता है।

यदि आप प्रकार के आंतरिक को नहीं जानते हैं, तो आप यह नहीं जान सकते कि क्या इंटर्न आवश्यकताओं को पूरा करते हैं (जैसे कि कोई आंतरिक पैडिंग नहीं)। इसलिए आप यह सुनिश्चित कर सकते हैं कि सभी घटक सादे-पुराने-डेटा, पुनरावर्ती हों, और यह सत्यापित करने के लिए आपके पास पर्याप्त दृश्यता हो।

यूएन / आईएन और एफएन के बीच प्रसारण वर्तमान में केवल असुरक्षित कोड में संभव है। मेरा मानना ​​है कि इस तरह के प्रसारण हमेशा सुरक्षित होते हैं लेकिन यह सुरक्षित भाषा को बड़ा करता है इसलिए यह विरोधाभासी हो सकता है।

फ्लोटिंग पॉइंट नंबरों में सिग्नलिंग NaN होता है जो एक ट्रैप प्रतिनिधित्व होता है जिसके परिणामस्वरूप UB होता है।

@ retep998 रस्ट किसी भी प्लेटफ़ॉर्म पर चलता है जो फ्लोटिंग-पॉइंट ट्रैप को अक्षम करने का समर्थन नहीं करता है? (यह यूबी मुद्दे को नहीं बदलता है, लेकिन सिद्धांत रूप में हम उस समस्या को दूर कर सकते हैं।)

@petrochenkov

व्याख्या यह है कि संघ एक पहेली है, जिसके लिए हम विवेचक को नहीं जानते हैं, अर्थात हम यह गारंटी दे सकते हैं कि किसी भी समय संघ के कम से कम एक वेरिएंट का वैध मूल्य है

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

#[repr(C)] बारे में प्रश्न: जैसा कि @pnkfelix ने हाल ही में मुझे बताया था, वर्तमान कल्पना बताती है कि यदि कोई संघ #[repr(C)] , तो इसे x फ़ील्ड के साथ संग्रहीत करना और पढ़ना अवैध है फ़ील्ड y । संभवत: ऐसा इसलिए है क्योंकि हमें सभी क्षेत्रों को एक ही ऑफसेट पर शुरू करने की आवश्यकता नहीं है।

मैं इसमें कुछ उपयोगिता देख सकता हूं: उदाहरण के लिए, एक सैनिटाइज़र एक सामान्य एनुम (या यहां तक ​​कि एक संरचना ...) की तरह उन्हें संग्रहीत करके यूनियनों को लागू कर सकता है और जांच कर सकता है कि आप उसी वेरिएंट का उपयोग करते हैं जिसे आप डालते हैं।

_But_ यह एक प्रकार का फुटगन लगता है, और उन रीप्रेंट गारंटियों में से एक हम कभी भी व्यवहार में _actually_ परिवर्तन करने में सक्षम नहीं होंगे, क्योंकि बहुत से लोग जंगली में इस पर निर्भर होंगे।

विचार?

@nikomatsakis

व्याख्या यह है कि संघ एक पहेली है, जिसके लिए हम विवेचक को नहीं जानते हैं, अर्थात हम यह गारंटी दे सकते हैं कि किसी भी समय संघ के कम से कम एक वेरिएंट का वैध मूल्य है

सबसे खराब हिस्सा संस्करण / क्षेत्र के टुकड़े हैं, जो यूनियनों के लिए सीधे सुलभ हैं।
इस कोड पर विचार करें:

union U {
    a: (u8, bool),
    b: (bool, u8),
}
fn main() {
    unsafe {
        let mut u = U { a: (2, false) };
        u.b.1 = 2; // turns union's memory into (2, 2)
    }
}

सभी क्षेत्र Copy , कोई भी स्वामित्व शामिल नहीं है और चेकर चलता है, लेकिन खुश है कि निष्क्रिय क्षेत्र b के आंशिक असाइनमेंट 0 वैध वेरिएंट के साथ राज्य में बदल जाता है। मैंने नहीं सोचा है कि इससे कैसे निपटा जाए। ऐसे करें यूबी? व्याख्या बदलें? कुछ और?

@petrochenkov

ऐसे करें यूबी?

यह मेरी धारणा होगी, हाँ। जब आपने a साथ असाइन किया, तो वेरिएंट b मान्य वेरिएंट के सेट में नहीं था, और इसलिए बाद में u.b.1 (चाहे पढ़ने या असाइन करने के लिए) का उपयोग अमान्य है।

# [ Repr (C)] के बारे में प्रश्न: जैसा कि

मुझे लगता है कि यहां उपयुक्त शब्दांकन यह है कि 1) उन फ़ील्ड्स से पढ़ना जो "लेआउट संगत" नहीं हैं (यह अस्पष्ट है) पहले से लिखे गए फ़ील्ड / फ़ील्ड-टुकड़े के साथ यूबी 2 है) #[repr(C)] यूनियनों के उपयोगकर्ताओं को पता है कि लेआउट क्या हैं (एबीआई डॉक्स से) इसलिए वे यूबी और गैर-यूबी 3 के बीच विचार-विमर्श कर सकते हैं) #[repr(Rust)] यूनियन लेआउट अनिर्दिष्ट हैं इसलिए उपयोगकर्ता यह नहीं कह सकते कि UB क्या है और क्या नहीं है, लेकिन हम (rustc / libstd + अपना) परीक्षण) के पास यह पवित्र ज्ञान है, इसलिए हम गेहूँ को झाड़ू से अलग कर सकते हैं और गैर-यूबी फैशन में #[repr(Rust)] का उपयोग कर सकते हैं।

4) आकार / स्ट्राइड और फील्ड रीऑर्डरिंग प्रश्नों पर निर्णय लेने के बाद, मैं अपेक्षा करता हूं कि मैं स्ट्रक्चर और यूनियन लेआउट को पत्थर और निर्दिष्ट करने की अपेक्षा करूंगा, ताकि उपयोगकर्ता लेआउट को भी जान सकें और #[repr(Rust)] यूनियनों का उपयोग करने में सक्षम हों स्वतंत्र रूप से #[repr(C)] और समस्या दूर हो जाएगी।

@nikomatsakis यूनियन RFC की चर्चा में, लोगों ने देशी रस्ट कोड के लिए इच्छुक लोगों का उल्लेख किया जो कॉम्पैक्ट संरचना संरचनाओं के निर्माण के लिए यूनियनों का उपयोग करता है।

क्या #[repr(C)] का उपयोग करने वाले लोगों से कुछ रुक रहा है? यदि नहीं, तो मुझे #[repr(Rust)] लिए किसी भी प्रकार की गारंटी प्रदान करने की आवश्यकता नहीं है, बस इसे "यहाँ ड्रेगन" के रूप में छोड़ दें। संभवतः एक लिंट का सबसे अच्छा होगा जो डिफ़ॉल्ट रूप से यूनियनों के लिए चेतावनी है जो #[repr(C)] ।

@ retep998 यह मुझे उचित लगता है कि repr(Rust) किसी विशेष लेआउट या ओवरलैप की गारंटी नहीं देता है। मैं बस सुझाव दूंगा कि repr(Rust) को संघ की स्मृति उपयोग के बारे में लोगों की धारणाओं को तोड़ना नहीं चाहिए ("सबसे बड़े सदस्य से बड़ा नहीं")।

क्या रस्ट किसी भी प्लेटफ़ॉर्म पर चलता है जो फ्लोटिंग-पॉइंट ट्रैप को अक्षम करने का समर्थन नहीं करता है?

यह वास्तव में पूछने के लिए एक वैध सवाल नहीं है। सबसे पहले, ऑप्टिमाइज़र स्वयं ट्रैप अभ्यावेदन के यूबी-नेस पर भरोसा कर सकता है और अप्रत्याशित तरीके से कार्यक्रम को फिर से लिख सकता है। इसके अलावा, रस्ट वास्तव में एफपी वातावरण को बदलने का समर्थन नहीं करता है।

लेकिन ऐसा लगता है कि यह एक प्रकार का फुटगन है, और उन पुनर्मुद्रण गारंटीओं में से एक है जो हम वास्तव में व्यवहार में कभी नहीं बदल पाएंगे, क्योंकि बहुत से लोग जंगली में इस पर निर्भर होंगे।

विचार?

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

If: विशेष रूप से प्रभावी अगर लोग किसी कारण से एक गरीब आदमी के संचार के रूप में संघ का उपयोग करना शुरू करते हैं।

किसी संघ के स्मृति उपयोग के बारे में लोगों की धारणाओं को तोड़ना नहीं चाहिए ("सबसे बड़े सदस्य से बड़ा नहीं")।

मैं असहमत हूं। उदाहरण के लिए, कुछ आर्किटेक्चर पर मशीन शब्द के आकार में repr(Rust) सामान का विस्तार करने के लिए यह बहुत समझ में आ सकता है।

स्थिरीकरण से पहले विचार किया जा सकता है कि एक मुद्दा https://github.com/rust-lang/rust/issues/37479 है। लगता है कि LLDB डिबगिंग यूनियनों के सबसे हाल के संस्करण के साथ काम नहीं कर सकते हैं :(

@alexcrichton GDB के साथ काम करता है?

मैं जो बता सकता हूं, हां से। लगता है कि लिनक्स बॉट्स परीक्षण ठीक चल रहा है।

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

यह देखना अच्छा होगा कि क्या हम इस सुविधा को प्राप्त कर सकते हैं FCP 1.17 चक्र के लिए (यह मार्च 16 बीटा है)। क्या कोई भी उत्कृष्ट प्रश्नों और फीचर की वर्तमान स्थिति का सारांश दे सकता है ताकि हम देख सकें कि क्या हम आम सहमति तक पहुँच सकते हैं और सब कुछ हल कर सकते हैं?

@withoutboats
मेरी योजनाएं हैं

• आगामी रिलीज (3 फरवरी) की प्रतीक्षा करें।
• Copy फ़ील्ड के साथ यूनियनों का स्थिरीकरण प्रस्तावित करें। यह एफएफआई की सभी जरूरतों को पूरा करेगा - एफएफआई पुस्तकालय स्थिर पर यूनियनों का उपयोग करने में सक्षम होंगे। "POD" यूनियनों का उपयोग C / C ++ में दशकों तक किया जाता है और अच्छी तरह से समझा जाता है (modulo type based aliasing, लेकिन Rust के पास यह नहीं है), कोई ज्ञात अवरोधक भी नहीं हैं।
• 3 फरवरी तक "यूनियंस 1.2" आरएफसी लिखें। यह यूनियनों के वर्तमान कार्यान्वयन और भविष्य के निर्देशों की रूपरेखा का वर्णन करेगा। गैर- Copy फ़ील्ड के साथ यूनियनों का भविष्य इस RFC पर चर्चा करने की प्रक्रिया में तय किया जाएगा।

ध्यान दें, कि मानक पुस्तकालय से ManuallyDrop या NoDrop तरह कुछ उजागर करना यूनियनों को स्थिर करने की आवश्यकता नहीं है।

स्थिति अद्यतन (4 फरवरी): मैं आरएफसी लिख रहा हूं, लेकिन मैं हमेशा की तरह प्रत्येक वाक्य के बाद लेखक का ब्लॉक ले रहा हूं, इसलिए एक मौका है कि मैं इसे अगले सप्ताह के अंत में समाप्त कर दूंगा (फरवरी 11-12) और इस सप्ताह के अंत में नहीं (फरवरी 4-5)।
स्थिति अद्यतन (11 फरवरी): पाठ 95% तैयार है, मैं इसे कल जमा करूंगा।

@petrochenkov कार्रवाई की एक बहुत ही उचित पाठ्यक्रम की तरह लगता है।

@petrochenkov यह मुझे उचित लगता है। मैंने आपके यूनियनों 1.2 प्रस्ताव की भी समीक्षा की, और कुछ टिप्पणियां प्रदान कीं; कुल मिलाकर, यह मुझे अच्छा लग रहा है।

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

इसलिए, मैंने "यूनियंस 1.2" आरएफसी - https://github.com/rust-lang/rfcs/pull/1897 जमा किया है।

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

"यूनियन्स 1.2" आरएफसी का पाठ वास्तव में एफएफआई-शैली के यूनियनों के बारे में कुछ भी नया नहीं बताता है, सिवाय इसके कि यह स्पष्ट रूप से पुष्टि करता है कि टाइपिंग की अनुमति है।
संपादित करें : "यूनियन 1.2" आरएफसी भी तुच्छ-विनाशकारी Copy फ़ील्ड्स को सुरक्षित करने के लिए कार्य करने जा रहा है (देखें https://github.com/rust-lang/rust/issues/32836#uuecomment-281296416, https) : //github.com/rust-lang/rust/issues/32836#issuecomment-281748451), यह एफएफआई-शैली के यूनियनों को भी प्रभावित करता है।

यह पाठ स्थिरीकरण के लिए आवश्यक दस्तावेज भी प्रदान करता है।
"अवलोकन" अनुभाग को पुस्तक में कॉपी किया जा सकता है और संदर्भ में "विस्तृत डिजाइन"।

ping @nikomatsakis

क्या वास्तव में इस तरह की चीज़ को भाषा के हिस्से के रूप में जोड़ा जाना चाहिए? थोड़ा unsafe और ptr::write() का उपयोग करके संघ के कार्यान्वयन में दस्तक देने में मुझे लगभग 20 मिनट लगे।

use std::mem;
use std::ptr;


/// A union of `f64`, `bool`, and `i32`.
#[derive(Default, Clone, PartialEq, Debug)]
struct Union {
    data: [u8; 8],
}

impl Union {
    pub unsafe fn get<T>(&self) -> &T {
        &*(&self.data as *const _ as *const T)
    }

    pub unsafe fn set<T>(&mut self, value: T) {
        // "transmute" our pointer to self.data into a &mut T so we can 
        // use ptr::write()
        let data_ptr: &mut T = &mut *(&mut self.data as *mut _ as *mut T);
        ptr::write(data_ptr, value);
    }
}


fn main() {
    let mut u = Union::default();
    println!("data: {0:?} ({0:#p})", &u.data);
    {
        let as_i32: &i32 = unsafe { u.get() };
        println!("as i32: {0:?} ({0:#p})", as_i32);
    }

    unsafe {
        u.set::<f64>(3.14);
    }

    println!("As an f64: {:?}", unsafe { u.get::<f64>() });
}

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

मुझे लगता है कि वे कुछ इस तरह लिख सकते हैं:

union! { Foo(u64, Vec<u8>, String) };

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

@ माइकल-एफ-ब्रायन हमारे पास निरंतर size_of अभी तक नहीं है।

@ माइकल-एफ-ब्रायन यह [u8] सरणी के लिए पर्याप्त नहीं है, आपको संरेखण को सही करने की भी आवश्यकता है। मैं वास्तव में पहले से ही यूनियनों को संभालने के लिए मैक्रोज़ का उपयोग करता हूं, लेकिन निरंतर size_of और align_of की कमी के कारण मुझे मैन्युअल रूप से सही स्थान आवंटित करना होगा, क्योंकि घोषणात्मक मैक्रोज़ I में कोई उपयोग करने योग्य पहचान नहीं है। मैन्युअल रूप से दोनों गेटर्स और सेटर के लिए नाम निर्दिष्ट करें। यहां तक ​​कि सिर्फ एक यूनियन को इनिशियलाइज़ करना इस समय कठिन है क्योंकि मुझे पहले इसे कुछ डिफॉल्ट वैल्यू के साथ इनिशियलाइज़ करना है और उसके बाद वैल्यू को उस वेरिएबल में सेट करना है जो मैं चाहता हूँ (या यूनियन के निर्माण के लिए दूसरे तरीके को जोड़ूँ जो परिभाषा में और भी अधिक वर्बोसिटी है। संघ का)। यह समग्र रूप से बहुत अधिक काम है और यूनियनों के लिए मूल समर्थन की तुलना में त्रुटि और बदसूरत होने का खतरा है। हो सकता है कि आपको RFC और उसके साथ हुई चर्चा को पढ़ना चाहिए ताकि आप समझ सकें कि यह विशेषता इतनी महत्वपूर्ण क्यों है।

और संरेखण के लिए समान।

मुझे लगता है कि पहचान का पता लगाना बहुत मुश्किल नहीं होना चाहिए अब syn मौजूद है। यह आपको पास किए गए एएसटी पर संचालन करने की अनुमति देता है, इसलिए आप दो आइडेंट ले सकते हैं, उनके स्ट्रिंग प्रतिनिधित्व को निकाल सकते हैं ( Ident लागू AsRef<str> ), फिर एक नया Ident बनाएँ Ident::From<String>() का उपयोग करके दोनों का संघटन है।

RFC ने इस बारे में बहुत कुछ उल्लेख किया है कि मौजूदा मैक्रो कार्यान्वयन कैसे उपयोग करने के लिए बोझिल हैं, हालांकि syn और quote जैसे टोकरे के हाल के निर्माण के साथ, अब मैक्रो की खरीद करना बहुत आसान है। मुझे लगता है कि एर्गोनॉमिक्स को बेहतर बनाने की दिशा में एक लंबा रास्ता तय करना होगा और चीजों को कम त्रुटि वाला बनाना होगा।

उदाहरण के लिए, आपके पास MyUnion::default() जो कि संघ के आंतरिक बफर का केवल शून्य है, फिर fn MyUnion::new<T>(value:T) -> MyUnion , जहां T का एक ऐसा गुण है जो यह सुनिश्चित करता है कि आप केवल सही प्रकारों के साथ आरंभ कर सकते हैं ।

संरेखण और आकार के संदर्भ में, क्या आप मानक पुस्तकालय से mem मॉड्यूल का उपयोग करने में सक्षम हैं (यानी std :: mem :: align_of () और मित्र)? मुझे लगता है कि मैं जो कुछ भी प्रस्तावित कर रहा हूं वह आकार और संरेखण की आवश्यकता का पता लगाने के लिए मैक्रो विस्तार समय पर उन का उपयोग करने में सक्षम होने पर निर्भर करेगा। 99.9% यूनियनों का उपयोग वैसे भी आदिम प्रकारों के साथ किया जाता है, इसलिए मुझे ऐसा लगता है कि आप एक सहायक फ़ंक्शन लिख पाएंगे जो एक प्रकार का नाम लेता है और इसके संरेखण या आकार (संभवतः संकलक से पूछ रहा है) देता है, हालांकि यह अधिक है एक कार्यान्वयन विस्तार)।

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

संरेखण और आकार के संदर्भ में, क्या आप मानक पुस्तकालय से मेम मॉड्यूल का उपयोग करने में सक्षम हैं (यानी std :: mem :: align_of () और मित्र)?

यह किसी भी क्रॉस संकलन के संदर्भ में काम करने वाला नहीं है।

@ माइकल-एफ-ब्रायन इन सभी चर्चाओं और बहुत से इतिहास के https://github.com/rust-lang/rfcs/pull/1444 में थे । पहले से ही उल्लेख किए गए लोगों के अलावा, आपकी विशिष्ट चिंताओं के जवाबों को संक्षेप में प्रस्तुत करने के लिए: आपको हर लक्ष्य प्लेटफॉर्म / कंपाइलर के पैडिंग और संरेखण नियमों को फिर से लागू करना होगा, और अपने एफएफआई कोड (जो कि @ retep88 ) में वास्तव में अजीब सिंटैक्स का उपयोग करें विंडोज बाइंडिंग के लिए बड़े पैमाने पर और अजीबता के लिए वाउच कर सकते हैं)। इसके अलावा, खरीद मैक्रो वर्तमान में केवल व्युत्पन्न के लिए काम करते हैं; आप सिंटैक्स को कहीं और नहीं बढ़ा सकते।

इसके अलावा:

99.9% समय यूनियनों का उपयोग किया जाता है, यह वैसे भी आदिम प्रकारों के साथ किया जाता है

सच नहीं है। C कोड व्यापक रूप से "संघों के संघों की संरचना" पैटर्न का उपयोग करता है, जहां अधिकांश संघ क्षेत्रों में विभिन्न संरचना प्रकार होते हैं।

@rfcbot fcp मर्ज प्रति @petrochenkov की टिप्पणी https://github.com/rust-lang/rust/issues/32836#issuecomment -279256434

मेरे पास जोड़ने के लिए कुछ भी नहीं है, बस बॉट को ट्रिगर करना है

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

• [x] @ न्यूटन
• [x] @ हेड्डी
• [x] @ मुनोमकोत्सकिस
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

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

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

टीम के सदस्य मुझे क्या टैग दे सकते हैं, इसके बारे में जानकारी के लिए यह दस्तावेज़ देखें।

PSA: मैं "Unions 1.2" RFC को FFI- शैली यूनियनों को प्रभावित करने वाले एक और बदलाव के साथ अपडेट करने जा रहा हूं - मैं RFC को "भविष्य के निर्देश" से यूनियनों के तुच्छ-विनाशकारी क्षेत्रों के लिए सुरक्षित असाइनमेंट स्थानांतरित करूंगा।

union.trivially_destructible_field = 10; // safe

क्यों:

• संघ की व्याख्या की परवाह किए बिना, तुच्छ-विनाशकारी संघ क्षेत्रों को असाइनमेंट बिना शर्त सुरक्षित हैं।
• यह संघ से संबंधित unsafe ब्लॉकों का लगभग आधा हिस्सा निकाल देगा।
• स्थिर कोड में unused_unsafe चेतावनियों / त्रुटियों की संभावित बड़ी संख्या के कारण बाद में करना कठिन होगा।

@petrochenkov क्या आपका मतलब है "तुच्छ विध्वंसक संघ के क्षेत्र", या "पूरी तरह से विनाशकारी क्षेत्रों के साथ संघ"?

क्या आप प्रस्ताव कर रहे हैं कि सभी असुरक्षित व्यवहार पढ़ने पर होते हैं, जहाँ आप एक व्याख्या चुनते हैं? उदाहरण के लिए, एक एनुम और अन्य क्षेत्रों से युक्त एक संघ होना, जहां संघ मूल्य में एक अमान्य भेदभाव है?

उच्च स्तर पर जो प्रशंसनीय लगता है। यह कुछ ऐसी चीज़ों की अनुमति देता है जिन्हें मैं असुरक्षित मानूंगा, लेकिन सामान्य तौर पर जंग ऐसे नहीं होती है, जैसे कि विध्वंसक को नष्ट करना या मेमोरी को लीक करना। निम्न स्तर पर, मैं उस ध्वनि पर विचार करने में संकोच करूंगा।

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

@joshtriplett
"तुच्छ रूप से विनाशकारी क्षेत्र", मैंने शब्दांकन को बदल दिया है।

क्या आप प्रस्ताव कर रहे हैं कि सभी असुरक्षित व्यवहार पढ़ने पर होते हैं, जहाँ आप एक व्याख्या चुनते हैं?

हाँ। बाद में लिखे बिना कुछ भी अकेले खतरनाक नहीं हो सकता।

संपादित करें:

मुझे लगता है कि असुरक्षित (सिर्फ डेरेफेरिंग पॉइंटर्स) की "न्यूनतम" धारणा बनाने के हमारे प्रयासों में एक गलती थी, रेट्रोस्पेक्ट में

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

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

@nrc
ठीक है, उपसमुच्चय स्पष्ट है - "एफएफआई यूनियन्स", या "सी यूनियन्स", या "प्री-सी ++ 11 यूनियन्स" - भले ही यह वाक्यात्मक नहीं है। मेरा प्रारंभिक लक्ष्य इस सबसेट ASAP (यह चक्र, आदर्श रूप से) को स्थिर करना था, इसलिए इसे winapi जैसे पुस्तकालयों में उपयोग किया जा सकता है।
शेष उपसमुच्चय और इसके कार्यान्वयन के बारे में विशेष रूप से संदिग्ध नहीं है, यह सिर्फ जरूरी नहीं है और "यूनियंस 1.2" आरएफसी के लिए प्रक्रिया पूरी होने तक अस्पष्ट राशि की प्रतीक्षा करने की आवश्यकता नहीं है। मेरी उम्मीद है कि शुरुआती सबसेट के स्थिरीकरण के बाद शेष भागों को 1, 2 या 3 चक्रों में स्थिर किया जाएगा।

मुझे लगता है कि मेरे पास सुरक्षित क्षेत्र असाइनमेंट के लिए एक अंतिम तर्क है।
असुरक्षित क्षेत्र असाइनमेंट

unsafe {
    u.trivially_destructible_field = value;
}

सुरक्षित पूर्ण संघ कार्य के बराबर है

u = U { trivially_destructible_field: value };

सिवाय इसके कि सुरक्षित संस्करण विरोधाभासी रूप से कम सुरक्षित है क्योंकि यह u बाइट्स को trivially_destructible_field से बाहर की ओर से अधिलेखित कर देगा, जबकि फ़ील्ड असाइनमेंट ने उन्हें छोड़ने के बारे में गारंटी दी है।

@petrochenkov उस का चरम size_of_val(&value) == 0 , है ना?

यदि प्रश्न में फ़ील्ड है, तो दो स्निपेट के बीच समानता केवल सच है
"तुच्छ विनाशकारी", नहीं?

इस लिहाज से ये सुरक्षित लेकिन कुछ मामलों में ही काम कर रहे हैं
मुझे बहुत असंगत लगता है।

फरवरी 22, 2017 14:50 पर, "वादिम पेट्रोचेनकोव" सूचनाएं @github.com
लिखा था:

मुझे लगता है कि मेरे पास सुरक्षित क्षेत्र असाइनमेंट के लिए एक अंतिम तर्क है।
असुरक्षित क्षेत्र असाइनमेंट

असुरक्षित {
u.trivially_destructible_field = value;
}

सुरक्षित पूर्ण संघ कार्य के बराबर है

u = U {trivially_destructible_field: value};

सिवाय इसके कि सुरक्षित संस्करण विरोधाभासी रूप से कम सुरक्षित है क्योंकि यह होगा
ओवरवेट के साथ trivially_destructible_field के बाहर यू के बाइट्स को ओवरराइट करें,
फील्ड असाइनमेंट के दौरान उन्हें बरकरार रखने की गारंटी होती है।

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

@eddyb

इसके चरम का आकार size_of_val (& value) == 0, सही है?

हां।

@nagisa
मुझे समझ में नहीं आता है कि झूठी सकारात्मकता के बड़े हिस्से को समाप्त करने वाला एक अतिरिक्त सरल नियम अत्यंत असंगत क्यों है। "केवल कुछ मामले" विशेष रूप से सभी एफएफआई यूनियनों को कवर करते हैं।
मुझे लगता है कि "बेहद असंगत" एक बड़ा overestimation है। जितना बड़ा "केवल mut चर नहीं सौंपा जा सकता; भयानक असंगति!", लेकिन अभी भी इस दिशा में जा रहा है।

@petrochenkov कृपया ऐसे मामले पर विचार करें:

// Somebody Somewhere in some crate (v 1.0.0)
struct Peach; // trivially destructible
union Banana { pub actually: Peach }

// Somebody Else in their dependent crate
extern some crate;
fn somefn(banana: &mut Banana) {
    banana.actually = Peach;
}

अब चूंकि ट्रेस कार्यान्वयन को जोड़ना आम तौर पर एक ब्रेकिंग परिवर्तन नहीं है, मि।

impl Drop for Peach { fn drop(&mut self) { println!("Moi Peach!") }

और टोकरा के संस्करण 1.1.0 (1.0.0 AFAIK के साथ संगत) जारी करें।

अचानक मिस्टर एबॉडी एल्स का क्रेट अब संकलित नहीं है:

fn somefn(banana: &mut Banana) {
    banana.actually = Peach; // ERROR: Something something… unsafe assingment… somewhat somewhat trivially indestructible… 
}

और इसलिए कभी-कभी संघ के क्षेत्रों में सुरक्षित असाइनमेंट की अनुमति देना केवल mut स्थानीय लोगों के रूप में तुच्छ नहीं है।

जैसा कि मैंने इस उदाहरण के नीचे लिखा है कि मैं अनिश्चित हो गया हूं

@nagisa
यह एक अच्छा तर्क है, मैंने संगतता के बारे में नहीं सोचा था।

समस्या हालांकि हल करने योग्य लगती है। अनुकूलता के मुद्दों से बचने के लिए वैसा ही करें जैसा कि सुसंगतता है - नकारात्मक तर्क से बचें। यानी "trivially-destructible" == "कोई भी घटक निकटतम सकारात्मक सन्निकटन के साथ Drop " लागू नहीं करता है - " Copy " लागू करता है।
Copy प्रकार Copy पिछड़े-अनुकूलता से लागू नहीं कर सकते हैं, और Copy प्रकार अभी भी "तुच्छ-विनाशकारी" प्रकार के बहुमत का प्रतिनिधित्व करते हैं, विशेष रूप से एफएफआई आयनों के संदर्भ में।

Drop करना पहले से ही पीछे की ओर संगत नहीं है और इसका यूनियन सुविधा से कोई लेना-देना नहीं है:

// Somebody Somewhere in some crate (v 1.0.0)
struct Apple; // trivially destructible
struct Pineapple { pub actually: Apple }

// Somebody Else in their dependent crate
extern some crate;
fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually
}

// some crate v 1.1.0
impl Drop for Pineapple { fn drop(&mut self) { println!("Moi Pineapple!") }

fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually // ERROR: can't move out of Pineapple
}

जो बदले में ड्रॉप ड्रॉप इंप्लांट कॉपी को लागू करने जैसा लगता है। और कॉपी करें
पर निर्भर किया जा सकता है।

बुध पर, 22 फरवरी, 2017 को प्रातः 10:11 बजे, jethrogb सूचनाएं @github.com ने लिखा:

कार्यान्वयन ड्रॉप पहले से ही पीछे-संगत नहीं है और इसमें है
संघ सुविधा से कोई लेना देना नहीं:

// किसी को कहीं कोई टोकरा (v। 1.0.0)
संरचना Apple; // तुच्छ रूप से विनाशकारी
संरचना अनानास {पब वास्तव में: सेब}

// कोई और अपने आश्रित टोकरे में
कुछ टोकरा बाहर करो;
fn अनानास_तो_पल (अनानास: अनानास) -> सेब {
pineapple.actually
}

// कुछ टोकरा v 1.1.0
अनानास के लिए ड्रॉप छोड़ना {fn ड्रॉप (और म्युट सेल्फ) {प्रिंटलेन! "(मोइ पाइनएप्पल!")।

fn अनानास_तो_पल (अनानास: अनानास) -> सेब {
banana.actually // ERROR: अनानास से बाहर नहीं जा सकता
}

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

@jethrogb
मैं इस मुद्दे का उल्लेख करना चाहता था, लेकिन ऐसा नहीं था क्योंकि इसमें कुछ विशेष प्राथमिकताएं नहीं थीं - Drop लागू करने वाली संरचना में सार्वजनिक क्षेत्र होना चाहिए और वह क्षेत्र Copy नहीं होना चाहिए। संघ का मामला बिना शर्त सभी संरचनाओं को प्रभावित करता है।

@petrochenkov मुझे लगता है कि शायद एक तर्क है कि एक संघ बनाने असुरक्षित होना चाहिए :)

@petrochenkov एक सबसेट को स्थिर करने के लिए विकास और रात-उपयोगकर्ता-अनुभव पथ क्या है? क्या हम सबसे पहले सबसेट के लिए एक नया फीचर गेट जोड़ते हैं, ताकि लोग स्थिर होने से पहले ही सब्मिट का उपयोग करके ठोस अनुभव प्राप्त कर सकें?

@pnkfelix
मैंने जो माना, वह इस उपसमुच्चय के लिए #[feature(untagged_unions)] आवश्यकता है, कोई नई सुविधाएँ या अन्य नौकरशाही नहीं है।
एफएफआई-शैली के यूनियनों को सबसे अधिक बार इस्तेमाल किए जाने वाले यूनियनों के रूप में माना जाता है, इसलिए एक नई सुविधा का मतलब स्थिरीकरण से ठीक पहले टूटना होगा, जो मुझे लगता है, कष्टप्रद होगा।

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

@ retep998
पैकिंग? यदि आपका मतलब #[repr(packed)] तो यह अभी यूनियनों पर समर्थित है ( align(>1) विशेषताओं के विपरीत)।

@petrochenkov #[repr(packed(N))] । वाइनपी में 1 के अलावा अन्य पैकिंग काफी आवश्यक है। ऐसा नहीं है कि मुझे विशेष रूप से यूनियनों पर समर्थित इन चीजों की आवश्यकता है, मैं सिर्फ अपनी न्यूनतम जंग आवश्यकता को बढ़ाने के लिए एक नए प्रमुख संस्करण पर कूदना नहीं चाहता जब तक कि मुझे उन सभी चीजों को एक ही समय में नहीं मिल सकता।

यहाँ खेलने की स्थिति को स्पष्ट करने के लिए:

वर्तमान FCP प्रस्ताव शुद्ध- Copy यूनियनों के लिए ही है। यही कारण है कि, जहां तक ​​मुझे जानकारी है, मूल रूप से "क्या हमें स्थिर होना चाहिए?" गति के बाद से चर्चा FCP सब नए RFC के बारे में @petrochenkov रहा है ।

IRC पर चर्चा से @nrc और @nikomatsakis , मुझे संदेह है कि आप दोनों अपने बक्से की जांच करने के लिए तैयार हैं, लेकिन मैं आपको छोड़ दूँगा;;

: घंटी: यह अब ऊपर की अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । : घंटी:

@petrochenkov
यह मुझे लगता है कि यह एक विचार से लाभ होगा जो मैंने हाल ही में मंगाई थी। (Https://internals.rust-lang.org/t/automatic-marker-trait-for-unconditionally-valid-repr-c-types/5054)

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

एफएफआई के संदर्भ में, Plain को परिभाषित किया जाना भी इस तरह के कोड के लिए कई मामलों में ध्वनि की एक वास्तविक आवश्यकता है, जबकि ऐसे मामले जहां गैर- Plain प्रकार उपयोगी होते हैं, स्थापित करना दुर्लभ और कठिन है। सुरक्षित रूप से।

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

@ Le-jzr
यह यूनियनों को पर्याप्त रूप से रूढ़िवादी लगता है।
मैं निकट भविष्य में जंग में Plain को स्वीकार करने का अनुमान लगाऊंगा, क्योंकि बहुत संभावना नहीं है + संघ क्षेत्रों के लिए अधिक पहुंच बनाने से कम या ज्यादा पिछड़े संगत (पूरी तरह से लिन्ट्स के कारण नहीं) है, इसलिए मैं यूनियनों के कारण देरी नहीं करूंगा यह करने के लिए।

@petrochenkov मैं अपने प्रस्ताव पर किसी भी बंद के इंतजार में यूनियनों को देरी करने का सुझाव नहीं दे रहा हूं, बल्कि अपने दम पर इस तरह के संभावित प्रतिबंधों के _existence_ पर विचार कर रहा हूं। भविष्य में संघ के क्षेत्रों में अधिक पहुंच बनाने से बाधाओं का सामना करना पड़ सकता है क्योंकि यह भाषा में अधिक असंगति पैदा करता है। विशेष रूप से, इसे बनाना ताकि क्षेत्र पहुंच की सुरक्षा एक क्षेत्र से दूसरे क्षेत्र में भिन्न हो, बदसूरत लगती है।

इसलिए घोषणा को unsafe union करने का मेरा सुझाव है, ताकि बिना किसी नए कीवर्ड को जोड़े बिना बिना सुरक्षित उपयोग के संस्करण को बाद में पेश किया जा सके। यह ध्यान देने योग्य है कि पूरी तरह से सुरक्षित-से-उपयोग संस्करण अधिकांश उपयोग के मामलों के लिए पर्याप्त है।

संपादित करें: मेरे कहने का मतलब स्पष्ट करने की कोशिश की गई।

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

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

अब जब कि FCP विलय करने के लिए पूरा हो गया है, तो यहां अगला कदम क्या है? 1.19 के लिए इसे स्थिर करना अच्छा होगा।

@bstrie तो आप एक सुविधा को स्थिर करना चाहते हैं

यदि कोई उस @rfcbot संदेश ( यहाँ स्रोत कोड ) में अधिक विवरण जोड़ सकता है तो यह बहुत बढ़िया होगा। यह इस प्रक्रिया से अपरिचित किसी व्यक्ति के लिए चीजों को कूदने और स्थानांतरित करने के लिए आसान बना सकता है।

इसे १.१ ९ में लाने का रास्ता साफ है। इसके लिए हुक पर कोई भी? cc @joshtriplett

क्या NonZero enum लेआउट अनुकूलन union माध्यम से लागू करने की गारंटी है? उदाहरण के लिए, Option<ManuallyDrop<&u32>> को शून्य सूचक के रूप में None प्रतिनिधित्व नहीं करना चाहिए। Some(ManuallyDrop::new(uninitialized::<[Vec<Foo>; 10]>())).is_some() को बिन बुलाए मेमोरी नहीं पढ़नी चाहिए।

इससे निपटने के लिए https://crates.io/crates/arrayvec में उपयोग किया गया) हैक्स है।

@SimonSapin
यह वर्तमान में RFC में एक अनसुलझे प्रश्न के रूप में चिह्नित है।
वर्तमान कार्यान्वयन में यह कार्यक्रम

#![feature(untagged_unions)]

struct S {
    _a: &'static u8
}
union U {
    _a: &'static u8
}

fn main() {
    use std::mem::size_of;
    println!("struct {}", size_of::<S>());
    println!("optional struct {}", size_of::<Option<S>>());
    println!("union {}", size_of::<U>());
    println!("optional union {}", size_of::<Option<U>>());
}

प्रिंट

struct 8
optional struct 8
union 8
optional union 16

, यानी अनुकूलन प्रदर्शन नहीं किया है।
cc https://github.com/rust-lang/rust/issues/36394

यह 1.19 बनाने की संभावना नहीं है।

@brson

यह 1.19 बनाने की संभावना नहीं है।

स्थिरीकरण पीआर विलय कर दिया जाता है।

अब 1.19 में अप्रकाशित यूनियनों के साथ शिपिंग (https://github.com/rust-lang/rust/pull/42068 के हिस्से में) - क्या इस मुद्दे पर कुछ शेष है या हमें बंद करना चाहिए?

@jonathandturner
अभी भी गैर- Copy फ़ील्ड के साथ यूनियनों की एक पूरी दुनिया है!
प्रगति ज्यादातर स्पष्टीकरण / प्रलेखन RFC (https://github.com/rust-lang/rfcs/pull/1897) पर अवरुद्ध है।

क्या अगस्त से गैर- Copy फ़ील्ड के साथ यूनियनों पर कोई प्रगति हुई है? यूनियंस 1.2 आरएफसी ठप हो गया है (मैं अनुमान लगा रहा हूं कि अवधि क्या है?)

यूनियनों में ?Sized प्रकारों की अनुमति - यदि केवल एक प्रकार के यूनियनों के लिए - तो https://github.com/rust-lang/rust/issues/47034 को लागू करना आसान होगा:

`` `जंग
यूनियन मैनुवलड्रॉप{
मूल्य: टी
}

@ मिकीय्यूह आपको वास्तव में केवल एक प्रकार से

मैं union s का उपयोग करके कुछ रस्ट कोड देख रहा हूं, और यह पता नहीं है कि यह अपरिभाषित व्यवहार को आमंत्रित करता है या नहीं।

संदर्भ [आइटम :: यूनियनों] में केवल उल्लेख है:

यदि वे संघ द्वारा रखे गए वर्तमान मूल्य के साथ पर्याप्त रूप से लेआउट के अनुकूल हैं तो निष्क्रिय क्षेत्रों (समान सिंटैक्स का उपयोग करके) तक पहुँचा जा सकता है। असंगत क्षेत्रों को पढ़ने से अपरिभाषित व्यवहार होता है।

लेकिन मैं "लेआउट संगत" की परिभाषा को न तो [आइटम :: यूनियनों] में और न ही [type_system :: type_layout] में देख सकता हूं ।

RFC के माध्यम से देखने से मुझे "लेआउट संगत" की परिभाषा नहीं मिल पाई है, RFC 1897 में क्या काम करना चाहिए और क्या नहीं करना चाहिए, केवल हाथ से लहराए गए उदाहरण

RFC1444: यूनियनें केवल तब तक अपने वैरिएंट्स को एक यूनियन ट्रांसमिट करने की अनुमति देती हैं, जब तक कि यह अपरिभाषित व्यवहार को लागू नहीं करता है, लेकिन जब ऐसा नहीं होता है तो मैं RFC में कहीं भी नहीं मिल सकता।

क्या _precise_ नियम हैं जो मुझे बताते हैं कि क्या यूनियनों का उपयोग करने वाले कोड के एक टुकड़े ने कहीं लिखा हुआ व्यवहार परिभाषित किया है (और क्या परिभाषित व्यवहार है)?

@gnzlbg पहले सन्निकटन के लिए: आप पैडिंग का उपयोग नहीं कर सकते हैं, एक अवैध

यदि आप यूनियनों से जुड़े विशिष्ट कोड की ओर इशारा करते हैं, तो हम इसे देख सकते हैं और बता सकते हैं कि क्या यह अपरिभाषित है।

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

वास्तव में नवीनतम आम सहमति यह है कि मनमानी तैरना पढ़ना ठीक है (# 46012)।

मैं एक और आवश्यकता जोड़ूंगा: दोनों स्रोत और लक्ष्य यूनियन वैरिएंट #[repr(C)] और इसलिए यदि वे संरचित हैं तो उनके सभी क्षेत्र (और पुनरावर्ती) हैं।

@Amanieu मैं सही खड़ा है, धन्यवाद।

इसलिए मुझे लगता है कि नियम कहीं नहीं लिखे गए हैं?

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

https://github.com/rust-lang-nursery/stdsimd/blob/03cb92ddce074a5170ed5e5c5c20e5fa4e4846c3/coresimd/src/x86/test.rs#L17

AFAIK एक संघ क्षेत्र लिख रहा है और दूसरा पढ़ना उसी प्रतिबंध के साथ transmute_copy का उपयोग करना पसंद कर रहा है। उन प्रतिबंधों को अभी भी थोड़ा अस्पष्ट है संघ-विशिष्ट नहीं है।

उस मामले के लिए, आपके द्वारा जोड़ा गया फ़ंक्शन केवल transmute::<__m128d, [f64; 2]> उपयोग कर सकता है। हालांकि यूनियन संस्करण यकीनन अच्छा है, कम से कम एक बार ट्रांसमिट जो वर्तमान में है उसे हटा दिया गया है: यह सिर्फ A { a }.b[idx] ।

@rkruppe मैंने उस लिंट को जोड़ने के लिए एक https://github.com/rust-lang-nursery/rust-clippy/issues/2361

आपके द्वारा जोड़ा गया फ़ंक्शन केवल ट्रांसमिट का उपयोग कर सकता है :: <__ m128d i = "8">

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

मुझे लगता है कि इससे मुझे मदद मिलती अगर भाषा के संदर्भ में यूनियनों ने यूनियनों के लिए नियमों को ट्रांसमिट के संदर्भ में निर्दिष्ट किया होता (भले ही ट्रांसमिट के नियम अभी तक 100% स्पष्ट नहीं हैं) केवल "लेआउट संगतता" का उल्लेख करने और छोड़ने के बजाय उस पर। "लेआउट संगतता" से छलांग "अगर ट्रांसमिट अपरिभाषित व्यवहार को लागू नहीं करता है, तो प्रकार लेआउट संगत हैं और प्रकार के माध्यम से पहुँचा जा सकता है" मेरे लिए स्पष्ट नहीं था।

स्पष्ट होने के लिए, संचार [_copy] यूनियनों की तुलना में "अधिक आदिम" नहीं है। वास्तव में transmute_copy का शाब्दिक अर्थ है सूचक as कास्ट और ptr::read । transmute अतिरिक्त रूप से mem::uninitialized (पदावनत) या MaybeUninitialized (एक संघ) या ऐसा ही कुछ और चाहिए, और प्रभावकारिता के लिए आंतरिक रूप में लागू किया जाता है, लेकिन यह भी एक प्रकार से नीचे आ जाता है- धूर्त मेमकी। मुख्य कारण जो मैंने प्रसारण के लिए कनेक्शन को आकर्षित किया है, क्योंकि यह पुराने और ऐतिहासिक रूप से अधिक जोर दिया गया है और इसलिए वर्तमान में हमारे पास अधिक लेखन और लोककथाओं का ज्ञान है जो विशेष रूप से प्रसारण पर केंद्रित है। वास्तविक अंतर्निहित अवधारणा, जो यह निर्धारित करती है कि क्या मान्य है और क्या नहीं (और जो एक युक्ति का वर्णन करेगा), यह है कि मूल्यों को बाइट्स के रूप में मेमोरी में कैसे संग्रहीत किया जाता है और किस प्रकार के रूप में पढ़ने के लिए यूबी अनुक्रम हैं।

सुधार: ट्रांसमीट को वास्तव में अनइंस्टाल्यूटेड स्टोरेज (आंतरिक, या यूनियनों के माध्यम से, या अन्यथा) की आवश्यकता नहीं है। एक तरफ दक्षता, आप इस तरह से कुछ कर सकते हैं (अछूता, शर्मनाक टाइपोस हो सकते हैं):

fn transmute<T, U>(x: T) -> U {
    assert!(size_of::<T>() == size_of::<U>());
    let mut bytes = [0u8; size_of::<U>()];
    ptr::write(bytes.as_mut_ptr() as *mut T, x);
    mem::forget(x);
    ptr::read(bytes.as_ptr() as *const U)
}

संचारण का एकमात्र "जादुई" हिस्सा यह है कि यह संकलन समय पर समान आकार के होने के लिए प्रकार के मापदंडों को बाध्य कर सकता है।

संदर्भ और यूनियंस 1.2 आरएफसी जानबूझकर इस मामले पर अस्पष्ट हैं क्योंकि सामान्य रूप से प्रसारित करने के नियमों का निपटान नहीं किया जाता है।
आशय यह था कि " repr(C) यूनियनों में तृतीय-पक्ष ABI विशिष्टताओं को देखें, repr(Rust) यूनियनों के लिए लेआउट संगतता ज्यादातर अनिर्दिष्ट है (जब तक कि यह नहीं है)"।

क्या बूंदों के साथ यूनियनों के ड्रॉप चेक शब्दार्थ को फिर से देखना देर हो गई है?

मूल मुद्दा यह है कि ManuallyDrop जोड़ने से जोसेफिन अस्वस्थ हो गईं, क्योंकि यह (बल्कि

एक छीन लिया गया उदाहरण https://play.rust-lang.org/?gist=607e2dfbd51f4062b9dc93d149815695&version=nightly पर है। विचार यह है कि एक प्रकार Pin<'a, T> , एक विधि pin(&'a self) -> &'a T जिसकी सुरक्षा " pin.pin() कॉल करने के बाद" इनवेरिएंट पर निर्भर करती है, यदि पिन का समर्थन करने वाली मेमोरी कभी भी पुनः प्राप्त होती है, पिन का विध्वंसक चला गया होगा ”।

इस अपरिवर्तनीय को रुस्त द्वारा #[allow(unions_with_drop_fields)] जोड़ा गया था, और ManuallyDrop https://doc.rust-lang.org/src/core/mem.rs.html#949 तक उपयोग किया गया था

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

IRC वार्तालाप: https://botbot.me/mozilla/rust-lang/2018-02-01/?msg=96386869&page=3

जोसेफिन मुद्दा: https://github.com/asajeffrey/josephine/issues/52

cc: @nox @eddyb @pnkfelix

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

विध्वंसक चलाने की गारंटी नहीं है। जंग इसकी गारंटी नहीं देती है। यह कोशिश करता है, लेकिन, उदाहरण के लिए, std::mem::forget को एक सुरक्षित फ़ंक्शन में बनाया गया था।

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

यूनियनें काफी हद तक असुरक्षित हैं क्योंकि आप यह नहीं जान सकते कि संघ का कौन सा क्षेत्र मान्य है। संघ नहीं हो Drop impl; यदि आपको ऐसा कोई इम्प्लान्ट चाहिए, तो आपको इसे मैन्युअल रूप से लिखना होगा, इस बात को ध्यान में रखते हुए कि आपको Drop साथ यूनियन फील्ड मान्य है या नहीं।

यहां एक स्पष्टीकरण: मेरा मानना ​​है कि हमें कभी भी यूनियनों को कम से कम एक चेतावनी-बाय-डिफॉल्ट लिंट के बिना डिफ़ॉल्ट रूप से Drop फ़ील्ड के साथ अनुमति देना चाहिए, यदि एक त्रुटि-बाय-डिफ़ॉल्ट लिंट नहीं। unions_with_drop_fields स्थिरीकरण प्रक्रिया के भाग के रूप में गायब नहीं होना चाहिए।

संपादित करें: उफ़, "करीब और टिप्पणी" हिट करने का मतलब नहीं था।

@joshtriplett हाँ, रस्ट की गारंटी नहीं है कि विध्वंसक चलेगा, लेकिन ऐसा हुआ (1.19 से पहले) अपरिवर्तनीय बनाए रखने के लिए कि परमिट-उधार मूल्यों को केवल उनकी स्मृति को पुनः प्राप्त किया जाएगा यदि विध्वंसक भाग गया। यह mem::forget की उपस्थिति में भी सही है, क्योंकि आप इसे perma-उधार मूल्य पर नहीं कह सकते।

यह वही है जो जोफिन पर नहीं बल्कि भरोसा कर रहा था, लेकिन यह सच नहीं है क्योंकि ड्रॉप चेकर unions_with_drop_fields व्यवहार करता है।

यह ठीक होगा यदि allow(unions_with_drop_fields) को एक असुरक्षित एनोटेशन माना जाता था, यह एक बहुत बड़ा बदलाव नहीं होगा, AFAICT, यह सिर्फ deny(unsafe_code) allow(unions_with_drop_fields) जाँच करने की आवश्यकता होगी।

@asajeffrey मैं अभी भी Pin चीज़ को समझने की कोशिश कर रहा हूं ... इसलिए, यदि मैं उदाहरण का सही ढंग से पालन करता हूं, तो यह "काम" करने का कारण यह है कि fn pin(&'a Pin<'a, T>) -> &'a T उधार लेने के लिए उधार लेने के लिए मजबूर करता है। जब तक जीवनकाल 'a प्रकार में एनोटेट किया जाता है, और यह आजीवन अधिक आक्रामक है।

यह एक दिलचस्प अवलोकन है! मुझे इस ट्रिक की जानकारी नहीं थी। मेरी आंत की भावना यह है कि यह "दुर्घटना से" काम करता है, अर्थात सुरक्षित जंग विध्वंसक को चलने से रोकने का एक तरीका प्रदान करने के लिए नहीं होता है लेकिन यह "अनुबंध" का हिस्सा नहीं बनता है। विशेष रूप से, https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html लीक को सूचीबद्ध नहीं करता है।

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

ManuallyDrop का जोड़ मूल रूप से रस्ट के उस नीच व्यवहार को मार देता है और कहता है कि इसे पहली जगह पर निर्भर नहीं होना चाहिए था जो मुझे सर्कुलर रीजनिंग जैसा लगता है। यदि ManuallyDrop ने Pin::pin कॉल करने की अनुमति नहीं दी है, तो क्या Pin::pin अनलॉउंड करने का कोई अन्य तरीका होगा? मुझे ऐसा नहीं लगता।

मुझे नहीं लगता कि हम हर गारंटी को संरक्षित करने के लिए प्रतिबद्ध हो सकते हैं, जो कि गलती से सही समय करने के लिए

इसके अलावा, यह एक दोधारी तलवार है - प्रत्येक अतिरिक्त गारंटी जो हम प्रदान करने का निर्णय लेते हैं, कुछ असुरक्षित कोड का ध्यान रखना है। एक नया गारंटी कर सकते हैं बस के रूप में अच्छी तरह से मौजूदा असुरक्षित कोड (चुपचाप crates.io पर कहीं बारे में पता किया जा रहा बिना बैठे) को तोड़ने के रूप में नए असुरक्षित कोड सक्षम खोज तो (उत्तरार्द्ध मामले यहाँ था)।

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

अगर ManuallyDrop ने Pin :: pin को कॉल करने की अनुमति नहीं दी है, तो क्या कॉल करने का कोई और तरीका होगा Pin :: pin unsound? मुझे ऐसा नहीं लगता।

unsafe कोड के साथ होगा। तो इस Pin ट्रिक साउंड की घोषणा करके, आप कुछ असुरक्षित कोड unsound घोषणा कर रहे हैं जो कि अगर हम ManuallyDrop ठीक है, तो ध्वनि होगी ।

हमने जो वर्णन किया है वह जीएस के साथ जंग को एकीकृत करने का एक बहुत ही एर्गोनोमिक तरीका है। जो मैं कहने की कोशिश कर रहा हूं, वह मुझे यह बताने में गलत लगता है कि यह सिर्फ एक दुर्घटना थी, जिसमें यह काम किया और हमें इसके बारे में भूल जाना चाहिए, जब मैं Drop साथ यूनियनों को मजबूर नहीं करने के लिए किसी भी उपयोग के मामले को नहीं पा सकता हूं @Asajeffrey द्वारा वर्णित के रूप में Drop फ़ील्ड, और जब यह वास्तव में केवल मस्सा जोसेफिन को तोड़ रहा है।

मैं इसके बारे में भूलकर खुश रहूंगा अगर कोई यह दिखा सकता है कि यह ManuallyDrop बिना भी बिना सोचे-समझे किया गया था।

मैं जो कहना चाह रहा हूं वह यह है कि मुझे यह बताना गलत लगता है कि यह सिर्फ एक दुर्घटना थी

मुझे इस चाल का कोई संकेत कभी भी "डिज़ाइन" नहीं हुआ है, इसलिए मुझे लगता है कि इसे दुर्घटना कहना काफी उचित है।

और हमें इसके बारे में भूलना चाहिए

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

उस ने कहा, मुझे यहां प्रदान की गई वास्तविक गारंटी को सटीक तरीके से व्यक्त करना मुश्किल लगता है, जो मुझे व्यक्तिगत रूप से " ManuallyDrop ठीक है" चीजों की ओर अधिक झुकाव देता है।

अगर हम उचित रूप से आश्वस्त हैं कि वास्तव में अन्य सभी unsafe कोड इस गारंटी का सम्मान करते हैं, और यह गारंटी प्रदान करना ManuallyDrop उपयोग के मामले से अधिक महत्वपूर्ण है। यह एक ट्रेड-ऑफ है, जो लीकेपोकलिप्सा के समान है, जहां हम अपना केक नहीं खा सकते हैं और यह भी है, (हम दोनों Rc अपने वर्तमान एपीआई और drop - के साथ नहीं हो सकते हैं) स्कोप आधारित थ्रेड; हम दोनों ManuallyDrop और Pin ) इसलिए हमें किसी भी तरह से निर्णय लेना होगा।

पर्याप्त रूप से, मैं दिल से इससे सहमत हूं। ध्यान दें कि यदि हम विचार करते हैं कि अंत में अपरिष्कृत व्यवहार के रूप में वर्णित drop -भोजी स्कॉप्ड थ्रेड API वापस ला सकता है।

जहां तक ​​मैं समझता हूं कि एलन का प्रस्ताव ManuallyDrop को हटाने का नहीं है, केवल ड्रॉपक को यह मानने के लिए कि यह (और Drop फ़ील्ड वाले अन्य यूनियनों का) विनाशकारी है। (यह विनाशकारी कुछ भी नहीं करने के लिए होता है, लेकिन इसका मात्र अस्तित्व प्रभावित करता है कि क्या कार्यक्रम ड्रॉपक स्वीकार या अस्वीकार करता है।)

मुझे यह जानकर खुशी होगी कि अगर कोई दिखा सकता है कि वह बिना मैनुअली मैनड्रॉप के भी बेकार था।

निश्चित नहीं है कि यह योग्य है, लेकिन यहां मेरा पहला प्रयास है: ManuallyDrop जैसी किसी चीज़ का मूर्खतापूर्ण कार्यान्वयन जो union जंग में काम करता है।

pub mod manually_drop {
    use std::mem;
    use std::ptr;
    use std::marker::PhantomData;

    pub struct ManuallyDrop<T> {
        data: [u8; 32],
        phantom: PhantomData<T>,
    }

    impl<T> ManuallyDrop<T> {
        pub fn new(x: T) -> ManuallyDrop<T> {
            assert!(mem::size_of::<T>() <= 32);
            let mut data = [0u8; 32];
            unsafe {
                ptr::copy(&x as *const _ as *const u8, &mut data[0] as *mut _, mem::size_of::<T>());
            }
            mem::forget(x);
            ManuallyDrop { data, phantom: PhantomData }
        }

        pub fn deref(&self) -> &T {
            unsafe {
                &*(&self.data as *const _ as *const T)
            }
        }
    }
}

(हाँ, संरेखण को सही करने के लिए मुझे शायद कुछ और काम करना है, लेकिन यह कुछ बछड़ों की बलि देकर भी किया जा सकता है।)
यह दिखाने वाला खेल का मैदान Pin : https://play.rust-lang.org/?gist=fe1d841cedb13d45add032b4aae6321e&version=nightly

ऊपर की दो धार वाली तलवार से मेरा अभिप्राय है - जहाँ तक मैं देख सकता हूँ, मेरा ManuallyDrop उन सभी नियमों का सम्मान करता है जो हमने बाहर रखे हैं। तो, हमारे पास असंगत असुरक्षित कोड के दो टुकड़े हैं - ManuallyDrop और Pin । कौन "सही" है? मैं कहता हूं कि Pin गारंटी पर निर्भर करता है कि हमने कभी नहीं किया और इसलिए यह "गलत" है, लेकिन यह एक निर्णय कॉल है, न कि एक प्रमाण।

अब यह दिलचस्प है। हमारे पिनिंग सामान के कुछ संस्करणों में, Pin::pin &'this mut Pin<'this, T> Pin::pin लगते हैं, लेकिन आपके ManuallyDrop लिए यह अनुचित नहीं होगा कि DerefMut निहित हो, सही ?

यहाँ एक खेल का मैदान है जो दिखाता है कि @RalfJung का (बिना किसी कारण के) अभी भी Pin साथ &mut - pin पद्धति से टूट जाता है।

https://play.rust-lang.org/?gist=5057570b54952e245fa463f8d7719663&version=nightly

यह आपके ManuallyDrop के लिए अनुचित नहीं होगा एक DerefMut निहित है, है ना?

हाँ, मैंने अभी इस उदाहरण के लिए आवश्यक एपीआई जोड़ा है। स्पष्ट deref_mut बस ठीक काम करना चाहिए।

जहां तक ​​मुझे समझ में आता है कि एलन का प्रस्ताव मैनलीड्रॉप को हटाने का नहीं है, केवल ड्रॉपक को यह मानने के लिए है कि यह (और ड्रॉप फील्ड के साथ अन्य यूनियनों) में एक विध्वंसक है। (यह विनाशकारी कुछ भी नहीं करने के लिए होता है, लेकिन इसका मात्र अस्तित्व प्रभावित करता है कि क्या कार्यक्रम ड्रॉपक स्वीकार या अस्वीकार करता है।)

आह, मैं चूक गया था कि; उसके लिए माफ़ करना। निम्नलिखित को मेरे उदाहरण में जोड़ने से यह काम करता रहता है:

    unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> {
        fn drop(&mut self) {}
    }

केवल तभी जब मैं #[may_dangle] Rust को हटा देता हूं, इसे अस्वीकार कर देता है। तो, बहुत कम से कम, हमें कुछ नियम के साथ आना होगा जो उपरोक्त कोड का उल्लंघन करता है - बस यह कह रहा है कि "कुछ कोड मौजूद हैं जिन्हें हम ध्वनि के रूप में देखना चाहते हैं कि यह असंगत है" क्योंकि यह एक बुरा कॉल है क्योंकि यह इसे बनाता है कुछ कोड को देखने और अगर यह ध्वनि है तो बहुत असंभव है।

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

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

समय क्षेत्र मजेदार हैं, मैं सिर्फ उठ गया! यहाँ दो मुद्दे प्रतीत होते हैं (सामान्य रूप से हमलावर, और विशेष रूप से ड्रॉपक), इसलिए मैं उन्हें अलग-अलग टिप्पणियों में डालूँगा ...

@ राल्फजंग : हां, यह असुरक्षित आक्रमणकारियों के बारे में एक मुद्दा है। जंग + एसटीडी के किसी भी संस्करण के लिए, आक्रमणकारी I का एक से अधिक विकल्प होता है जिसे भरोसेमंद-गारंटी तर्क का उपयोग करके बनाए रखा जाता है। और वास्तव में दो पुस्तकालय L1 और L2 , जिन्होंने असंगत I1 और I2 , जैसे कि Rust + L1 सुरक्षित और जंग + L2 सुरक्षित है, लेकिन जंग + L1 + L2 असुरक्षित है।

इस मामले में, L1 ManuallyDrop और L2 Josephine , और यह बहुत स्पष्ट है कि ManuallyDrop अब जीतने वाला है। std , जो कि जोसफीन की तुलना में बहुत अधिक पिछड़ी अनुकूलता की कमी है।

दिलचस्प बात यह है कि, https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html पर दिशानिर्देशों को "असुरक्षित कोड लिखते समय प्रोग्रामर की जिम्मेदारी है कि इसे सुरक्षित कोड देना संभव नहीं है।" इन व्यवहारों को प्रदर्शित करें: ... "अर्थात, यह एक प्रासंगिक संपत्ति है (सभी सुरक्षित संदर्भों के लिए C, C [P] गलत नहीं हो सकता) और इसलिए संस्करण पर निर्भर है (चूंकि Rust + std का v1.20 अधिक सुरक्षित है v1.18 से संदर्भ)। विशेष रूप से, मेरा दावा है कि पिनिंग ने वास्तव में 1.20 से पहले रस्ट के लिए इस बाधा को संतुष्ट नहीं किया था, क्योंकि कोई सुरक्षित संदर्भ नहीं था सी सेंट सी [पिनिंग] गलत हो जाता है।

हालांकि, यह सिर्फ बैरक-रूम लॉयरिंग है, मुझे लगता है कि हर कोई इस बात से सहमत है कि इस संदर्भ में कोई समस्या है, इसलिए असुरक्षित कोड दिशानिर्देशों के बारे में सभी चर्चाएं हैं।

अगर और कुछ नहीं, मुझे लगता है कि पिनिंग ने आकस्मिक आक्रमणकारियों के गलत उदाहरण का एक दिलचस्प उदाहरण दिखाया है।

ख़ास बात यह है कि असंगठित यूनियनों (और इसलिए ManuallyDrop ) ने ड्रॉप चेकर के साथ बातचीत में था, विशेष रूप से ManualDrop

unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> { ... }

और फिर आपके पास इस बारे में वार्तालाप हो सकता है कि यह अनुमति है या नहीं :) वास्तव में, यह वार्तालाप may_dangle थ्रेड में शुरू हो रहा है https://github.com/rust-lang/rust/issues/ पर 34761 # जारीकरण -362375924

@RalfJung आपका कोड एक दिलचस्प कोने का मामला दिखाता है, जहाँ data लिए रन-टाइम प्रकार T , लेकिन यह संकलन-समय प्रकार [u8; N] । may_dangle का संबंध किस प्रकार से है?

दिलचस्प बात यह है कि, https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html पर दिशानिर्देशों को "असुरक्षित कोड लिखते समय प्रोग्रामर की जिम्मेदारी है कि इसे सुरक्षित कोड देना संभव नहीं है।" इन व्यवहारों को प्रदर्शित करें: ... "यह एक प्रासंगिक संपत्ति है

आह, दिलचस्प है। मैं मानता हूं कि यह स्पष्ट रूप से पर्याप्त नहीं है - यह मूल स्कूप्ड थ्रेड्स को ध्वनि देगा। सार्थक होने के लिए, इसे (कम से कम) असुरक्षित कोड के सेट को निर्दिष्ट करना होगा जिसे सुरक्षित कोड को कॉल करने की अनुमति है।

व्यक्तिगत रूप से, मुझे लगता है कि यह निर्दिष्ट करने का एक बेहतर तरीका है कि इनवियर्स को बनाए रखा जाए। लेकिन मैं यहां स्पष्ट रूप से पक्षपाती हूं, क्योंकि जिस पद्धति का उपयोग मैं रस्ट के बारे में चीजों को साबित करने के लिए करता हूं, उसके लिए ऐसी आवश्यकता होती है। ;)

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

उदाहरण के लिए, अपरिभाषित व्यवहार की सीमाएं और असुरक्षित कोड क्या कर सकते हैं, समान नहीं हैं। उस विषय पर हालिया चर्चा के लिए https://github.com/nikomatsakis/rust-memory-model/issues/44 देखें: &mut T mem::size_of::<T>() == 0 लिए किसी भी अपरिभाषित व्यवहार का नेतृत्व न करें असुरक्षित कोड के लिए सीधे, और फिर भी स्पष्ट रूप से अवैध माना जाता है। कारण यह है कि अन्य असुरक्षित कोड इसके स्वामित्व वाले अनुशासन पर भरोसा कर सकते हैं, और चीजों की नकल करने से उस अनुशासन का उल्लंघन होता है।

अगर और कुछ नहीं, मुझे लगता है कि पिनिंग ने आकस्मिक आक्रमणकारियों के गलत उदाहरण का एक दिलचस्प उदाहरण दिखाया है।

ओह, यह निश्चित रूप से। और मुझे आश्चर्य है कि हम भविष्य में इससे बचने के लिए क्या कर सकते हैं? हो सकता है कि कुछ बड़ी चेतावनी https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html पर यह कहते हुए "सिर्फ इसलिए कि एक अपरिवर्तनीय व्यक्ति जंग खाए + लिबास में होता है, वह असुरक्षित कोड नहीं कर सकता है" इस पर भरोसा करें, इसके बजाय यहां कुछ अपरिवर्तनीय हैं जिन पर आप भरोसा कर सकते हैं?

@ राल्फजंग हाँ, मुझे नहीं लगता कि किसी को भी "शुद्धता" के संदर्भगत अवहेलना से प्यार है, मुख्यतः क्योंकि यह संदर्भों की अवलोकन शक्ति को भंगुर कर देता है। मैं आक्रमणकारियों के संदर्भ में एक अर्थपूर्ण अवज्ञा के साथ बहुत खुश हूँ।

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

निरंतर जाँच वर्तमान में विशेष केस यूनियन फ़ील्ड नहीं है: (cc @solson @ oli-obk)

union Transmute<T, U> { from: T, to: U }

const SILLY: () = unsafe {
    (Transmute::<usize, Box<String>> { from: 1 }.to, ()).1
};

fn main() {
    SILLY
}

उपरोक्त कोड मारी मूल्यांकन त्रुटि "नॉन-कॉन्स्टेबल fn std::ptr::drop_in_place::<(std::boxed::Box<std::string::String>, ())> - shim(Some((std::boxed::Box<std::string::String>, ()))) " का उत्पादन करता है।

इसे बदलने के लिए .to के प्रकार को बलपूर्वक परीक्षक द्वारा देखा जा सकता है:

const fn id<T>(x: T) -> T { x }

const SILLY: () = unsafe {
    (id(Transmute::<usize, Box<String>> { from: 1 }.to), ()).1
};

"विनाशकों का संकलन-समय पर मूल्यांकन नहीं किया जा सकता है"।

प्रासंगिक कार्यान्वयन कोड यहां है (विशेष रूप से restrict कॉल):
https://github.com/rust-lang/rust/blob/5e4603f99066eaf2c1cf19ac3afbac9057b1e177/src/librustc_mir/transform/qualify_consts.rs#L557

# 41073 के बेहतर विश्लेषण से पता चला था कि जब संघों के उप-क्षेत्रों को सौंपने के लिए विनाशकारी भाग आते हैं, तो स्थैतिककरण के लिए अपर्याप्त रूप से तैयार हैं। उस मुद्दे को विवरण के लिए देखें।

क्या यह पूरी तरह से यूनियनों में Drop प्रकारों पर शासन करने के लिए यथार्थवादी है, और ManuallyDrop अलग से लागू करें (एक लंग-आइटम के रूप में)? जो मैं बता सकता हूं, ManuallyDrop यूनियनों में Drop लिए सबसे बड़ी प्रेरणा लगती है, लेकिन यह एक बहुत ही खास मामला है।

एक सकारात्मक "नो ड्रॉप" गुण के अभाव में, हम तब कह सकते हैं कि एक संघ अच्छी तरह से बनता है यदि हर क्षेत्र Copy या ManuallyDrop<T> । यूनियन फील्ड असाइन करते समय ड्रापिंग के आसपास की सभी जटिलताओं को पूरी तरह से साइड-स्टेप कर देगा (जहाँ ऐसा लगता है कि हर संभव समाधान आश्चर्यजनक फुटगणों से भरा होगा), और ManuallyDrop प्रोग्रामरों के लिए एक स्पष्ट मार्कर है जिसे उन्हें Drop संभालना होगा Drop लागू नहीं होगा।" अच्छे।)

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

जिस तरह से यूनियन में कभी-कभी सी का उपयोग किया जाता है, उसके साथ यह टकराव होता है, जो एक "विस्तार बिंदु" है (IIRC @joshtriplett एक था जिसका उल्लेख सभी के हाथों में है): एक हेडर फ़ाइल एक यूनियन के लिए 3 वेरिएंट घोषित कर सकती है, लेकिन यह बाद में और वेरिएंट जोड़ने के साथ आगे-संगत माना जाता है (जब तक कि संघ के आकार में वृद्धि न हो)। लाइब्रेरी का उपयोगकर्ता यूनियन डेटा को नहीं छूने का वादा करता है यदि टैग (कहीं और बैठे) इंगित करता है कि वे वर्तमान संस्करण को नहीं जानते हैं। महत्वपूर्ण बात है, तो आप केवल एक ही संस्करण पता है, कि इसका मतलब यह नहीं है कि वहाँ केवल एक ही संस्करण है!

यह जाँच अधिक स्मार्ट हो सकती है, उदाहरण के लिए, यह उत्पाद प्रकारों के माध्यम से और नाममात्र प्रकारों के माध्यम से पार किया जा सकता है जो एक ही टोकरे में घोषित किए गए हैं।

यह विधेय पहले से ही मौजूद है, लेकिन जेनेरिक में रूढ़िवादी है क्योंकि इस पर बाध्य होने का कोई लक्षण नहीं है।
आप इसे std::mem::needs_drop माध्यम से एक्सेस कर सकते हैं (जो एक आंतरिक का उपयोग करता है जो rustc लागू होता है)।

@eddyb needs_drop खाते में अनुकूलता को आगे ले जाएगा, या यह खुशी से अन्य कृतियों पर ध्यान देगा कि क्या उनके प्रकार Drop लागू होते हैं? यहां लक्ष्य एक ऐसा चेक है जो सेमर-संगत परिवर्तनों से कभी नहीं टूटेगा, जहां किसी प्रकार या जीवनकाल के मापदंडों के साथ एक संरचना में impl Drop जोड़ना और केवल निजी फ़ील्ड्स सेवर संगत है।

@RalfJung

जिस तरह से यूनियन में कभी-कभी सी का उपयोग किया जाता है, उसके साथ यह टकराव होता है, जो एक "विस्तार बिंदु" है (IIRC @joshtriplett एक था जिसका उल्लेख सभी के हाथों में है): एक हेडर फ़ाइल एक यूनियन के लिए 3 वेरिएंट घोषित कर सकती है, लेकिन यह बाद में और वेरिएंट जोड़ने के साथ आगे-संगत माना जाता है (जब तक कि संघ के आकार में वृद्धि न हो)। लाइब्रेरी का उपयोगकर्ता यूनियन डेटा को नहीं छूने का वादा करता है यदि टैग (कहीं और बैठे) इंगित करता है कि वे वर्तमान संस्करण को नहीं जानते हैं। महत्वपूर्ण रूप से, यदि आप केवल एक ही संस्करण को जानते हैं, तो इसका मतलब यह नहीं है कि केवल एक ही संस्करण है!

यह बहुत विशिष्ट मामला है।
यह केवल C- शैली यूनियनों को प्रभावित करता है (इसलिए कोई विध्वंसक नहीं हैं और C हेडर से उत्पन्न Copy , बिलकुल स्थिर पर उपलब्ध सबसेट) है।
हम आसानी से ऐसी यूनियनों में _dummy: () या _future: () फ़ील्ड जोड़ सकते हैं और डिफ़ॉल्ट रूप से सुरक्षित "एनम" मॉडल से लाभ उठा सकते हैं। एक एफएफआई संघ एक "विस्तार बिंदु" है जो कुछ भी वैसे भी अच्छी तरह से प्रलेखित होने की आवश्यकता है।

17 अप्रैल, 2018 10:08:54 AM PDT, वादिम पेट्रोचेनकोव नोटिफिकेशन @github.com ने लिखा:

हम आसानी से ऐसी यूनियनों में एक _dummy: () या _future: () जोड़ सकते हैं
और डिफ़ॉल्ट रूप से हमारे सुरक्षित "एनम" मॉडल से लाभ उठाते रहें।

मैंने देखा है कि लोग यूनियनों की तरह व्यवहार करने के बारे में बात करते हैं जिसके लिए हम सिर्फ विवेकशील को नहीं जानते हैं, लेकिन मेरे ज्ञान का सबसे अच्छा करने के लिए, मैं किसी भी वास्तविक मॉडल या उनके इलाज के बारे में नहीं जानता। मूल चर्चा में, यहां तक ​​कि गैर-एफएफआई यूनियनों को "एक समय में कई वेरिएंट मान्य थे" मॉडल चाहते थे, जिसमें गैर-एफएफआई यूनियनों को वांछित करने के लिए प्रेरक उपयोग के मामले भी शामिल थे।

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

एफएफआई संघ
एक "विस्तार बिंदु" होना एक ऐसी चीज़ है जिसे अच्छी तरह से प्रलेखित करने की आवश्यकता है
वैसे भी।

हमें निश्चित रूप से शब्दार्थों को उतने ही सही ढंग से दस्तावेज़ित करना चाहिए जितना हम कर सकते हैं।

@RalfJung नहीं, यह सभी आंतरिक विवरणों को उजागर करते हुए auto trait s की तरह व्यवहार करता है।

वर्तमान में "सक्रिय क्षेत्रों" के बारे में कुछ चर्चा है और https://github.com/rust-lang/rust/issues/41073#issuecomment -380291471 पर यूनियनों में गिरावट है

यूनियनों को बिट्स का एक बैग होना जारी रखना चाहिए, रस्ट को यह पता नहीं है कि असुरक्षित कोड तक पहुंचने तक उन्हें किसी भी समय क्या हो सकता है।

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

मेरे लिए, यदि आप किसी यूनियन की सामग्री को छोड़ना चाहते हैं, तो आपको ~ कास्ट / ट्रांसमीट करना होगा (हो सकता है कि यह ट्रांसमिट न हो क्योंकि यह दूसरे वेरिएंट के लिए अंत में कुछ अप्रयुक्त बिट्स के साथ बड़ा हो सकता है) आप ~ ड्रॉपर्स को उन फ़ील्ड्स पर ले जाना चाहते हैं जिन्हें छोड़ने की आवश्यकता है और std::ptr::drop_in_place उपयोग करें, या मूल्य निकालने के लिए फ़ील्ड सिंटैक्स का उपयोग करें।

अगर मुझे यूनियनों के बारे में कुछ नहीं पता था कि मैं उनसे काम करने की उम्मीद कैसे करूंगा:

उदाहरण - संघ के रूप में mem::uninitialized प्रतिनिधित्व करना

pub union MaybeValid<T> {
    valid: T,
    invalid: ()
}

impl<T> MaybeValid<T> {
    #[inline] // this should optimize to a no-op
    pub fn from_valid(valid: T) -> MaybeValid<T> {
        MaybeValid { valid }
    }

    pub fn invalid() -> MaybeValid<T> {
        MaybeValid { invalid: () }
    }

   pub fn zeroed() -> MaybeValid<T> {
        // do whatever is necessary here...
        unimplemented!()
    }
}

fn example() {
    let valid_data = MaybeValid::from_valid(1_u8);
    // Destructor of a union always does nothing, but that's OK since our 
    // data type owns nothing.
    drop(valid_data);
    let invalid_data = MaybeValid::invalid();
    // Destructor of a union again does nothing, which means it needs to know 
    // nothing about its surroundings, and can't accidentally try to free unused memory.
    drop(invalid_data);
    let valid_data = MaybeValid::from_valid(String::from("test string"));
    // Now if we dropped `valid_data` we would leak memory, since the string 
    // would never get freed. This is already possible in safe rust using e.g. `Rc`. 
    // `union` is a similarly advanced feature to `Rc` and so new users are 
    // protected by the order in which concepts are introduced to them. This is 
    // still "safe" even though it leaks because it cannot trigger UB.
    //drop(valid_data)
    // Since we know that our union is of a particular form, we can safely 
    // move the value out, in order to run the destructor. I would expect this 
    // to fail if the drop method had run, even though the drop method does 
    // nothing, because that's the way stuff works in rust - once it's dropped
    // you can't use it.
    let _string_to_drop = unsafe { valid_data.valid };
    // No memory leak and all unsafety is encapsulated.
}

मैं इसे पोस्ट करने जा रहा हूं, फिर इसे संपादित करूंगा ताकि मैं अपने काम को ढीला न करूं।
खेतों को छोड़ने के लिए EDIT @SimonSapin तरीका।

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

(यदि यह केवल इसे छोड़ देना है तो इसे स्थानांतरित करने के अर्थ में मूल्य निकालने की कोई आवश्यकता नहीं है, आप एक फ़ील्ड में एक संकेतक ले सकते हैं और std::ptr::drop_in_place उपयोग कर सकते हैं।)

संबंधित: स्थिरांक के लिए मैं वर्तमान में तर्क दे रहा हूं कि एक निरंतर के अंदर संघ के कम से कम एक क्षेत्र को सही करने की आवश्यकता है: https://github.com/rust-lang/rust/pull/51361 (यदि आपके पास एक ZST फ़ील्ड है अटल सत्य)

मैं इसे पोस्ट करने जा रहा हूं, फिर इसे संपादित करूंगा ताकि मैं अपने काम को ढीला न करूं।

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

@derekdreery (और बाकी सभी) मैं https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025 के लिए आपकी प्रतिक्रिया में दिलचस्पी लूंगा

संबंधित: स्थिरांक के लिए मैं वर्तमान में तर्क दे रहा हूं कि एक निरंतर के अंदर संघ के कम से कम एक क्षेत्र को सही करने की आवश्यकता है: # 51361

मैंने कार्यान्वयन देखा है लेकिन तर्क नहीं देखा है। ;)

अच्छी तरह से ... तर्क "बिल्कुल अजीब नहीं लग रहा था" द्वारा।

मुझे कोई भी योजना लागू करने में खुशी होगी जो हम कॉन्स्टेबल चेकर के साथ आएंगे, लेकिन मेरा अंतर्ज्ञान हमेशा यह था कि संघ के एक संस्करण को पूरी तरह से सही करने की आवश्यकता है।

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

मुझे लगता है कि यूनियनों को "बिना किसी व्याख्या किए गए बिट्स के बैग" हैं, उन्हें एक्सेस करने के लिए कुछ सुविधाजनक तरीके से। मैं उन्हें जाँच न करने के बारे में कुछ भी अजीब नहीं देखता।

AFAIK में वास्तव में बर्लिन के सभी हाथों में उल्लेखित कुछ उपयोग-मामले @joshtriplett हैं जहां संघ का पहला आधा एक क्षेत्र से मेल खाता है और दूसरा आधा कुछ अन्य क्षेत्र से मेल खाता है।

मुझे लगता है कि यूनियनों को "बिना किसी व्याख्या किए गए बिट्स के बैग" हैं, उन्हें एक्सेस करने के लिए कुछ सुविधाजनक तरीके से। मैं उन्हें जाँच न करने के बारे में कुछ भी अजीब नहीं देखता।

मैं हमेशा यद्यपि यह व्याख्या कुछ हद तक भाषा की भावना के खिलाफ जाती है।
अन्य स्थानों में हम फुटगणों को रोकने के लिए स्थैतिक विश्लेषण का उपयोग करते हैं, यह जाँचते हैं कि असंगठित या उधार के मूल्यों तक पहुंच नहीं है, लेकिन उन यूनियनों के लिए जो विश्लेषण अचानक अक्षम हैं, कृपया शूट करें।

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

इसके अलावा, यह union सरल बनाता

हमें नहीं लगता कि हमें उस लागत का भुगतान करना है क्योंकि बैग-ऑफ-बिट्स मॉडल एनम-अननोन-वेरिएंट मॉडल की तुलना में कोई नया अवसर नहीं देता है।

यहाँ प्रश्न में संपत्ति कम से कम असुरक्षित कोड को बनाए रखने के लिए एक बोझ के रूप में ज्यादा है क्योंकि यह एक सुरक्षा है। कोई भी स्थैतिक विश्लेषण नहीं है जो उन सभी गलतियों को रोक सकता है जो इस संपत्ति को तोड़ सकती हैं क्योंकि हम असुरक्षित टाइप ^{1 के} लिए यूनियनों का उपयोग करना चाहते हैं, इसलिए "अनजान वेरिएंट के साथ एनम" का अर्थ है कोड हैंडलिंग यूनियनों को सुपर सावधान रहना होगा कि यह कैसे लिखता है संघ या जोखिम तत्काल यूबी, वास्तव में संघ से पढ़ने में शामिल असमानता को कम किए बिना, क्योंकि पढ़ने के लिए पहले से ही जानने की आवश्यकता होती है (चैनलों के माध्यम से संकलक समझ में नहीं आता है) कि बिट्स आपके द्वारा पढ़े जाने वाले संस्करण के लिए मान्य हैं। हम केवल वास्तव में उपयोगकर्ताओं को एक ऐसे संघ के बारे में चेतावनी दे सकते हैं जो इसके किसी भी वेरिएंट के लिए मान्य नहीं है, जब यह मीरी के तहत चल रहा है, न कि अधिकांश मामलों में जहां यह रनटाइम में होता है।

¹ उदाहरण के लिए, यह मानते हुए कि टुपल्स सरलता के लिए repr (C) हैं, union Foo { a: (bool, u8), b: (u8, bool) } आपको कुछ ऐसी चीज़ों का निर्माण करने की अनुमति देता है जो केवल फ़ील्ड असाइनमेंट द्वारा अमान्य हैं।

@rkruppe

संघ फू {a: (बूल, यू 8), बी: (यू 8, बूल)}

अरे, यह मेरा उदाहरण है :)
और यह RFC 1897 के मॉडल (कम से कम एक "पत्ती" टुकड़े bool -1, u8 -1, u8 -2, bool तहत मान्य है -2 किसी भी आंशिक असाइनमेंट के बाद वैध है)।

कोड हैंडलिंग यूनियनों को सुपर सावधान रहना होगा कि यह संघ को कैसे लिखता है या तत्काल यूबी को जोखिम में डालता है

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

दूसरी ओर, चाल की जाँच के बिना , संघ को बहुत आसानी से अमान्य स्थिति में डाला जा सकता है।

let u: Union;
let x = u.field; // UB

यह RFC 1897 के मॉडल की बात है, स्थैतिक जाँच सुनिश्चित करता है कि कोई भी सुरक्षित संचालन (जैसे असाइनमेंट या आंशिक असाइनमेंट) संघ को अमान्य स्थिति में बदल सकता है, इसलिए आपको हर समय सुपर सावधान रहने की आवश्यकता नहीं है और तत्काल यूबी प्राप्त नहीं करें ।
केवल केंद्रीय-असंबद्ध असुरक्षित संचालन जैसे जंगली संकेत के माध्यम से लिखते हैं, एक संघ को अमान्य बना सकता है।

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

कट्टरपंथी प्रकार की जाँच ड्रोपिंग को कैसे प्रभावित करेगी? यदि आप एक संघ बनाते हैं, तो इसे C को पास करें, जो स्वामित्व लेता है, तो जंग डेटा को मुक्त करने की कोशिश करेगा, शायद एक डबल-फ्री? या क्या आप हमेशा Drop खुद को लागू करेंगे?

यदि सुझाव "संकलन के समय वैधानिक रूप से वैरिएंट की जाँच की जाती है", तो अगर यह सुझाव समझ में आया तो इसे संपादित करना अच्छा होगा।

2 संपादित करें यूनियनों बिट्स के एक बैग के रूप में शुरू कर सकता है और फिर बाद में पीछे की ओर संगत होने के लिए सुरक्षित पहुंच की अनुमति देता है?

और यह RFC 1897 के मॉडल (कम से कम "पत्ती" अंशों में से एक बूल -1, u8-1, u8-2, बूल -2 किसी भी आंशिक असाइनमेंट के बाद मान्य है) के तहत मान्य है।

अगर हम तय करते हैं कि हम चाहते हैं कि यह वैध हो, तो मुझे लगता है कि @ ओली-ओबेक को दिखाने के लिए मिरिक के चेक को अपडेट करना चाहिए - https://github.com/rust-lang/rust/pull/51361 के साथ विलय कर दिया गया, इसे अस्वीकार कर दिया जाएगा मिरी।

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

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

मुझे लगता है कि मुझे यहां कुछ मौलिक याद आ रही है। मैं @rkruppe से सहमत हूं
यूनियनों के साथ कठिन समस्या यह सुनिश्चित कर रही है कि संघ वर्तमान में संग्रहीत करता है
वह डेटा जिसे प्रोग्राम पढ़ना चाहता है।

लेकिन AFAIK को स्थैतिक विश्लेषण द्वारा "स्थानीय रूप से" हल नहीं किया जा सकता है। हम
कम से कम पूरे कार्यक्रम का विश्लेषण करने के लिए, और तब भी यह होगा
हल करने के लिए एक कठिन समस्या।

तो ... क्या मेज पर इस समस्या का समाधान है? या, क्या करता है
वास्तव में प्रस्तावित सटीक समाधान हमें खरीदते हैं? कहो मुझे C से एक संघ मिलता है,
पूरे जंग और सी कार्यक्रम का विश्लेषण किए बिना, प्रस्तावित क्या कर सकता है
स्थिर विश्लेषण वास्तव में पाठकों के लिए गारंटी है?

@gnzlbg मुझे लगता है कि हमें केवल वही गारंटी मिलेगी जो @petrochenkov ने ऊपर लिखी है

स्थैतिक जाँच यह सुनिश्चित करती है कि कोई भी सुरक्षित संचालन (जैसे असाइनमेंट या आंशिक असाइनमेंट) संघ को अमान्य स्थिति में बदल सकता है

दूसरी ओर, चाल की जाँच के बिना, संघ को बहुत आसानी से अमान्य स्थिति में रखा जा सकता है।

आपका प्रस्ताव बुरी तरह से पढ़े जाने से नहीं बचाता है, मुझे नहीं लगता कि यह संभव है।

इसके अलावा, मैंने कुछ बहुत ही बुनियादी "इनिशियलाइज़्ड" ट्रैकिंग की कल्पना की, "किसी भी क्षेत्र को लिखने के लिए यूनियन इनिशियलाइज़ करता है"। हमें कुछ भी तब चाहिए होगा जब impl Drop for MyUnion की अनुमति हो। बेहतर या बदतर के लिए, हमें यह तय करना होगा कि एक संघ के लिए स्वचालित ड्रॉप कॉल कब और कहाँ डालें। उन नियमों को यथासंभव सरल होना चाहिए क्योंकि यह अतिरिक्त कोड है जिसे हम मौजूदा सूक्ष्म असुरक्षित कोड में डाल रहे हैं। यूनियनों के लिए जो Drop लागू करते हैं, मैंने भी struct समान प्रतिबंध की कल्पना की है जो डेटा संरचना पहले से ही आरंभिक होने तक किसी फ़ील्ड में लिखने की अनुमति नहीं देता है।

@derekchiang

यूनियनों बिट्स के एक बैग के रूप में शुरू कर सकता है और फिर बाद में पीछे की ओर संगत होने के लिए सुरक्षित पहुंच की अनुमति देता है?
एक बार जब हम कहते हैं कि यह बिट्स का एक बैग है, तो असुरक्षित कोड हो सकता है जो यह अनुमति देता है।

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

उदाहरण के लिए, इसके लिए एक उपयोग मामला: सी-स्टाइल टैग किए गए यूनियन पर विचार करें जो भविष्य में अधिक टैग के साथ स्पष्ट रूप से एक्स्टेंसिबल है। उस संघ को पढ़ने वाले C और Rust कोड को यह नहीं मानना ​​चाहिए कि वह हर संभावित क्षेत्र को जानता है।

@RalfJung

शायद मुझे दूसरी दिशा से शुरुआत करनी चाहिए।

क्या यह कोड 1) यूनियनों के लिए 2) गैर-यूनियनों के लिए काम करना चाहिए?

let x: T;
let y = x.field;

मेरे लिए दोनों ही मामलों में जवाब स्पष्ट "नहीं" है, क्योंकि यह त्रुटियों की एक पूरी श्रेणी है, जो रुस्ट T के "संघ" -इस की परवाह किए बिना रोक सकते हैं और करना चाहते हैं।

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

फिर, एनम मॉडल केवल ऊपर वर्णित स्थिर जाँच का परिणाम है + एक और स्थिति।
यदि 1) आरंभीकरण जाँच सक्षम है और 2) असुरक्षित कोड संघ से संबंधित क्षेत्र में मनमाने ढंग से अमान्य बाइट नहीं लिखता है, तो यूनियनों में से एक "पत्ती" फ़ील्ड स्वचालित रूप से वैध है। यह डायनेमिक अनचेकेबल है (कम से कम यूनियनों के लिए> 1 फ़ील्ड और कॉन्स्टेबल-मूल्यांकनकर्ता के बाहर) गारंटी है, लेकिन यह सबसे पहले कोड पढ़ने वाले लोगों पर लक्षित है।

उदाहरण के लिए, @joshtriplett से यह मामला

उदाहरण के लिए, इसके लिए एक उपयोग मामला: सी-स्टाइल टैग किए गए यूनियन पर विचार करें जो भविष्य में अधिक टैग के साथ स्पष्ट रूप से एक्स्टेंसिबल है। उस संघ को पढ़ने वाले C और Rust कोड को यह नहीं मानना ​​चाहिए कि वह हर संभावित क्षेत्र को जानता है।

यदि कोड स्पष्ट रूप से "संभावित भविष्य के एक्सटेंशन" के लिए एक अतिरिक्त फ़ील्ड था, तो कोड पढ़ने वाले लोगों के लिए अधिक स्पष्ट होगा।

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

@petrochenkov

क्या यह कोड 1) यूनियनों के लिए 2) गैर-यूनियनों के लिए काम करना चाहिए?

let x: T;
let y = x.field;

मेरे लिए दोनों ही मामलों में जवाब स्पष्ट "नहीं" है, क्योंकि यह त्रुटियों की एक पूरी श्रेणी है, जो रुस्ट T के "संघ" -इस की परवाह किए बिना रोक सकते हैं और करना चाहते हैं।

सहमत, असमान मूल्यों के लिए जाँच का यह स्तर उचित और काफी संभव लगता है।

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

अब तक सहमत है, मुझे लगता है कि मैं नियमों के नियमों को समझता हूं।

फिर, एनम मॉडल केवल ऊपर वर्णित स्थिर जाँच का परिणाम है + एक और स्थिति।
यदि 1) आरंभीकरण जाँच सक्षम है और 2) असुरक्षित कोड संघ से संबंधित क्षेत्र में मनमाने ढंग से अमान्य बाइट नहीं लिखता है, तो यूनियनों में से एक "पत्ती" फ़ील्ड स्वचालित रूप से वैध है। यह डायनेमिक अनचेकेबल है (कम से कम यूनियनों के लिए> 1 फ़ील्ड और कॉन्स्टेबल-मूल्यांकनकर्ता के बाहर) गारंटी है, लेकिन यह सबसे पहले कोड पढ़ने वाले लोगों पर लक्षित है।

यह अतिरिक्त शर्त यूनियनों के लिए मान्य नहीं है।

उदाहरण के लिए, @joshtriplett से यह मामला

उदाहरण के लिए, इसके लिए एक उपयोग मामला: सी-स्टाइल टैग किए गए यूनियन पर विचार करें जो भविष्य में अधिक टैग के साथ स्पष्ट रूप से एक्स्टेंसिबल है। उस संघ को पढ़ने वाले C और Rust कोड को यह नहीं मानना ​​चाहिए कि वह हर संभावित क्षेत्र को जानता है।

यदि कोड स्पष्ट रूप से "संभावित भविष्य के एक्सटेंशन" के लिए एक अतिरिक्त फ़ील्ड था, तो कोड पढ़ने वाले लोगों के लिए अधिक स्पष्ट होगा।

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

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

उन "असुरक्षित" तृतीय पक्ष "का अर्थ है" एफएफआई से एक संघ प्राप्त करना "शामिल है, जो पूरी तरह से वैध उपयोग का मामला है।

यहाँ एक ठोस उदाहरण दिया गया है:

union Event {
    event_id: u32,
    event1: Event1,
    event2: Event2,
    event3: Event3,
}

struct Event1 {
    event_id: u32, // always EVENT1
    // ... more fields ...
}
// ... more event structs ...

match u.event_id {
    EVENT1 => { /* ... */ }
    EVENT2 => { /* ... */ }
    EVENT3 => { /* ... */ }
    _ => { /* unknown event */ }
}

यह पूरी तरह से मान्य कोड है जो लोग यूनियनों का उपयोग करके लिख सकते हैं और कर सकते हैं।

@petrochenkov

क्या यह कोड 1) यूनियनों के लिए 2) गैर-यूनियनों के लिए काम करना चाहिए?
मेरे लिए दोनों ही मामलों में उत्तर स्पष्ट "नहीं" है, क्योंकि यह त्रुटियों की एक पूरी श्रेणी है, जो कि टी के "संघ" की परवाह किए बिना, जंग को रोक सकता है और रोकना चाहता है।

मेरे लिए ठीक है।

यूनियनों के लिए सबसे सरल योजना "स्ट्रक्चर्स + (डी) इनिशियलाइज़ेशन / एक क्षेत्र के उधार के समान नियम (डी) अपने सिबलिंग फ़ील्ड्स को इनिशियलाइज़ / लोन देना होगा"।

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

यदि 1) आरंभीकरण जाँच सक्षम है और 2) असुरक्षित कोड संघ से संबंधित क्षेत्र में मनमाने ढंग से अमान्य बाइट नहीं लिखता है, तो यूनियनों में से एक "पत्ती" फ़ील्ड स्वचालित रूप से वैध है। यह डायनेमिक अनचेकेबल है (कम से कम यूनियनों के लिए> 1 फ़ील्ड और कॉन्स्टेबल-मूल्यांकनकर्ता के बाहर) गारंटी है, लेकिन यह सबसे पहले कोड पढ़ने वाले लोगों पर लक्षित है।

मुझे लगता है कि यह बुनियादी वैधता मान्यताओं के लिए गतिशील रूप से जाँच योग्य (दी गई प्रकार की जानकारी) के लिए अत्यंत वांछनीय है। फिर हम उन्हें मिरि में CTFE के दौरान जाँच कर सकते हैं, हम उन्हें "पूर्ण" मिर्री रन (जैसे एक परीक्षण सूट) के दौरान भी जाँच सकते हैं, हम अंततः किसी प्रकार का सैनिटाइज़र या शायद एक ऐसा मोड ले सकते हैं जहाँ पर रुस्ट debug_assert! उत्सर्जन करता है वैधता की जांच करने के लिए महत्वपूर्ण स्थानों में।
मुझे लगता है कि सी के अनियंत्रित नियमों के साथ अनुभव पर्याप्त सबूत देता है कि ये समस्याग्रस्त हैं। आमतौर पर, पहला कदम वास्तव में समझने और स्पष्ट करने के लिए है कि उन्हें व्यक्त करने के लिए गतिशील रूप से जांचने योग्य तरीका खोजने के लिए नियम क्या हैं। यहां तक ​​कि संगामिति स्मृति मॉडल के लिए, "गतिशील रूप से जांच योग्य" वेरिएंट (एक आभासी मशीन के चरण-दर-चरण निष्पादन के संदर्भ में सब कुछ समझाते हुए परिचालन शब्दार्थ) दिखा रहे हैं और स्वयंसिद्ध की लंबे समय से चली आ रही खुली समस्याओं को हल करने का एकमात्र तरीका है मॉडल जो पहले उपयोग किए गए थे ("पतली हवा की समस्या का ouf" यहां एक कीवर्ड है)।

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

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

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

वह गारंटी हमें क्या

@joshtriplett

सी-स्टाइल टैग किए गए संघ पर विचार करें जो भविष्य में अधिक टैग के साथ स्पष्ट रूप से एक्स्टेंसिबल है। उस संघ को पढ़ने वाले C और Rust कोड को यह नहीं मानना ​​चाहिए कि वह हर संभावित क्षेत्र को जानता है।

@Petrochenkov द्वारा प्रस्तावित मॉडल उन usecases को संघ में __non_exhaustive: () फ़ील्ड जोड़कर अनुमति देता है। हालाँकि, मुझे नहीं लगता कि यह आवश्यक होना चाहिए। वैचारिक रूप से, बाध्यकारी जनरेटर इस तरह के क्षेत्र को जोड़ सकते हैं।

@RalfJung

यह गतिशील अनियंत्रित है (कम से कम यूनियनों के लिए> 1 क्षेत्रों और कांस्टेबल-मूल्यांकनकर्ता के बाहर) गारंटी

मुझे लगता है कि यह बुनियादी वैधता मान्यताओं के लिए गतिशील रूप से जांच योग्य है

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

@RalfJung

@Petrochenkov द्वारा प्रस्तावित मॉडल उन

हां, मैं समझ गया था कि यह प्रस्ताव था।

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

वे कर सकते थे, लेकिन उन्हें व्यवस्थित रूप से हर एक संघ में जोड़ना होगा।

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

@joshtriplett

यूनियनों के प्राथमिक उपयोग के मामले

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

@petrochenkov मैं कहना नहीं था "प्राथमिक उपयोग के मामले को तोड़ने", मैंने कहा "प्राथमिक उपयोग के मामलों को तोड़ने"। एफएफआई यूनियनों के प्राथमिक उपयोग के मामलों में से एक है।

और उन सभी सेटों का संघ (हेह;) लें

निश्चित रूप से एक बयान के लिए एक आकर्षक स्पष्टता है कि "एक संघ के संभावित मूल्य इसके सभी संभावित वेरिएंट के संभावित मूल्यों का संघ हैं ..."

सच। हालाँकि, यह प्रस्ताव नहीं है - हम सभी सहमत हैं कि निम्नलिखित कानूनी होना चाहिए:

union F {
  x: (u8, bool),
  y: (bool, u8),
}
fn foo() -> F {
  let mut f = F { x: (5, false) };
  unsafe { f.y.1 = 17; }
  f
}

वास्तव में मुझे लगता है कि यह एक बग है कि इसके लिए unsafe आवश्यकता होती है।

इसलिए, संघ को कम से कम, अलविदा लेना होगा।
इसके अलावा, मुझे नहीं लगता कि "आकर्षक स्पष्टता" अपने आप में एक पर्याप्त अच्छा कारण है। हमारे द्वारा तय किया गया कोई भी आक्रमण असुरक्षित कोड लेखकों के लिए एक महत्वपूर्ण बोझ है, हमारे पास ठोस लाभ होने चाहिए जो हमें बदले में मिलते हैं।

@RalfJung

वास्तव में मुझे लगता है कि यह एक बग है कि इसके लिए भी असुरक्षित की आवश्यकता है।

मुझे नए MIR- आधारित अनैफिसिटी-चेकर कार्यान्वयन के बारे में नहीं पता है, लेकिन पुराने HIR- आधारित में यह निश्चित रूप से एक चेकर सीमा / सरलीकरण था - केवल expr1.field = expr2 केवल भावों का विश्लेषण संभव था - इस क्षेत्र के लिए असाइनमेंट "अनफसली ऑप्ट-आउट, बाकी सब कुछ सामान्य रूप से जेनेरिक" फ़ील्ड एक्सेस "के रूप में माना जाता है जो यूनियनों के लिए असुरक्षित है।

Https://github.com/rust-lang/rust/issues/52786#issuecomment -408645420 में टिप्पणी का उत्तर दें:

तो विचार यह है कि संकलक अभी भी Wrap<T> के अनुबंध के बारे में कुछ नहीं जानता है और उदाहरण के लिए लेआउट अनुकूलन नहीं कर सकता है। ठीक है, यह स्थिति समझ में आती है।
इसका अर्थ है कि आंतरिक रूप से, Wrap मॉड्यूल के अंदर, Wrap<T> मॉड्यूल का कार्यान्वयन, उदाहरण के लिए, अस्थायी रूप से इसमें "अनपेक्षित मान" लिख सकते हैं, यदि यह उन्हें उपयोगकर्ताओं को लीक नहीं करता है, और संकलक उनके साथ ठीक हो जाएगा।

मुझे यकीन नहीं है कि अप्रत्याशित मूल्यों के अभाव के बारे में Wrap s अनुबंध का हिस्सा क्षेत्र गोपनीयता से संबंधित कैसे है।

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

जैसा कि मैं आपको टिप्पणी करता हूं, दृष्टिकोण यह कहना है कि एक निजी क्षेत्र (संघ या एक संरचना में, कोई फर्क नहीं पड़ता) का तात्पर्य उपयोगकर्ता के लिए एक अनजान अपरिचित से है, इसलिए कोई भी कार्य उस क्षेत्र को बदल रहा है (सीधे या जंगली संकेत के माध्यम से, doesn ' t मामला) UB में परिणाम होता है क्योंकि वे संभावित अनिर्दिष्ट अपरिवर्तनीय को तोड़ सकते हैं।

इस का मतलब है कि अगर एक संघ एक भी निजी क्षेत्र है, तो इसकी implementer (लेकिन संकलक) मान सकते हैं कि कि कोई तीसरा पक्ष है कि संघ में एक अप्रत्याशित मूल्य लिखेंगे।
यह कुछ अर्थों में उपयोगकर्ता के लिए "डिफ़ॉल्ट यूनियन प्रलेखन क्लॉज" है:
- (डिफ़ॉल्ट) यदि किसी यूनियन के पास कोई निजी फ़ील्ड है तो आप उसमें कचरा नहीं लिख
- अन्यथा, आप कचरे को एक संघ में लिख सकते हैं जब तक कि उसके डॉक्स इसे स्पष्ट रूप से प्रतिबंधित नहीं करते हैं।

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

@RalfJung
क्या यह आपको सही स्थिति का वर्णन करता है?

इस तरह के परिदृश्यों का इलाज कैसे किया जाता है?

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

जैसा कि मैं आपको टिप्पणी करता हूं, दृष्टिकोण यह कहना है कि एक निजी क्षेत्र (संघ या एक संरचना में, कोई फर्क नहीं पड़ता) का तात्पर्य उपयोगकर्ता के लिए एक अनजान अपरिचित से है, इसलिए कोई भी कार्य उस क्षेत्र को बदल रहा है (सीधे या जंगली संकेत के माध्यम से, doesn ' t मामला) UB में परिणाम होता है क्योंकि वे संभावित अनिर्दिष्ट अपरिवर्तनीय को तोड़ सकते हैं।

नहीं, यह मेरा मतलब नहीं है।

कई आक्रमणकारी हैं। मुझे नहीं पता कि हमें कितने की आवश्यकता होगी, लेकिन कम से कम दो होंगे (और मेरे पास उनके लिए महान नाम नहीं हैं):

• एक प्रकार का "लेआउट-स्तरीय इनवेरिएंट" (या "सिंटेक्टिक इनवेरिएंट") पूरी तरह से टाइप के वाक्यात्मक आकार द्वारा परिभाषित किया गया है। ये " &mut T गैर-पूर्ण और गठबंधन" जैसी चीजें हैं, " bool 0 या 1 ", " ! नहीं हो सकता मौजूद"। इस स्तर पर, *mut T usize - दोनों किसी भी मूल्य की अनुमति देते हैं (या शायद किसी भी प्रारंभिक मूल्य पर, लेकिन वह अंतर किसी अन्य चर्चा के लिए है)। हम अंततः, सभी प्रकारों के लिए संरचनात्मक पुनर्संक्रमण द्वारा इन आक्रमणकारियों को वर्तनी के लिए एक दस्तावेज देने जा रहे हैं: एक संरचना का लेआउट-स्तर अपरिवर्तनीय यह है कि इसके सभी क्षेत्रों में उनके अपरिवर्तित बनाए रखा गया है, आदि दृश्यता यहां भूमिका नहीं निभाती है।

Violating the layout-level invariant is instantaneous UB. This is a statement we can make because we have defined this invariant in very simple terms, and we make it part of the definition of the language itself. We can then exploit this UB (and we already do), e.g. to perform enum layout optimizations.

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

  कस्टम, सिमेंटिक इनवेरिएंट और यूबी के बीच संबंध यह है कि हम घोषणा करते हैं कि असुरक्षित कोड विदेशी कोड द्वारा संरक्षित किए जा रहे अपने सिमेंटिक इनवेरिएंट पर निर्भर हो सकता है । इससे Vec के आकार के क्षेत्र में किसी भी यादृच्छिक सामान को आगे बढ़ाने के लिए गलत हो जाता है। ध्यान दें कि मैंने गलत कहा अप्राप्त शब्द का उपयोग करता हूं) - लेकिन अपरिभाषित व्यवहार नहीं ! इस अंतर को प्रदर्शित करने के लिए एक और उदाहरण (वास्तव में, एक ही उदाहरण) &mut ZST लिए नियमों के बारे में &mut ZST कभी भी तत्काल UB नहीं है, लेकिन यह अभी भी गलत / निराधार है क्योंकि कोई ऐसा असुरक्षित कोड लिख सकता है जो इस पर निर्भर न हो।

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

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

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

उदाहरण के लिए, एक संरचना के एक सार्वजनिक क्षेत्र में एक कस्टम इनवेरिएंट नहीं हो सकता है जो फ़ील्ड प्रकार के

एक सार्वजनिक क्षेत्र के साथ एक संघ ... अच्छी तरह से कुछ दिलचस्प है। संघ क्षेत्र पढ़ना वैसे भी असुरक्षित है, इसलिए वहां कुछ भी नहीं बदलता है। संघ क्षेत्र लिखना सुरक्षित है, इसलिए सार्वजनिक क्षेत्र के साथ एक संघ को मनमाने ढंग से डेटा को संभालने में सक्षम होना चाहिए, जो उस क्षेत्र के प्रकार के कस्टम अपरिवर्तनीय को क्षेत्र में डालने से संतुष्ट करता है। मुझे संदेह है कि यह बहुत उपयोगी होगा ...

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

इसका मतलब है कि आंतरिक रूप से, रैप के मॉड्यूल के अंदर, लपेट का कार्यान्वयनमॉड्यूल, उदाहरण के लिए, अस्थायी रूप से इसमें "अनपेक्षित मान" लिख सकते हैं, अगर यह उन्हें उपयोगकर्ताओं को लीक नहीं करता है, और संकलक उनके साथ ठीक होगा।

सही बात। (आतंक-सुरक्षा यहाँ एक चिंता का विषय है लेकिन आप शायद जानते हैं)। यह ऐसा ही है, Vec , मैं सुरक्षित रूप से कर सकता हूं

let sz = self.size;
self.size = 1337;
self.size = sz;

और कोई यूबी नहीं है।

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

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

मैंने अंततः उस ब्लॉग पोस्ट के बारे में &mut T का आरंभिक रूप दिया जाना चाहिए, और दो प्रकार के आक्रमणकारियों का उल्लेख ऊपर किया गया है।

क्या यहां कुछ भी ट्रैक करने के लिए बचा है जो पहले से ही https://github.com/rust-lang/rust/issues/55149 द्वारा कवर नहीं किया गया है, या हमें बंद करना चाहिए?

E0658 अभी भी यहाँ इंगित करता है:

त्रुटि [E0658]: गैर- Copy फ़ील्ड्स के साथ यूनियन अस्थिर हैं (देखें मुद्दा # 8188)

यह वर्तमान में परमाणु के साथ बहुत अधिक खेलता है, क्योंकि वे Copy लागू नहीं करते हैं। किसी को भी एक समाधान पता है?

जब https://github.com/rust-lang/rust/issues/55149 लागू हो जाता है, तो आप एक संघ में ManuallyDrop<AtomicFoo> का उपयोग कर सकेंगे। तब तक, एकमात्र काम-रात्रि का उपयोग करना है (या union उपयोग न करें और कुछ विकल्प खोजें)।

लागू होने के साथ, आपको ManuallyDrop आवश्यकता नहीं होनी चाहिए; सब के बाद जंग को पता है कि Atomic* Drop लागू नहीं करता है।

ट्रैकिंग मुद्दे को नए पर स्विच करने के लिए खुद को सौंपना।