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

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

पिछली कुछ चर्चाओं के बारे में जानने के लिए https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03t6ji/?st=ixp2gf04&sh=7d6920db देखें।

मुझे लगता है कि यह Go1 के लिए टाइप सिस्टम का बहुत महत्वपूर्ण परिवर्तन है और इसकी कोई आवश्यकता नहीं है।
मेरा सुझाव है कि हम इसे गो 2 के बड़े संदर्भ में फिर से देखें।

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

Go . में योग के प्रकार

एक योग प्रकार "|" के साथ संयुक्त दो या दो से अधिक प्रकारों द्वारा दर्शाया जाता है
ऑपरेटर।

type: type1 | type2 ...

परिणामी प्रकार के मान केवल निर्दिष्ट प्रकारों में से एक को धारण कर सकते हैं। NS
प्रकार को एक इंटरफ़ेस प्रकार के रूप में माना जाता है - इसका गतिशील प्रकार है
मूल्य जो इसे सौंपा गया है।

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

उदाहरण के लिए:

type maybeInt nil | int

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

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

योग प्रकार का शून्य मान पहले प्रकार का शून्य मान है
योग।

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

उदाहरण के लिए:

var x int|float64 = 13

गतिशील प्रकार int के साथ एक मूल्य का परिणाम होगा, लेकिन

var x int|float64 = 3.13

परिणामस्वरूप गतिशील प्रकार फ्लोट64 वाला मान होगा।

कार्यान्वयन

एक सरल कार्यान्वयन इंटरफ़ेस के रूप में योग प्रकार को लागू कर सकता है
मूल्य। एक अधिक परिष्कृत दृष्टिकोण एक प्रतिनिधित्व का उपयोग कर सकता है
संभावित मूल्यों के सेट के लिए उपयुक्त।

उदाहरण के लिए एक योग प्रकार जिसमें पॉइंटर्स के बिना केवल ठोस प्रकार होते हैं
एक अतिरिक्त मूल्य का उपयोग करके गैर-सूचक प्रकार के साथ कार्यान्वित किया जा सकता है
वास्तविक प्रकार याद रखें।

सम-ऑफ-स्ट्रक्चर-प्रकार के लिए, अतिरिक्त पैडिंग का उपयोग करना भी संभव हो सकता है
उस उद्देश्य के लिए structs के लिए सामान्य बाइट्स।

@rogpeppe यह कैसे प्रकार के दावे और प्रकार स्विच के साथ बातचीत करेगा? संभावित रूप से यह एक प्रकार (या किसी प्रकार का दावा) पर case होने के लिए एक संकलन-समय त्रुटि होगी जो योग का सदस्य नहीं है। क्या इस तरह के प्रकार पर एक गैर-विस्तृत स्विच होना भी एक त्रुटि होगी?

टाइप स्विच के लिए, यदि आपके पास है

type T int | interface{}

और आप करते हैं:

switch t := t.(type) {
  case int:
    // ...

और t में एक इंटरफ़ेस {} है जिसमें एक int है, क्या यह पहले मामले से मेल खाता है? क्या होगा यदि पहला मामला case interface{} ?

या योग प्रकारों में केवल ठोस प्रकार हो सकते हैं?

type T interface{} | nil बारे में क्या? अगर आप लिखते हैं

var t T = nil

टी का प्रकार क्या है? या वह निर्माण वर्जित है? इसी तरह का प्रश्न type T []int | nil लिए उठता है, इसलिए यह केवल इंटरफेस के बारे में नहीं है।

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

इसका मतलब है कि यदि आपके पास त्रुटि है तो आप संकलक को त्रुटि प्राप्त कर सकते हैं:

func addOne(x int|float64) int|float64 {
    switch x := x.(type) {
    case int:
        return x + 1
    case float64:
         return x + 1
    }
}

और आप एक अतिरिक्त मामला जोड़ने के लिए योग प्रकार बदलते हैं।

टाइप स्विच के लिए, यदि आपके पास है

टाइप टी इंट | इंटरफेस{}

और आप करते हैं:

स्विच टी: = टी। (प्रकार) {
केस इंट:
//...
और t में एक इंटरफ़ेस {} है जिसमें एक int है, क्या यह पहले मामले से मेल खाता है? क्या होगा यदि पहला मामला केस इंटरफ़ेस {} है?

t में एक इंटरफ़ेस नहीं हो सकता {} जिसमें एक int हो। टी एक इंटरफ़ेस है
किसी अन्य इंटरफ़ेस प्रकार की तरह ही टाइप करें, सिवाय इसके कि यह केवल
इसमें शामिल प्रकारों का प्रगणित सेट होता है।
एक इंटरफ़ेस की तरह {} में एक इंटरफ़ेस नहीं हो सकता है {} जिसमें एक इंट हो।

योग प्रकार इंटरफ़ेस प्रकारों से मेल खा सकते हैं, लेकिन उन्हें अभी भी एक ठोस मिलता है
गतिशील मूल्य के लिए टाइप करें। उदाहरण के लिए, यह होना ठीक रहेगा:

type R io.Reader | io.ReadCloser

टाइप टी इंटरफेस के बारे में क्या {} | शून्य? अगर आप लिखते हैं

वर टी टी = शून्य

टी का प्रकार क्या है? या वह निर्माण वर्जित है? टाइप टी []int | . के लिए एक समान प्रश्न उठता है शून्य, तो यह सिर्फ इंटरफेस के बारे में नहीं है।

उपरोक्त प्रस्ताव के अनुसार, आपको पहला आइटम मिलता है
योग में कि मूल्य को सौंपा जा सकता है, इसलिए
आपको शून्य इंटरफ़ेस मिलेगा।

वास्तव में इंटरफ़ेस{} | शून्य तकनीकी रूप से बेमानी है, क्योंकि कोई भी इंटरफ़ेस {}
शून्य हो सकता है।

[]int | . के लिए nil, एक nil []int एक nil इंटरफ़ेस के समान नहीं है, इसलिए
([]int|nil)(nil) का ठोस मूल्य []int(nil) बिना टाइप किए nil ।

[]int | nil मामला दिलचस्प है। मैं उम्मीद करता हूं कि nil प्रकार की घोषणा में हमेशा "शून्य इंटरफ़ेस मान" का अर्थ होगा, इस मामले में

type T []int | nil
var x T = nil

इसका अर्थ यह होगा कि x nil इंटरफ़ेस है, nil []int ।

वह मान एक ही प्रकार में एन्कोड किए गए nil []int से अलग होगा:

var y T = []int(nil)  // y != x

क्या योग हमेशा सभी प्रकार के मूल्य होने पर भी शून्य की आवश्यकता नहीं होगी? अन्यथा var x int64 | float64 क्या होगा? मेरा पहला विचार, अन्य नियमों से अलग करना, पहले प्रकार का शून्य मान होगा, लेकिन फिर var x interface{} | int बारे में क्या? जैसा कि @bcmills बताते हैं, यह एक अलग योग शून्य होना चाहिए।

यह अति सूक्ष्म प्रतीत होता है।

संपूर्ण प्रकार के स्विच अच्छे होंगे। वांछित व्यवहार न होने पर आप हमेशा एक खाली default: जोड़ सकते हैं।

प्रस्ताव कहता है, "किसी योग प्रकार को मान निर्दिष्ट करते समय, यदि मान अधिक में फ़िट हो सकता है
संभावित प्रकारों में से एक से, फिर पहले को चुना जाता है।"

के साथ:

type T []int | nil
var x T = nil

x में ठोस प्रकार []int होगा क्योंकि nil []int को असाइन करने योग्य है और []int प्रकार का पहला तत्व है। यह किसी अन्य []int (शून्य) मान के बराबर होगा।

क्या योग हमेशा सभी प्रकार के मूल्य होने पर भी शून्य की आवश्यकता नहीं होगी? अन्यथा क्या होगा var x int64 | फ्लोट64 हो?

प्रस्ताव कहता है "एक योग प्रकार का शून्य मान पहले प्रकार का शून्य मान है
योग।", तो उत्तर int64(0) है।

मेरा पहला विचार, अन्य नियमों से अलग करना, पहले प्रकार का शून्य मान होगा, लेकिन फिर var x इंटरफ़ेस {} | के बारे में क्या होगा। NS? जैसा कि @bcmills बताते हैं, यह एक अलग राशि शून्य होना चाहिए

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

योग प्रकार का शून्य मान योग में पहले प्रकार का शून्य मान है।

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

तो (stuff) | nil केवल तभी समझ में आता है जब (सामान) में कुछ भी शून्य नहीं हो सकता है और nil | (stuff) अर्थ कुछ अलग हो सकता है, इस पर निर्भर करता है कि सामान में कुछ भी शून्य हो सकता है? शून्य क्या जोड़ता है?

@ianlancetaylor मेरा मानना ​​​​है कि कई कार्यात्मक भाषाएं अनिवार्य रूप से लागू (बंद) योग प्रकारों को लागू करती हैं जैसे आप C . में कैसे करेंगे

struct {
    int which;
    union {
         A a;
         B b;
         C c;
    } summands;
}

यदि which संघ के क्षेत्रों में अनुक्रमित करता है, तो 0 = a, 1 = b, 2 = c, सभी बाइट्स के लिए शून्य मान परिभाषा शून्य होती है। और आपको इंटरफेस के विपरीत, कहीं और प्रकारों को स्टोर करने की आवश्यकता होगी। जहां भी आप प्रकार की जानकारी संग्रहीत करते हैं, आपको किसी प्रकार के शून्य टैग के लिए विशेष हैंडलिंग की भी आवश्यकता होगी।

यह विशेष इंटरफेस के बजाय संघ के मूल्य प्रकार बना देगा, जो कि दिलचस्प भी है।

क्या सभी शून्य मान काम करने का कोई तरीका है यदि फ़ील्ड जो प्रकार रिकॉर्ड करता है उसके पास पहले प्रकार का प्रतिनिधित्व करने वाला शून्य मान होता है? मुझे लगता है कि इसका प्रतिनिधित्व करने का एक संभावित तरीका यह होगा:

type A = B|C
struct A {
  choice byte // value 0 or 1
  value ?// (thing big enough to store B | C)
}

[संपादित करें]

सॉरी @jimmyfrasche ने मुझे पंच मार दिया।

क्या शून्य से कुछ ऐसा जोड़ा गया है जिसके साथ नहीं किया जा सकता

type S int | string | struct{}
var None struct{}

?

ऐसा लगता है कि यह बहुत सारे भ्रम से बचा जाता है (जो मेरे पास है, कम से कम)

या और अच्छा

type (
     None struct{}
     S int | string | None
)

इस तरह आप None पर स्विच टाइप कर सकते हैं और None{} साथ असाइन कर सकते हैं

@jimmyfrasche struct{} बराबर नहीं है nil । यह एक मामूली विवरण है, लेकिन यह अन्य प्रकारों पर टाइप-स्विच से अनावश्यक रूप से (?) टाइप-स्विच को अलग कर देगा।

@bcmills अन्यथा दावा करने का मेरा इरादा नहीं

@rogpeppe यह क्या प्रिंट करता है?

// r is an io.Reader interface value holding a type that also implements io.Closer
var v io.ReadCloser | io.Reader = r
switch v.(type) {
case io.ReadCloser: fmt.Println("ReadCloser")
case io.Reader: fmt.Println("Reader")
}

मैं "पाठक" मानूंगा

@jimmyfrasche मैं मान ReadCloser , जैसा कि आप किसी अन्य इंटरफ़ेस पर टाइप-स्विच से प्राप्त करेंगे।

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

@bcmills यह वह https://play.golang.org/p/PzmWCYex6R

@ianlancetaylor यह बढ़ाने के लिए एक उत्कृष्ट बिंदु है, धन्यवाद। मुझे नहीं लगता कि इसे प्राप्त करना मुश्किल है, हालांकि इसका मतलब यह है कि मेरा "बेवकूफ कार्यान्वयन" सुझाव स्वयं भी बेवकूफ है। एक योग प्रकार, हालांकि एक इंटरफ़ेस प्रकार के रूप में माना जाता है, में वास्तव में प्रकार और इसकी विधि सेट के लिए प्रत्यक्ष सूचक नहीं होता है - इसके बजाय, जब उपयुक्त हो, तो एक पूर्णांक टैग हो सकता है जो प्रकार का तात्पर्य करता है। वह टैग गैर-शून्य हो सकता है, भले ही वह प्रकार शून्य हो।

दिया गया:

 var x int | nil = nil

x का रनटाइम मान सभी शून्य नहीं होना चाहिए। x के प्रकार पर स्विच करते समय या कनवर्ट करते समय
इसे किसी अन्य इंटरफ़ेस प्रकार के लिए, टैग को एक छोटी तालिका के माध्यम से अप्रत्यक्ष किया जा सकता है जिसमें
वास्तविक प्रकार के संकेत।

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

var t nil | int
var u float64 | t

@jimmyfrasche मैं ReadCloser मानूंगा, जैसा कि आप किसी अन्य इंटरफ़ेस पर टाइप-स्विच से प्राप्त करेंगे।

हां।

@bcmills यह वह https://play.golang.org/p/PzmWCYex6R

मुझे यह नहीं मिला। रीडक्लोजर प्रिंट करने के लिए टाइप स्विच के लिए "यह [...] मान्य क्यों होगा"
किसी भी इंटरफ़ेस प्रकार की तरह, एक योग प्रकार उसमें मौजूद चीज़ों के ठोस मूल्य से अधिक संग्रहीत नहीं करेगा।

जब एक योग में कई इंटरफ़ेस प्रकार होते हैं, तो रनटाइम प्रतिनिधित्व केवल एक इंटरफ़ेस मान होता है - यह सिर्फ इतना है कि हम जानते हैं कि अंतर्निहित मान को घोषित संभावनाओं में से एक या अधिक को लागू करना चाहिए।

यानी, जब आप किसी प्रकार (I1 | I2) को कुछ असाइन करते हैं, जहां I1 और I2 दोनों इंटरफ़ेस प्रकार हैं, तो बाद में यह बताना संभव नहीं है कि आपने जो मान डाला था वह उस समय I1 या I2 को लागू करने के लिए जाना जाता था।

यदि आपके पास एक प्रकार है जो io.ReadCloser | . है io.Reader जब आप स्विच टाइप करते हैं या io.Reader पर जोर देते हैं तो आप सुनिश्चित नहीं हो सकते हैं कि यह io.ReadCloser नहीं है जब तक कि योग प्रकार को असाइनमेंट अनबॉक्स नहीं करता है और इंटरफ़ेस को रीबॉक्स करता है।

दूसरी तरफ जा रहे हैं, अगर आपके पास io.Reader | io.ReadCloser यह या तो कभी भी io.ReadCloser को स्वीकार नहीं करेगा क्योंकि यह सख्ती से दाएं से बाएं जाता है या कार्यान्वयन को योग में सभी इंटरफेस से "सर्वश्रेष्ठ मिलान" इंटरफ़ेस खोजना होगा लेकिन इसे अच्छी तरह परिभाषित नहीं किया जा सकता है।

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

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

@griesemer हाँ, यह सही है।

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

@jimmyfrasche

यदि आपके पास एक प्रकार है जो io.ReadCloser | . है io.Reader जब आप स्विच टाइप करते हैं या io.Reader पर जोर देते हैं तो आप सुनिश्चित नहीं हो सकते हैं कि यह io.ReadCloser नहीं है जब तक कि योग प्रकार को असाइनमेंट अनबॉक्स नहीं करता है और इंटरफ़ेस को रीबॉक्स करता है।

यह आपके पास वह प्रकार है, आप जानते हैं कि यह हमेशा एक io.Reader होता है (या शून्य, क्योंकि कोई भी io.Reader भी शून्य हो सकता है)। दो विकल्प अनन्य नहीं हैं - प्रस्तावित योग प्रकार एक "समावेशी या" है न कि "अनन्य या"।

दूसरी तरफ जा रहे हैं, अगर आपके पास io.Reader | io.ReadCloser यह या तो कभी भी io.ReadCloser को स्वीकार नहीं करेगा क्योंकि यह सख्ती से दाएं से बाएं जाता है या कार्यान्वयन को योग में सभी इंटरफेस से "सर्वश्रेष्ठ मिलान" इंटरफ़ेस खोजना होगा लेकिन इसे अच्छी तरह परिभाषित नहीं किया जा सकता है।

यदि "दूसरे रास्ते पर जाकर", आपका मतलब उस प्रकार को असाइन करना है, तो प्रस्ताव कहता है:

"किसी योग प्रकार को मान निर्दिष्ट करते समय, यदि मान अधिक में फ़िट हो सकता है
संभावित प्रकारों में से एक से, फिर पहले को चुना जाता है।"

इस मामले में, एक io.ReadCloser एक io.Reader और एक io.ReadCloser दोनों में फिट हो सकता है, इसलिए यह io.Reader चुनता है, लेकिन वास्तव में बाद में बताने का कोई तरीका नहीं है। प्रकार io.Reader और प्रकार io.Reader | . के बीच कोई पता लगाने योग्य अंतर नहीं है io.ReadCloser, क्योंकि io.Reader io.Reader को लागू करने वाले सभी इंटरफ़ेस प्रकारों को भी धारण कर सकता है। इसलिए मुझे संदेह है कि संकलक को इस तरह से अस्वीकार करना एक अच्छा विचार हो सकता है। उदाहरण के लिए, यह इंटरफ़ेस से जुड़े किसी भी योग प्रकार को अस्वीकार कर सकता है {} क्योंकि इंटरफ़ेस {} में पहले से ही कोई भी प्रकार हो सकता है, इसलिए अतिरिक्त योग्यताएं कोई जानकारी नहीं जोड़ती हैं।

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

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

आइए, फिलहाल, मेरे पिछले उदाहरण का उपयोग करें और कहें कि आरसी एक संरचना है जिसे io.ReadCloser को सौंपा जा सकता है।

अगर तुम यह करते हो

var v io.ReadCloser | io.Reader = RC{}

परिणाम स्पष्ट और स्पष्ट हैं।

हालांकि, अगर आप ऐसा करते हैं

var r io.Reader = RC{}
var v io.ReadCloser | io.Reader = r

केवल समझदार बात यह है कि एक io.Reader के रूप में v store r है, लेकिन इसका मतलब है कि जब आप v पर स्विच टाइप करते हैं तो आप सुनिश्चित नहीं हो सकते कि जब आप io.Reader केस को हिट करते हैं तो आपके पास वास्तव में एक नहीं है आईओ.रीडक्लोजर। आपके पास कुछ ऐसा होना चाहिए:

switch v := v.(type) {
case io.ReadCloser: useReadCloser(v)
case io.Reader:
  if rc, ok := v.(io.ReadCloser); ok {
    useReadCloser(rc)
  } else {
    useReader(v)
  }
}

अब, एक समझ है जिसमें io.ReadCloser <: io.Reader, और जैसा कि आपने सुझाव दिया है, आप उन्हें अस्वीकार कर सकते हैं, लेकिन मुझे लगता है कि समस्या अधिक मौलिक है और गो के लिए किसी भी प्रकार के प्रस्ताव पर लागू हो सकती है।

मान लें कि आपके पास क्रमशः ए (), बी (), और सी () विधियों के साथ ए, बी, और सी तीन इंटरफेस हैं, और तीनों विधियों के साथ एक स्ट्रक्चर एबीसी है। A, B, और C असंयुक्त हैं इसलिए A | बी | सी और इसके क्रमपरिवर्तन सभी मान्य प्रकार हैं। लेकिन आपके पास अभी भी ऐसे मामले हैं

var c C = ABC{}
var v A | B | C = c

इसे पुनर्व्यवस्थित करने के कई तरीके हैं और आपको अभी भी इस बारे में कोई सार्थक गारंटी नहीं मिलती है कि इंटरफेस शामिल होने पर v क्या है। आपके द्वारा राशि को अनबॉक्स करने के बाद यदि ऑर्डर महत्वपूर्ण है तो आपको इंटरफ़ेस को अनबॉक्स करने की आवश्यकता है।

हो सकता है कि प्रतिबंध यह होना चाहिए कि कोई भी सारांश इंटरफेस बिल्कुल भी नहीं हो सकता है?

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

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

@jimmyfrasche आदेशित अनबॉक्सिंग के लिए उपयोग-मामला वास्तव में महत्वपूर्ण है? यही कारण है कि मेरे लिए स्पष्ट नहीं है, और ऐसे मामलों में जहां यह महत्वपूर्ण है के लिए यह स्पष्ट बॉक्स structs के साथ चारों ओर काम करने के लिए आसान है:

type ReadCloser struct {  io.ReadCloser }
type Reader struct { io.Reader }

var v ReadCloser | Reader = Reader{r}

@bcmills यह अधिक है कि परिणाम स्पष्ट और

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

सभी गारंटियां जो आप एक राशि प्रकार के साथ चाहते हैं

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

यही है, यदि किसी मान को असाइनमेंट-संगत होने के आधार पर किसी योग प्रकार को असाइन किया जा सकता है
योग प्रकार के सदस्यों में से एक के साथ, हम रिकॉर्ड नहीं करते हैं कि उनमें से कौन सा सदस्य रहा है
"चुना हुआ" - हम केवल मान को ही रिकॉर्ड करते हैं। ठीक उसी तरह जब आप एक io.Reader असाइन करते हैं
एक इंटरफ़ेस के लिए {}, आप स्थिर io.Reader प्रकार खो देते हैं और केवल मान ही होता है
जो io.Reader के साथ संगत है लेकिन किसी अन्य इंटरफ़ेस प्रकार के साथ भी ऐसा होता है
लागू करने के लिए।

आपके उदाहरण में:

var c C = ABC{}
var v A | B | C = c

ए, बी और सी में से किसी के लिए वी का एक प्रकार का दावा सफल होगा। यह मुझे उचित लगता है।

@rogpeppe वे शब्दार्थ जो मैं कल्पना कर रहा था उससे अधिक समझ में आता है। मैं अभी भी पूरी तरह से आश्वस्त नहीं हूं कि इंटरफेस और योग अच्छी तरह से मिलते हैं, लेकिन मुझे अब यकीन नहीं है कि वे नहीं करते हैं। प्रगति!

मान लें कि आपके पास type U I | *T जहां I एक इंटरफ़ेस प्रकार है और *T एक प्रकार है जो I ।

दिया गया

var i I = new(T)
var u U = i

u का गतिशील प्रकार *T , और in

var u U = new(T)

आप उस *T को I के रूप में एक प्रकार के दावे के साथ एक्सेस कर सकते हैं। क्या वो सही है?

इसका मतलब यह होगा कि एक वैध इंटरफ़ेस मान से योग के लिए असाइनमेंट को योग में पहले मिलान प्रकार की खोज करनी होगी।

यह var v uint8 | int32 | int64 = i जैसी किसी चीज़ से कुछ अलग भी होगा, जो मुझे लगता है, बस हमेशा उन तीन प्रकारों में से जो भी i , भले ही i एक int64 जो uint8 में फिट हो सकता है।

प्रगति!

वाह!

आप उस * टी को एक प्रकार के दावे के साथ I के रूप में एक्सेस कर सकते हैं। क्या वो सही है?

हां।

इसका मतलब यह होगा कि एक वैध इंटरफ़ेस मान से योग के लिए असाइनमेंट को योग में पहले मिलान प्रकार की खोज करनी होगी।

हाँ, जैसा कि प्रस्ताव कहता है (बेशक संकलक स्थिर रूप से जानता है कि कौन सा चुनना है, इसलिए रनटाइम पर कोई खोज नहीं है)।

यह var v uint8 | . जैसी किसी चीज़ से कुछ अलग भी होगा int32 | int64 = i जो, मैं कल्पना करता हूं, हमेशा उन तीन प्रकारों में से जो भी हो, मैं हमेशा के साथ जाता हूं, भले ही मैं एक int64 था जो uint8 में फिट हो सकता था।

हां, क्योंकि जब तक मैं स्थिर नहीं हूं, यह केवल उन विकल्पों में से एक को असाइन करने योग्य होगा।

हां, क्योंकि जब तक मैं स्थिर नहीं हूं, यह केवल उन विकल्पों में से एक को असाइन करने योग्य होगा।

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

तो मेरी पिछली पोस्ट से I | *T प्रकार प्रभावी रूप से वही है जैसे I और io.ReadCloser | io.Reader प्रभावी रूप से io.Reader के समान प्रकार है?

ये सही है। दोनों प्रकार मेरे सुझाए गए नियम द्वारा कवर किए जाएंगे कि संकलक योग प्रकारों को अस्वीकार करता है जहां एक प्रकार एक इंटरफ़ेस है जिसे किसी अन्य प्रकार द्वारा कार्यान्वित किया जाता है। समान या समान नियम int|int जैसे डुप्लिकेट प्रकारों के साथ योग प्रकारों को कवर कर सकता है।

एक सोचा: यह शायद unintuitive है कि int|byte के समान नहीं है byte|int , लेकिन यह व्यवहार में शायद ठीक है।

इसका मतलब यह होगा कि एक वैध इंटरफ़ेस मान से योग के लिए असाइनमेंट को योग में पहले मिलान प्रकार की खोज करनी होगी।

हाँ, जैसा कि प्रस्ताव कहता है (बेशक संकलक स्थिर रूप से जानता है कि कौन सा चुनना है, इसलिए रनटाइम पर कोई खोज नहीं है)।

मैं इसका पालन नहीं कर रहा हूं। जिस तरह से मैंने इसे पढ़ा (जो कि जो इरादा था उससे अलग हो सकता है) I और T-उपकरण- I के संघ U से निपटने के कम से कम दो तरीके हैं।

1a) U u = t असाइनमेंट पर, टैग को T पर सेट किया जाता है। बाद में चयन का परिणाम T होता है क्योंकि टैग एक T होता है।
1b) U u = i (i वास्तव में एक T है) के असाइनमेंट पर, टैग I पर सेट है। बाद में चयन का परिणाम T में होता है क्योंकि टैग एक I है लेकिन दूसरा चेक है (प्रदर्शन किया जाता है क्योंकि T I और T को लागू करता है) यू का सदस्य है) एक टी की खोज करता है।

2a) 1a . की तरह
2b) U u = i असाइनमेंट पर (i वास्तव में एक T है), जेनरेट कोड यह देखने के लिए मान (i) की जांच करता है कि क्या यह वास्तव में T है, क्योंकि T लागू करता है I और T भी U का सदस्य है। क्योंकि यह है, टैग टी पर सेट है। बाद में चयन सीधे टी में परिणाम देता है।

उस स्थिति में जब T, V, W सभी I और U = *T | *V | *W | I , असाइनमेंट U u = i लिए 3 प्रकार के परीक्षणों की आवश्यकता होती है।

यूनियन प्रकारों के लिए इंटरफेस और पॉइंटर्स मूल उपयोग केस नहीं थे, हालांकि, क्या यह था?

मैं कुछ प्रकार की हैकरी की कल्पना कर सकता हूं जहां एक "अच्छा" कार्यान्वयन कुछ बिट बैंगिंग करेगा - उदाहरण के लिए, यदि आपके पास 4 या उससे कम पॉइंटर प्रकार का संघ है जहां सभी संदर्भ 4-बाइट गठबंधन हैं, तो टैग को निचले 2 में स्टोर करें मूल्य के बिट्स। बदले में इसका तात्पर्य यह है कि किसी संघ के सदस्य का पता लेना अच्छा नहीं है (यह किसी भी तरह से नहीं होगा, क्योंकि उस पते का उपयोग टैग को समायोजित किए बिना "पुराने" प्रकार को फिर से संग्रहीत करने के लिए किया जा सकता है)।

या अगर हमारे पास 50-ईश-बिट एड्रेस स्पेस था और हम NaN के साथ कुछ स्वतंत्रता लेने के इच्छुक थे, तो हम पूर्णांक, पॉइंटर्स और डबल्स को 64-बिट यूनियन में थप्पड़ मार सकते थे, और कुछ बिट फ़िडलिंग की संभावित लागत।

दोनों उप-सुझाव स्थूल हैं, मुझे यकीन है कि दोनों में कट्टर समर्थकों की एक छोटी (?) संख्या होगी।

इसका अर्थ यह है कि संघ के किसी सदस्य का पता लेना ठीक नहीं है

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

यू यू = आई (मैं वास्तव में एक टी है) के असाइनमेंट पर, टैग I पर सेट है।

मुझे लगता है कि यह क्रूक्स है - कोई टैग I नहीं है।

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

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

यूनियन प्रकारों के लिए इंटरफेस और पॉइंटर्स मूल उपयोग केस नहीं थे, हालांकि, क्या यह था?

ऐसा नहीं था, लेकिन मेरे विचार में, किसी भी प्रस्ताव को अन्य भाषा सुविधाओं के संबंध में जितना संभव हो उतना ऑर्थोगोनल होना चाहिए।

@ dr2chase मेरी समझ अब तक यह है कि, यदि किसी योग प्रकार में इसकी परिभाषा में कोई इंटरफ़ेस प्रकार शामिल है, तो रनटाइम पर इसका कार्यान्वयन एक इंटरफ़ेस के समान होता है (विधि सेटों के चौराहे वाले) लेकिन स्वीकार्य प्रकारों के बारे में संकलन-समय अपरिवर्तनीय अभी भी हैं लागू किया गया

यहां तक ​​​​कि अगर एक योग प्रकार में केवल ठोस प्रकार होते हैं और इसे सी-शैली के भेदभाव वाले संघ की तरह लागू किया जाता है, तो आप योग प्रकार में एक मूल्य को संबोधित करने में सक्षम नहीं होंगे क्योंकि आपके द्वारा लिए जाने के बाद वह पता एक अलग प्रकार (और आकार) बन सकता है ये पता। हालाँकि, आप योग टाइप किए गए मूल्य का पता स्वयं ले सकते हैं।

क्या यह वांछनीय है कि योग प्रकार इस तरह से व्यवहार करते हैं? हम आसानी से यह घोषणा कर सकते हैं कि चयनित/जोर दिया गया प्रकार वही है जो प्रोग्रामर ने कहा/निहित है जब संघ को एक मूल्य सौंपा गया था। अन्यथा हम int8 बनाम int16 बनाम int32, आदि के संबंध में दिलचस्प स्थानों तक पहुंच सकते हैं या, उदाहरण के लिए, int8 | uint8 ।

क्या यह वांछनीय है कि योग प्रकार इस तरह से व्यवहार करते हैं?

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

अन्यथा हम int8 बनाम int16 बनाम int32, आदि के संबंध में दिलचस्प स्थानों तक पहुंच सकते हैं या, उदाहरण के लिए, int8 | uint8.

यहाँ आपकी क्या चिंता है?

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

एक योग प्रकार के साथ आप किस प्रकार के प्रोग्राम लिख सकते हैं जिसमें इंटरफेस शामिल हैं जो आप अन्यथा नहीं कर सकते हैं?

वैकल्पिक प्रस्ताव।

एक संघ प्रकार एक प्रकार है जो शून्य या अधिक प्रकारों को सूचीबद्ध करता है, लिखा जाता है

union {
  T0
  T1
  //...
  Tn
}

संघ में सभी सूचीबद्ध प्रकार (T0, T1, ..., Tn) अलग-अलग होने चाहिए और कोई भी इंटरफ़ेस प्रकार नहीं हो सकता।

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

संघ प्रकारों के लिए कोई एम्बेडिंग नहीं है। एक यूनियन प्रकार को दूसरे में सूचीबद्ध करना किसी अन्य वैध प्रकार को सूचीबद्ध करने जैसा ही है। हालाँकि, एक संघ अपने स्वयं के प्रकार को पुनरावर्ती रूप से सूचीबद्ध नहीं कर सकता है, उसी कारण से कि type S struct { S } अमान्य है।

यूनियनों को स्ट्रक्चर्स में एम्बेड किया जा सकता है।

संघ प्रकार का मान एक गतिशील प्रकार होता है, जो सूचीबद्ध प्रकारों में से एक तक सीमित होता है, और गतिशील प्रकार का मान-संग्रहीत मान कहा जाता है। सूचीबद्ध प्रकारों में से एक हर समय गतिशील प्रकार है।

खाली संघ का शून्य मान अद्वितीय है। एक गैर-रिक्त संघ का शून्य मान संघ में सूचीबद्ध पहले प्रकार का शून्य मान है।

संघ प्रकार के लिए एक मान, U , शून्य मान के लिए U{} के साथ बनाया जा सकता है। यदि U में एक या अधिक प्रकार हैं और v सूचीबद्ध प्रकारों में से एक का मान है, तो T , U{v} v संग्रहीत करने वाला एक संघ मूल्य बनाता है T । यदि v एक प्रकार का है जो U में सूचीबद्ध नहीं है जिसे सूचीबद्ध प्रकारों में से एक से अधिक को सौंपा जा सकता है, तो स्पष्ट रूपांतरण की आवश्यकता है।

एक संघ प्रकार का एक मूल्य U को दूसरे संघ प्रकार V में परिवर्तित किया जा सकता है जैसा कि V(U{}) यदि U में प्रकारों का सेट इसका सबसेट है V में प्रकारों का सेट। अर्थात्, आदेश को अनदेखा करते हुए, U में V के समान सभी प्रकार होने चाहिए, और U ऐसे प्रकार नहीं हो सकते जो V बल्कि V ऐसे प्रकार हो सकते हैं जो U ।

यूनियन प्रकारों के बीच असाइनमेंट को परिवर्तनीयता के रूप में परिभाषित किया जाता है, जब तक कि यूनियन प्रकारों में से अधिकांश को परिभाषित (नामांकित) किया जाता है।

सूचीबद्ध प्रकारों में से एक का मान, T , एक संघ प्रकार का U संघ प्रकार U एक चर को सौंपा जा सकता है। यह डायनामिक प्रकार को T सेट करता है और मान को संग्रहीत करता है। असाइनमेंट संगत मान ऊपर के रूप में काम करते हैं।

यदि सभी सूचीबद्ध प्रकार समानता ऑपरेटरों का समर्थन करते हैं:

• समानता ऑपरेटरों का उपयोग एक ही संघ प्रकार के दो मूल्यों पर किया जा सकता है। एक संघ प्रकार के दो मान कभी समान नहीं होते हैं यदि उनके गतिशील प्रकार भिन्न होते हैं।
• उस संघ के मूल्य की तुलना उसके किसी भी सूचीबद्ध प्रकार के मूल्य से की जा सकती है। यदि यूनियन का डायनामिक प्रकार अन्य ऑपरेंड का प्रकार नहीं है, तो == गलत है और संग्रहीत मूल्य की परवाह किए बिना != सत्य है। असाइनमेंट संगत मान ऊपर के रूप में काम करते हैं।
• संघ का उपयोग मानचित्र कुंजी के रूप में किया जा सकता है

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

इसके सूचीबद्ध प्रकारों में से किसी एक के लिए संघ प्रकार के विरुद्ध एक प्रकार का अभिकथन धारण करता है यदि मुखर प्रकार गतिशील प्रकार है।

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

प्रकार स्विच या तो संपूर्ण होने चाहिए, सभी सूचीबद्ध प्रकारों सहित, या उनमें एक डिफ़ॉल्ट केस होना चाहिए।

प्रकार के दावे और प्रकार स्विच संग्रहीत मूल्य की एक प्रति लौटाते हैं।

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

टिप्पणियाँ:

union{...} सिंटैक्स को आंशिक रूप से इस थ्रेड में योग प्रकार के प्रस्ताव से अलग करने के लिए चुना गया था, मुख्य रूप से गो व्याकरण में अच्छे गुणों को बनाए रखने के लिए, और संयोग से यह मजबूत करने के लिए कि यह एक भेदभावपूर्ण संघ है। परिणामस्वरूप, यह कुछ अजीब यूनियनों जैसे union{} और union{ int } । पहला कई अर्थों में struct{} (हालांकि परिभाषा के अनुसार एक अलग प्रकार) के बराबर है, इसलिए यह एक और खाली प्रकार जोड़ने के अलावा, भाषा में नहीं जोड़ता है। दूसरा शायद अधिक उपयोगी है। उदाहरण के लिए, type Id union { int } बहुत हद तक type Id struct { int } सिवाय इसके कि संघ संस्करण idValue.int को निर्दिष्ट किए बिना सीधे असाइनमेंट की अनुमति देता है जिससे यह एक अंतर्निहित प्रकार की तरह प्रतीत होता है।

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

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

सूचीबद्ध प्रकारों के तरीकों के वैध प्रतिच्छेदन को लेने के बजाय संघ पर ही अनुमति देने के तरीके गलती से अवांछित तरीके प्राप्त करने से बचते हैं। सामान्य इंटरफेस के लिए संग्रहीत मूल्य पर जोर देने का प्रकार प्रचार वांछित होने पर सरल, स्पष्ट रैपर विधियों की अनुमति देता है। उदाहरण के लिए, एक संघ प्रकार पर U जिसके सभी सूचीबद्ध प्रकार लागू होते हैं fmt.Stringer :

func (u U) String() string {
  return u.(fmt.Stringer).String()
}

लिंक किए गए रेडिट थ्रेड में, rsc ने कहा:

योग के शून्य मान के लिए यह अजीब होगा {X; Y } योग {Y; एक्स }। ऐसा नहीं है कि रकम आमतौर पर कैसे काम करती है।

मैं इस बारे में सोच रहा हूं, क्योंकि यह वास्तव में किसी भी प्रस्ताव पर लागू होता है।

यह कोई बग नहीं है: यह एक विशेषता है।

विचार करना

type (
  Undefined = struct{}
  UndefinedOrInt union { Undefined; int }
)

बनाम

type (
  Illegal = struct{}
  IntOrIllegal union { int; Illegal }
)

UndefinedOrInt डिफ़ॉल्ट रूप से कहता है कि यह अभी तक परिभाषित नहीं है, लेकिन, जब यह होगा, तो यह int मान होगा। यह *int समान है, इस प्रकार योग प्रकार (1 + int) को अब गो में प्रदर्शित करने की आवश्यकता है और शून्य मान भी समान है।

दूसरी ओर, IntOrIllegal , डिफ़ॉल्ट रूप से कहता है कि यह int 0 है, लेकिन इसे किसी बिंदु पर अवैध के रूप में चिह्नित किया जा सकता है। यह अभी भी *int लेकिन शून्य मान इरादे का अधिक अभिव्यंजक है, जैसे कि यह लागू करना कि यह डिफ़ॉल्ट रूप से new(int) ।

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

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

यदि योग सप्ताह के एक दिन थे (प्रत्येक दिन एक परिभाषित struct{} ), जो भी पहले सूचीबद्ध है वह सप्ताह का पहला दिन है, iota -स्टाइल एनम के लिए समान है।

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

यदि "योग" और "संघ" की गणितीय अवधारणाओं से अंतर समस्या है, तो हम उन्हें हमेशा कुछ और कह सकते हैं (उदाहरण के लिए "संस्करण")।

नामों के लिए: संघ c/c++ शुद्धतावादियों को भ्रमित करता है। वेरिएंट मुख्य रूप से COBRA और COM प्रोग्रामर्स से परिचित है, जहां भेदभावपूर्ण संघ को कार्यात्मक भाषाओं द्वारा पसंद किया जाता है। सेट एक क्रिया और संज्ञा है। मुझे कीवर्ड _pick_ पसंद है। लिम्बो ने _pick_ का इस्तेमाल किया। यह छोटा है और प्रकार के एक सीमित सेट से चुनने के प्रकार के इरादे का वर्णन करता है।

नाम/वाक्यविन्यास काफी हद तक अप्रासंगिक है। चुनना ठीक रहेगा।

इस सूत्र में कोई भी प्रस्ताव सेट सैद्धांतिक परिभाषा में फिट बैठता है।

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

@jimmyfrasche

मैं व्यक्तिगत रूप से मानता हूं कि इंटरफेस को 'पिक' सदस्यों के रूप में अस्वीकार करना एक बहुत बड़ी कमी है। सबसे पहले, यह 'पिक' प्रकारों के महान उपयोग मामलों में से एक को पूरी तरह से हरा देगा - एक त्रुटि होने पर सदस्यों में से एक होना चाहिए। या आप एक ऐसे पिक प्रकार से निपटना चाहते हैं जिसमें या तो एक io.Reader या एक स्ट्रिंग है, यदि आप उपयोगकर्ता को पहले से StringReader का उपयोग करने के लिए बाध्य नहीं करना चाहते हैं। लेकिन सब कुछ, एक इंटरफ़ेस सिर्फ एक और प्रकार है, और मेरा मानना ​​​​है कि 'पिक' सदस्यों के लिए टाइप प्रतिबंध नहीं होना चाहिए। ऐसा होने पर, यदि एक पिक प्रकार में 2 इंटरफ़ेस सदस्य होते हैं, जहां एक दूसरे द्वारा पूरी तरह से संलग्न होता है, तो यह एक संकलन-समय त्रुटि होनी चाहिए, जैसा कि पहले उल्लेख किया गया है।

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

@rogpeppe @jimmyfrasche कुछ ऐसा जो मुझे आपके प्रस्तावों में नहीं दिख रहा है, इसलिए हमें ऐसा करना चाहिए। एक नए प्रकार के प्रकार को जोड़ने का एक स्पष्ट नुकसान है: यह एक नई अवधारणा है जिसे हर किसी को सीखना होगा जो गो का सहारा लेता है। क्षतिपूर्ति लाभ क्या है? विशेष रूप से, नए प्रकार का प्रकार हमें क्या देता है जो हमें इंटरफ़ेस प्रकारों से नहीं मिलता है?

@ianlancetaylor रॉबर्ट ने इसे यहाँ अच्छी तरह से संक्षेप में प्रस्तुत किया है: https://github.com/golang/go/issues/19412#issuecomment -288608089

@ianlancetaylor
दिन के अंत में, यह कोड को और अधिक पठनीय बनाता है, और यही गो का मुख्य निर्देश है। Json.Token पर विचार करें, इसे वर्तमान में एक इंटरफ़ेस {} के रूप में परिभाषित किया गया है, हालांकि दस्तावेज़ीकरण में कहा गया है कि यह वास्तव में केवल विशिष्ट प्रकार के प्रकारों में से एक हो सकता है। यदि, दूसरी ओर, इसे इस प्रकार लिखा जाता है

type Token Delim | bool | float64 | Number | string | nil

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

दिन के अंत में, यह कोड को और अधिक पठनीय बनाता है, और यही गो का मुख्य निर्देश है।

अधिक सुविधाओं का मतलब है कि किसी को कोड को समझने के लिए और जानना होगा। किसी भाषा के औसत-केवल ज्ञान वाले व्यक्ति के लिए इसकी पठनीयता अनिवार्य रूप से [नई जोड़ी गई] सुविधाओं की संख्या के विपरीत आनुपातिक है।

@cznic

अधिक सुविधाओं का मतलब है कि किसी को कोड को समझने के लिए और जानना होगा।

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

यदि बेहतर संकलन-समय प्रकार की जाँच वास्तव में एकमात्र लाभ है, तो हम पशु चिकित्सक द्वारा जाँच की गई टिप्पणी को पेश करके भाषा को बदले बिना बहुत समान लाभ प्राप्त कर सकते हैं। कुछ इस तरह

//vet:types Delim | bool | float64 | Number | string | nil
type Token interface{}

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

कई, शायद सभी, cmd/vet द्वारा किए गए परीक्षणों को भाषा में जोड़ा जा सकता है, इस अर्थ में कि उन्हें एक अलग स्थिर विश्लेषण उपकरण के बजाय संकलक द्वारा जांचा जा सकता है। लेकिन विभिन्न कारणों से हमें पशु चिकित्सक को संकलक से अलग करना उपयोगी लगता है। यह अवधारणा पशु चिकित्सक के बजाय भाषा पक्ष पर क्यों आती है?

@ianlancetaylor ने टिप्पणियों की फिर से जाँच की: https://github.com/BurntSushi/go-sumtype

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

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

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

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

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

@ianlancetaylor

यह अवधारणा पशु चिकित्सक के बजाय भाषा पक्ष पर क्यों आती है?

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

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

गो के संदर्भ में, ऐसा लगता है कि vet में सुविधाओं को रखने का मुख्य कारण उन परिवर्तनों को लागू करना है जो भाषा पर लागू होने पर गो 1 संगतता को संरक्षित नहीं करेंगे। मैं इसे यहां एक मुद्दे के रूप में नहीं देखता।

सुविधाओं को vet में न रखने का एक कारण

switch x := somepkg.SomeFunc().(type) {
…
}

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

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

@बीसीमिल्स

यह अवधारणा पशु चिकित्सक के बजाय भाषा पक्ष पर क्यों आती है?

आप उसी प्रश्न को ट्यूरिंग-पूर्ण कोर के बाहर किसी भी सुविधा पर लागू कर सकते हैं ....

मैं सहमत नहीं हूं। यदि चर्चा के तहत फीचर संकलित कोड को प्रभावित करता है, तो इसके पक्ष में एक स्वचालित तर्क है। इस मामले में, सुविधा स्पष्ट रूप से संकलित कोड को प्रभावित नहीं करती है।

(और, हाँ, पशु चिकित्सक आयातित पैकेजों के स्रोत को पार्स कर सकता है।)

मैं यह दावा करने की कोशिश नहीं कर रहा हूं कि पशु चिकित्सक के बारे में मेरा तर्क निर्णायक है। लेकिन प्रत्येक भाषा परिवर्तन एक नकारात्मक स्थिति से शुरू होता है: एक सरल भाषा बहुत ही वांछनीय है, और इस तरह की एक महत्वपूर्ण नई विशेषता अनिवार्य रूप से भाषा को और अधिक जटिल बनाती है। भाषा परिवर्तन के पक्ष में आपको मजबूत तर्कों की आवश्यकता है। और मेरे नजरिए से वे मजबूत तर्क अभी सामने नहीं आए हैं। आखिरकार, हमने इस मुद्दे के बारे में लंबे समय तक सोचा है, और यह एक सामान्य प्रश्न है (https://golang.org/doc/faq#variant_types)।

@ianlancetaylor

इस मामले में, सुविधा स्पष्ट रूप से संकलित कोड को प्रभावित नहीं करती है।

मुझे लगता है कि यह विशिष्ट विवरण पर निर्भर करता है? "योग का शून्य-मान पहले प्रकार का शून्य-मान है" व्यवहार जो @jimmyfrasche ने ऊपर उल्लेख किया है (https://github.com/golang/go/issues/19412#issuecomment-289319916) निश्चित रूप से होगा।

@urandom मैं एक लंबी व्याख्या लिख ​​रहा था कि इंटरफ़ेस और यूनियन प्रकार स्पष्ट प्रकार के

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

संघ के पास स्पष्ट "फ़ील्ड नाम" हैं जिन्हें इसके बाद "टैग नाम" कहा जाता है:

union { //or whatever
  None, invalid struct{} //None is zero value
  Good, Bad int
  Err error //okay because it's explicitly named
}

अभी भी कोई एम्बेडिंग नहीं है। टैग नाम के बिना टाइप रखना हमेशा एक त्रुटि है।

यूनियन मानों में डायनामिक प्रकार के बजाय डायनामिक टैग होता है।

शाब्दिक मूल्य निर्माण: U{v} पूरी तरह से स्पष्ट होने पर ही मान्य है, अन्यथा इसे U{Tag: v} ।

परिवर्तनीयता और असाइनमेंट संगतता टैग नामों को भी ध्यान में रखते हैं।

एक संघ को असाइनमेंट जादू नहीं है। इसका मतलब हमेशा एक संगत संघ मूल्य निर्दिष्ट करना होता है। संग्रहीत मान सेट करने के लिए, वांछित टैग नाम का स्पष्ट रूप से उपयोग किया जाना चाहिए: v.Good = 1 डायनामिक टैग को अच्छा और संग्रहीत मान को 1 पर सेट करता है।

संग्रहीत मूल्य तक पहुँचने के लिए एक प्रकार के दावे के बजाय एक टैग अभिकथन का उपयोग किया जाता है:

g := v.[Tag] //may panic
g, ok := v.[Tag] //no panic but could return zero-value, false

v.Tag rhs पर एक त्रुटि है क्योंकि यह अस्पष्ट है।

टैग स्विच टाइप स्विच की तरह होते हैं, जिन्हें switch v.[type] लिखा जाता है, सिवाय इसके कि केस यूनियन के टैग होते हैं।

डायनेमिक टैग के प्रकार के संबंध में टाइप एसेर्शन होल्ड करें। टाइप स्विच इसी तरह काम करते हैं।

कुछ संघ प्रकार के मान a, b दिए गए हैं, a == b यदि उनके डायनामिक टैग समान हैं और संग्रहीत मान समान है।

यह जांचना कि क्या संग्रहीत मूल्य कुछ विशेष मूल्य है, एक टैग अभिकथन की आवश्यकता है।

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

प्रतिबिंब को टैग नामों के साथ-साथ हैंडल की भी आवश्यकता होती है।

ई: नेस्टेड यूनियनों के लिए स्पष्टीकरण। दिया गया

type U union {
  A union {
    A1 T1
    A2 T2
  }
  B union {
    B1 T3
    B2 T4
  }
}
var u U

u का मान डायनामिक टैग A है और संग्रहीत मान डायनामिक टैग A1 के साथ अनाम संघ है और इसका संग्रहीत मान T1 का शून्य मान है।

u.B.B2 = returnsSomeT3()

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

v := u.[A].[A2]

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

संपादित 2: प्रकार के दावों पर स्पष्टीकरण।

दिया गया

type U union {
  Exported, unexported int
}
var u U

u.(int) जैसा एक प्रकार का दावा पूरी तरह से उचित है। परिभाषित पैकेज के भीतर, वह हमेशा रहेगा। हालांकि, यदि u परिभाषित पैकेज से बाहर है तो u.(int) डायनामिक टैग के unexported के लीक होने के कार्यान्वयन विवरण से बचने के लिए घबराएगा। इसी प्रकार एक इंटरफ़ेस प्रकार के दावे के लिए।

@ianlancetaylor यहां कुछ उदाहरण दिए गए हैं कि यह सुविधा कैसे मदद करेगी:

1. कुछ पैकेजों के केंद्र में (उदाहरण के लिए go/ast ) एक या अधिक बड़े योग प्रकार हैं। उन प्रकारों को समझे बिना इन पैकेजों को नेविगेट करना कठिन है। अधिक भ्रामक रूप से, कभी-कभी एक योग प्रकार को विधियों के साथ एक इंटरफ़ेस द्वारा दर्शाया जाता है (जैसे go/ast.Node ), दूसरी बार खाली इंटरफ़ेस द्वारा (जैसे go/ast.Object.Decl )।

2. प्रोटोबफ oneof फीचर को गो में संकलित करने के परिणामस्वरूप एक निर्यात न किए गए इंटरफ़ेस प्रकार का परिणाम होता है जिसका एकमात्र उद्देश्य यह सुनिश्चित करना है कि किसी एक फ़ील्ड को असाइनमेंट टाइप-सुरक्षित है। बदले में oneof की प्रत्येक शाखा के लिए एक प्रकार उत्पन्न करने की आवश्यकता होती है। अंतिम उत्पाद के लिए टाइप अक्षर पढ़ना और लिखना कठिन है:

   &sppb.Mutation{
              Operation: &sppb.Mutation_Delete_{
                  Delete: &sppb.Mutation_Delete{
                      Table:  m.table,
                      KeySet: keySetProto,
                  },
              },
   }
   

   कुछ (हालांकि सभी नहीं) oneofs को योग प्रकारों द्वारा व्यक्त किया जा सकता है।

3. कभी-कभी एक "शायद" प्रकार वही होता है जिसकी किसी को आवश्यकता होती है। उदाहरण के लिए, कई Google API संसाधन अद्यतन संचालन संसाधन के फ़ील्ड के सबसेट को बदलने की अनुमति देते हैं। गो में इसे व्यक्त करने का एक प्राकृतिक तरीका प्रत्येक क्षेत्र के लिए "शायद" प्रकार के साथ संसाधन संरचना का एक प्रकार है। उदाहरण के लिए, Google क्लाउड स्टोरेज ObjectAttrs संसाधन ऐसा दिखता है

   type ObjectAttrs struct {
      ContentType string
      ...
   }
   

   आंशिक अपडेट का समर्थन करने के लिए, पैकेज भी परिभाषित करता है

   type ObjectAttrsToUpdate struct {
      ContentType optional.String
      ...
   }
   

   जहां optional.String इस तरह दिखता है ( Godoc ):

   // String is either a string or nil.
   type String interface{}
   

   यह व्याख्या करना और टाइप करना-असुरक्षित दोनों है, लेकिन यह व्यवहार में सुविधाजनक साबित होता है, क्योंकि एक ObjectAttrsToUpdate शाब्दिक उपस्थिति को एन्कोडिंग करते समय बिल्कुल ObjectAttrs शाब्दिक जैसा दिखता है। काश हम लिख पाते

   type ObjectAttrsToUpdate struct {
      ContentType string | nil
      ...
   }
   

4. कई फ़ंक्शन xor शब्दार्थ के साथ (T, error) लौटाते हैं (T अर्थपूर्ण है यदि त्रुटि शून्य है)। वापसी प्रकार को T | error रूप में लिखने से शब्दार्थ स्पष्ट होगा, सुरक्षा बढ़ेगी, और रचना के लिए अधिक अवसर प्रदान होंगे। भले ही हम (संगतता कारणों से) नहीं कर सकते हैं या किसी फ़ंक्शन के रिटर्न वैल्यू को बदलना नहीं चाहते हैं, फिर भी उस मान को ले जाने के लिए योग प्रकार उपयोगी है, जैसे इसे किसी चैनल पर लिखना।

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

chan *Response | error

यह प्रकार कई बार लिखने के लिए काफी छोटा है।

@ianlancetaylor यह शायद एक अच्छी शुरुआत नहीं है, लेकिन यहां वह सब कुछ है जो आप यूनियनों के साथ कर सकते हैं जो आप पहले से ही गो 1 में कर सकते हैं, क्योंकि मुझे लगा कि उन तर्कों को स्वीकार करना और सारांशित करना उचित था:

(नीचे वाक्य रचना/शब्दार्थ के लिए टैग के साथ मेरे नवीनतम प्रस्ताव का उपयोग करना। साथ ही उत्सर्जित कोड को मूल रूप से सी कोड की तरह माना जाता है जिसे मैंने बहुत पहले थ्रेड में पोस्ट किया था।)

योग प्रकार आईओटा, पॉइंटर्स और इंटरफेस के साथ ओवरलैप करते हैं।

योटा

ये दो प्रकार मोटे तौर पर समकक्ष हैं:

type Stoplight union {
  Green, Yellow, Red struct {}
}

func (s Stoplight) String() string {
  switch s.[type] {
  case Green: return "green" //etc
  }
}

तथा

type Stoplight int

const (
  Green Stoplight = iota
  Yellow
  Red
)

func (s Stoplight) String() string {
  switch s {
  case Green: return "green" //etc
  }
}

संकलक संभवतः दोनों के लिए एक ही कोड का उत्सर्जन करेगा।

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

बेशक, कुछ चीजें हैं जो आप आईओटा के साथ कर सकते हैं जो आप संघ प्रकारों के साथ नहीं कर सकते हैं।

संकेत

ये दो प्रकार मोटे तौर पर समकक्ष हैं

type MaybeInt64 union {
  None struct{}
  Int64 int64
}

तथा

type MaybeInt64 *int64

सूचक संस्करण अधिक कॉम्पैक्ट है। डायनामिक टैग को स्टोर करने के लिए यूनियन संस्करण को एक अतिरिक्त बिट (जो बदले में शब्द आकार का होगा) की आवश्यकता होगी, इसलिए मान का आकार संभवतः https://golang.org/pkg/database/sql/ जैसा ही होगा।

संघ संस्करण अधिक स्पष्ट रूप से इरादे का दस्तावेजीकरण करता है।

बेशक, ऐसी चीजें हैं जो आप पॉइंटर्स के साथ कर सकते हैं जो आप यूनियन प्रकारों के साथ नहीं कर सकते हैं।

इंटरफेस

ये दो प्रकार मोटे तौर पर समकक्ष हैं

type AB union {
  A A
  B B
}

तथा

type AB interface {
  secret()
}
func (A) secret() {}
func (B) secret() {}

एम्बेडिंग के साथ संघ संस्करण को बाधित नहीं किया जा सकता है। ए और बी को सामान्य तरीकों की आवश्यकता नहीं है- वे वास्तव में आदिम प्रकार हो सकते हैं या पूरी तरह से अलग विधि सेट हो सकते हैं, जैसे कि json.Token उदाहरण @urandom पोस्ट किया गया।

यह देखना वाकई आसान है कि आप एबी यूनियन बनाम एबी इंटरफेस में क्या डाल सकते हैं: परिभाषा दस्तावेज है (मुझे कुछ पता लगाने के लिए कई बार गो/एस्ट स्रोत को पढ़ना पड़ा है)।

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

बेशक, ऐसी चीजें हैं जो आप इंटरफेस के साथ कर सकते हैं जो आप यूनियन प्रकारों के साथ नहीं कर सकते हैं।

सारांश

हो सकता है कि ओवरलैप बहुत अधिक ओवरलैप हो।

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

आईओटा और पॉइंटर उदाहरणों के क्लंकी संस्करणों का निर्माण "एक अनएक्सपोर्टेड मेथड के साथ इंटरफेस" रणनीति का उपयोग करके किया जा सकता है। उस मामले के लिए, हालांकि, स्ट्रक्चर को map[string]interface{} और (गैर-खाली) इंटरफेस के साथ func प्रकार और विधि मानों के साथ सिम्युलेटेड किया जा सकता है। कोई नहीं करेगा क्योंकि यह कठिन और कम सुरक्षित है।

उन सभी सुविधाओं से भाषा में कुछ तो जुड़ जाता है लेकिन उनकी अनुपस्थिति (दर्दनाक, और विरोध के तहत) के आसपास काम किया जा सकता है।

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

@jimmyfrasche

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

संक्षेप में, आपका संघ प्रकार कुछ इस तरह दिखना चाहिए:

union {
    struct{}
    int
    err
}

प्रकार स्वयं अद्वितीय इंडेंटिफायर प्रदान करेंगे जिनका उपयोग संघ को असाइन करने के लिए किया जा सकता है, जिस तरह से स्ट्रक्चर में एम्बेडेड प्रकारों को पहचानकर्ता के रूप में उपयोग किया जाता है।

हालांकि, काम करने के लिए स्पष्ट असाइनमेंट के लिए, एक सदस्य के रूप में एक अज्ञात प्रकार निर्दिष्ट करके एक संघ प्रकार बनाने में सक्षम नहीं हो सकता है, क्योंकि वाक्यविन्यास ऐसी अभिव्यक्ति की अनुमति देगा। जैसे v.struct{} = struct{}

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

अब, मुझे यकीन नहीं है कि कौन सा वाक्यविन्यास बेहतर होगा।

[union|sum|pick|oneof] {
    type1
    package1.type2
    ....
}

उपरोक्त अधिक जाने जैसा लगता है, लेकिन इस प्रकार के लिए थोड़ा वर्बोज़ है।

दूसरी ओर, type1 | package1.type2 आपके सामान्य गो प्रकार की तरह नहीं लग सकता है, हालांकि इसे '|' का उपयोग करने का लाभ मिलता है। प्रतीक, जिसे मुख्य रूप से OR के रूप में पहचाना जाता है। और यह गूढ़ हुए बिना वाचालता को कम करता है।

@urandom यदि आपके पास "टैग नाम" नहीं हैं, लेकिन अतिरिक्त चेक के साथ इंटरफेस को interface{} में गिरने दें। वे योग प्रकार बनना बंद कर देते हैं क्योंकि आप एक चीज डाल सकते हैं लेकिन इसे कई तरीकों से निकाल सकते हैं। टैग नाम उन्हें योग प्रकार होने देते हैं और अस्पष्टता के बिना इंटरफेस रखते हैं।

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

कि आप एक प्रकार से एक से अधिक टैग दे सकते हैं यह एक विशेषता है। एक पंक्ति में कितनी सफलताएँ या असफलताएँ हुई हैं, यह मापने के लिए एक प्रकार पर विचार करें (1 सफलता N विफलताओं को रद्द करती है और इसके विपरीत)

type Counter union {
  Successes, Failures uint 
}

टैग नामों के बिना आपको चाहिए

type (
  Success uint
  Failures uint
  Counter Successes | Failures
)

और काम की तरह लग रहे हैं c = Successes(1) के बजाय c.Successes = 1 । आपको ज्यादा फायदा नहीं होता है।

एक अन्य उदाहरण एक प्रकार है जो स्थानीय या दूरस्थ विफलता का प्रतिनिधित्व करता है। टैग नामों के साथ यह मॉडल बनाना आसान है:

type Failure union {
  Local, Remote error
}

त्रुटि की भविष्यवाणी को इसके टैग नाम के साथ निर्दिष्ट किया जा सकता है, भले ही वास्तविक त्रुटि कुछ भी हो। टैग नामों के बिना आपको type Local { error } आवश्यकता होगी और रिमोट के लिए भी, भले ही आप सीधे योग में इंटरफेस की अनुमति दें।

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

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

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

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

उस पर कुछ विस्तार करने के लिए, मेरे लिए प्रेरक उदाहरण @rogpeppe io.Reader | io.ReadCloser । टैग के बिना इंटरफेस की अनुमति देना, यह io.Reader जैसा ही है।

आप एक ReadCloser डाल सकते हैं और इसे एक रीडर के रूप में बाहर निकाल सकते हैं। आप ए खो देते हैं | बी का अर्थ है ए या बी योग प्रकार की संपत्ति।

यदि आपको कभी-कभी io.ReadCloser को io.Reader रूप में संभालने के बारे में विशिष्ट होने की आवश्यकता होती है तो आपको रैपर स्ट्रक्चर बनाने की आवश्यकता होती है जैसा कि type Reader struct { io.Reader } आदि और प्रकार Reader | ReadCloser ।

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

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

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

आप टैग जोड़ते हैं और वह सब चला जाता है।

union { R io.Reader | RC io.ReadCloser } आप स्पष्ट रूप से कह सकते हैं कि मैं चाहता हूं कि इस रीडक्लोजर को एक पाठक के रूप में माना जाए यदि यह समझ में आता है। कोई रैपर प्रकार की आवश्यकता नहीं है। यह परिभाषा में निहित है। टैग के प्रकार के बावजूद, यह या तो एक टैग है या दूसरा।

नकारात्मक पक्ष यह है कि, यदि आपको कहीं और से एक io.Reader मिलता है, तो मान लें कि कोई chan रिसीव या func कॉल है, और यह एक io.ReadCloser हो सकता है और आपको इसे उचित टैग पर असाइन करने की आवश्यकता है, आपको io पर assert टाइप करना होगा। करीब पढ़ें और परीक्षण करें। लेकिन इससे प्रोग्राम का आशय बहुत स्पष्ट हो जाता है—ठीक वही जो आपका मतलब कोड में है।

इसके अलावा, क्योंकि टैग अभिकथन प्रकार के अभिकथनों से भिन्न होते हैं, यदि आप वास्तव में परवाह नहीं करते हैं और केवल एक io.Reader चाहते हैं, तो आप टैग की परवाह किए बिना इसे बाहर निकालने के लिए एक प्रकार के दावे का उपयोग कर सकते हैं।

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

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

लिप्यंतरण में काफी कुछ बॉयलरप्लेट होता है इसलिए मैं आम तौर पर दोहराव के बारे में एक नोट के साथ कई तरीकों का पहला उदाहरण ही लिखता हूं।

संघ के प्रस्ताव के साथ जाओ:

type fail union { //zero value: (Local, nil)
  Local, Remote error
}

func (f fail) Error() string {
  //Could panic if local/remote nil, but assuming
  //it will be constructed purposefully
  return f.(error).Error()
}

type U union { //zero value: (A, "")
  A, B, C string
  D, E    int
  F       fail
}

//in a different package

func create() pkg.U {
  return pkg.U{D: 7}
}

func process(u pkg.U) {
  switch u := u.[type] {
  case A:
    handleA(u) //undefined here, just doing something with unboxed value
  case B:
    handleB(u)
  case C:
    handleC(u)
  case D:
    handleD(u)
  case E:
    handleE(u)
  case F:
    switch u := u.[type] {
    case Local:
      log.Fatal(u)
    case Remote:
      log.Printf("remote error %s", u)
      retry()
    } 
  }
}

वर्तमान गो में अनूदित:

(लिप्यंतरण और उपरोक्त के बीच अंतर के बारे में नोट्स शामिल हैं)

const ( //simulates tags, namespaced so other packages can see them without overlap
  Fail_Local = iota
  Fail_Remote
)

//since there are only two tags with a single type this can
//be represented precisely and safely
//the error method on the full version of fail can be
//put more succinctly with type embedding in this case

type fail struct { //zero value (Fail_Local, nil) :)
  remote bool
  error
}

// e, ok := f.[Local]
func (f *fail) TagAssertLocal2() (error, bool) { //same for TagAssertRemote2
  if !f.remote {
    return nil, false
  }
  return f.error, true
}

// e := f.[Local]
func (f *fail) TagAssertLocal() error { //same for TagAssertRemote
  if !f.remote {
    panic("invalid tag assert")
  }
  return f.error
}

// f.Local = err
func (f *fail) SetLocal(err error) { //same for SetRemote
  f.remote = false
  f.error = err
}

// simulate tag switch
func (f *fail) TagSwitch() int {
  if f.remote {
    return Fail_Remote
  }
  return Fail_Local
}

// f.(someType) needs to be written as f.TypeAssert().(someType)
func (f *fail) TypeAssert() interface{} {
  return f.error
}

const (
  U_A = iota
  U_B
  // ...
  U_F
)

type U struct { //zero value (U_A, "", 0, fail{}) :(
  kind int //more than two types, need an int
  s string //these would all occupy the same space
  i int
  f fail
}

//s, ok := u.[A]
func (u *U) TagAssertA2() (string, bool) { //similar for B, etc.
  if u.kind == U_A {
    return u.s, true
  }
  return "", false
}

//s := u.[A]
func (u *U) TagAssertA() string { //similar for B, etc.
  if u.kind != U_A {
    panic("invalid tag assert")
  }
  return u.s
}

// u.A = s
func (u *U) SetA(s string) { //similar for B, etc.
  //if there were any pointers or reference types
  //in the union, they'd have to be nil'd out here,
  //since the space isn't shared
  u.kind = U_A
  u.s = s
}

// special case of u.F.Local = err
func (u *U) SetF_Local(err error) { //same for SetF_Remote
  u.kind = U_F
  u.f.SetLocal(err)
}

func (u *U) TagSwitch() int {
  return u.kind
}

func (u *U) TypeAssert() interface{} {
  switch u.kind {
  case U_A, U_B, U_C:
    return u.s
  case U_D, U_E:
    return u.i
  }
  return u.f
}

//in a different package

func create() pkg.U {
  var u pkg.U
  u.SetD(7)
  return u
}

func process(u pkg.U) {
  switch u.TagSwitch() {
  case U_A:
    handleA(u.TagAssertA())
  case U_B:
    handleB(u.TagAssertB())
  case U_C:
    handleC(u.TagAssertC())
  case U_D:
    handleD(u.TagAssertD())
  case U_E:
    handleE(u.TagAssertE())
  case U_F:
    switch u := u.TagAssertF(); u.TagSwitch() {
    case Fail_Local:
      log.Fatal(u.TagAssertLocal())
    case Fail_Remote:
      log.Printf("remote error %s", u.TagAssertRemote())
    }
  }
}

@jimmyfrasche

चूंकि संघ में ऐसे टैग होते हैं जिनमें समान प्रकार हो सकते हैं, क्या निम्न सिंटैक्स बेहतर अनुकूल नहीं होगा:

func process(u pkg.U) {
  switch v := u {
  case A:
    handleA(v) //undefined here, just doing something with unboxed value
  case B:
    handleB(v)
  case C:
    handleC(v)
  case D:
    handleD(v)
  case E:
    handleE(v)
  case F:
    switch w := v {
    case Local:
      log.Fatal(w)
    case Remote:
      log.Printf("remote error %s", w)
      retry()
    } 
  }
}

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

साथ ही, इस प्रस्ताव के तहत, क्या ऐसा कोड मान्य होगा:

type Foo union {
    // Completely different types, no ambiguity
    A string
    B int
}

func Bar(f Foo) {
    switch v := f {
        ....
    }
}

....

func main() {
    // No need for Bar(Foo{A: "hello world"})
    Bar("hello world")
    Bar(1)
}

@urandom मैंने जब भी संभव हो मौजूदा गो सिंटैक्स के अनुरूपता का उपयोग करके अर्थशास्त्र को प्रतिबिंबित करने के लिए एक वाक्यविन्यास चुना है।

इंटरफ़ेस प्रकारों के साथ आप कर सकते हैं

var i someInterface = someValue //where someValue implements someInterface.
var j someInterface = i //this assignment is different from the last one.

यह ठीक और स्पष्ट है क्योंकि इससे कोई फर्क नहीं पड़ता कि अनुबंध संतुष्ट होने तक someValue किस प्रकार का है।

जब आप यूनियनों पर टैग पेश करते हैं तो यह कभी-कभी अस्पष्ट हो सकता है। मैजिक असाइनमेंट केवल कुछ मामलों में ही मान्य होगा। विशेष आवरण यह आपको कभी-कभी स्पष्ट होने के आसपास ही ले जाता है।

मुझे कभी-कभी एक कदम छोड़ने में सक्षम होने में कोई बिंदु नहीं दिखता है, खासकर जब एक कोड परिवर्तन आसानी से उस विशेष मामले को अमान्य कर सकता है और फिर आपको वापस जाना होगा और फिर भी सभी कोड अपडेट करना होगा। अपने Foo/Bar उदाहरण का उपयोग करने के लिए यदि C int को Foo C int में जोड़ा जाता है तो Bar(1) को बदलना होगा लेकिन Bar("hello world") । यह उन स्थितियों में कुछ कीस्ट्रोक्स को बचाने के लिए सब कुछ जटिल करता है जो सामान्य नहीं हो सकते हैं और अवधारणाओं को समझना कठिन बना देता है क्योंकि कभी-कभी वे इस तरह दिखते हैं और कभी-कभी वे दिखते हैं-यह देखने के लिए कि आप पर क्या लागू होता है, इस आसान फ़्लोचार्ट से परामर्श लें!

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

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

type Foo struct {
  A string
  B int
}

func Bar(f Foo) {...}

func main() {
  Bar("hello world") //same as Bar(Foo{A: "hello world", B: 0})
  Bar(1) //same as Bar(Foo{A: "", B: 1})
}

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

इसके अलावा प्रस्ताव में Bar(Foo{1}) की अनुमति है जब यह स्पष्ट है यदि आप वास्तव में कीस्ट्रोक को सहेजना चाहते हैं। आपके पास यूनियनों के लिए संकेत भी हो सकते हैं, इसलिए &Foo{"hello world"} लिए समग्र शाब्दिक वाक्यविन्यास अभी भी आवश्यक है।

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

switch v := u.[type] {... इंटरफेस के लिए switch v := i.(type) {... को अच्छी तरह से प्रतिबिंबित करता है जबकि अभी भी संघ मूल्यों पर सीधे प्रकार के स्विच और दावे की अनुमति देता है। स्पॉट करना आसान बनाने के लिए शायद यह u.[union] होना चाहिए, लेकिन किसी भी तरह से सिंटैक्स इतना भारी नहीं है और यह स्पष्ट है कि इसका क्या मतलब है।

आप एक ही तर्क दे सकते हैं कि .(type) अनावश्यक है, लेकिन जब आप देखते हैं कि आप हमेशा जानते हैं कि वास्तव में क्या हो रहा है और यह पूरी तरह से इसे सही ठहराता है, मेरी राय में।

इन विकल्पों के पीछे मेरा यही तर्क था।

@jimmyfrasche
आपके स्पष्टीकरण के बाद भी स्विच सिंटैक्स मेरे लिए थोड़ा सा सहज ज्ञान युक्त लगता है। एक इंटरफ़ेस के साथ, switch v := i.(type) {... संभावित प्रकारों के माध्यम से स्विच करता है, जैसा कि स्विच मामलों द्वारा सूचीबद्ध है, और .(type) द्वारा इंगित किया गया है।
हालांकि, एक संघ के साथ, एक स्विच संभावित प्रकारों के माध्यम से स्विच नहीं कर रहा है, लेकिन मान। प्रत्येक मामला एक अलग संभावित मूल्य का प्रतिनिधित्व करता है, जहां मूल्य वास्तव में एक ही प्रकार साझा कर सकते हैं। यह स्ट्रिंग्स और इंट स्विच के समान है, जहां मामले भी मूल्यों को सूचीबद्ध करते हैं, और उनका सिंटैक्स एक साधारण switch v := u {... । उस से, मेरे लिए यह अधिक स्वाभाविक लगता है कि संघ के मूल्यों के माध्यम से स्विच करना switch v := u { ... , क्योंकि मामले समान हैं, लेकिन इनट्स और स्ट्रिंग्स के मामलों की तुलना में अधिक प्रतिबंधात्मक हैं।

@urandom यह वाक्य रचना के बारे में एक बहुत अच्छी बात है। सच्चाई यह है कि यह मेरे पिछले प्रस्ताव से बिना लेबल के एक होल्डओवर है इसलिए यह तब प्रकार था। मैंने बिना सोचे-समझे आंख मूंदकर इसे कॉपी कर लिया। इस पर ध्यान दिलाने के लिए धन्यवाद।

switch u {... काम करेगा लेकिन switch v := u {... साथ समस्या यह है कि यह बहुत अधिक switch v := f(); v {... जैसा दिखता है (जो त्रुटि रिपोर्टिंग को और अधिक कठिन बना देगा - स्पष्ट नहीं कि जिसका इरादा था)।

यदि union कीवर्ड का नाम बदलकर pick कर दिया गया है जैसा कि switch u.[pick] {... या switch v := u.[pick] {... रूप में लिखा जा सकता है जो समरूपता रखता है एक प्रकार के स्विच के साथ लेकिन भ्रम खो देता है और बहुत अच्छा दिखता है।

यहां तक ​​​​कि अगर कार्यान्वयन एक int पर स्विच कर रहा है, तब भी डायनामिक टैग और संग्रहीत मूल्य में चयन का निहित विनाशकारी है, जो मुझे लगता है कि व्याकरणिक नियमों के बावजूद स्पष्ट होना चाहिए

आप जानते हैं, केवल टैग फ़ील्ड को कॉल करना और इसे फ़ील्ड मुखर होना और फ़ील्ड स्विच होना बहुत मायने रखता है।

संपादित करें: हालांकि, अजीब चुनने के साथ प्रतिबिंबित का उपयोग करना होगा

[देरी से प्रतिक्रिया के लिए खेद है - मैं छुट्टी पर था]

@ianlancetaylor ने लिखा:

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

दो मुख्य फायदे हैं जो मैं देख रहा हूं। पहला भाषा लाभ है; दूसरा एक प्रदर्शन लाभ है।

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

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

मेरे लिए एक विशेष दर्द जो योग प्रकार हल कर सकता है वह है गोडोक। उदाहरण के लिए ast.Spec लें: https://golang.org/pkg/go/ast/#Spec

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

यदि भाषा पहले से ही सभी संभावित मूल्यों को जानती है, तो इसे godoc में स्वचालित किया जा सकता है जैसे iotas के साथ एनम प्रकार। वे वास्तव में केवल प्लेनटेक्स्ट होने के विपरीत, प्रकारों से भी जुड़ सकते थे।

संपादित करें: एक और उदाहरण: https://github.com/mvdan/sh/commit/ebbfda50dfe167bee741460a4491ffec1006bdef

@mvdan यह बिना किसी भाषा परिवर्तन के Go1 में कहानी को बेहतर बनाने के लिए एक उत्कृष्ट, व्यावहारिक बिंदु है। क्या आप इसके लिए एक अलग मुद्दा दर्ज कर सकते हैं और इसका संदर्भ दे सकते हैं?

क्षमा करें, क्या आप केवल godoc पृष्ठ के भीतर अन्य नामों के लिंक की बात कर रहे हैं, लेकिन फिर भी उन्हें मैन्युअल रूप से सूचीबद्ध कर रहे हैं?

क्षमा करें, स्पष्ट होना चाहिए था।

मेरा मतलब गॉडोक में मौजूदा पैकेज में परिभाषित इंटरफेस को लागू करने वाले प्रकारों को स्वचालित रूप से संभालने के लिए एक फीचर अनुरोध था।

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

मैं इस (पहले से ही बहुत लंबे) धागे को नहीं लेना चाहता, इसलिए मैंने एक अलग मुद्दा बनाया है - ऊपर देखें।

@Merovius मैं इस मुद्दे में https://github.com/golang/go/issues/19814#issuecomment -298833986 का जवाब दे रहा हूं क्योंकि एएसटी सामान एनम की तुलना में योग प्रकारों पर अधिक लागू होता है। आपको एक अलग मुद्दे में खींचने के लिए खेद है।

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

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

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

कई मामले हैं:

1. आपका कोड प्रत्येक नोड पर चलने की अपेक्षा करता है:
   1.1. आपके पास कोई डिफ़ॉल्ट विवरण नहीं है, आपका कोड चुपचाप गलत है
   1.2. आपके पास एक घबराहट के साथ एक डिफ़ॉल्ट विवरण है, आपका कोड संकलन समय के बजाय रनटाइम पर विफल रहता है (परीक्षण मदद नहीं करते हैं क्योंकि वे केवल उन नोड्स के बारे में जानते हैं जो आपके द्वारा परीक्षण लिखे जाने पर मौजूद थे)
2. आपका कोड केवल नोड प्रकारों के सबसेट का निरीक्षण करता है:
   2.1. इस नए प्रकार का नोड वैसे भी उपसमुच्चय में नहीं होता
   2.1.1. जब तक इस नए नोड में आपकी रुचि का कोई भी नोड शामिल नहीं है, तब तक सब कुछ काम करता है
   2.1.2. अन्यथा, आप उसी स्थिति में हैं जैसे कि आपका कोड प्रत्येक नोड पर चलने की अपेक्षा करता है
   2.2. इस नए प्रकार का नोड उस उपसमुच्चय में होता जिसमें आप रुचि रखते हैं, क्या आप इसके बारे में जानते थे।

इंटरफ़ेस-आधारित एएसटी के साथ केवल 2.1.1 मामला सही ढंग से काम करता है। यह जितना कुछ भी संयोग है। क्रमिक कोड सुधार काम नहीं करता है। एएसटी को अपने संस्करण को टक्कर देनी है और आपके कोड को इसके संस्करण को टक्कर देने की जरूरत है।

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

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

न तो 2.2 के साथ मदद करता है, लेकिन क्या कर सकता है?

एक सरल, एएसटी-आसन्न, मामला है जहां योग प्रकार उपयोगी होंगे: टोकन। मान लें कि आप एक सरल कैलकुलेटर के लिए एक लेक्सर लिख रहे हैं। * जैसे टोकन हैं जिनके साथ कोई मूल्य नहीं जुड़ा है और Var जैसे टोकन हैं जिनमें नाम का प्रतिनिधित्व करने वाली एक स्ट्रिंग है, और टोकन जैसे Val जो एक फ्लोट64 धारण करते हैं .

आप इसे इंटरफेस के साथ लागू कर सकते हैं लेकिन यह थकाऊ होगा। आप शायद ऐसा कुछ करेंगे, यद्यपि:

package token
type Type int
const (
  Times Type = iota
  // ...
  Var
  Val
)
type Value struct {
  Type
  Name string // only valid if Type == Var
  Number float64 // only valid if Type == Val
}

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

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

मुझे लगता है कि अधिक टूलींग आवश्यक है। मुझे यकीन नहीं है कि यह पर्याप्त है।

@jimmyfrasche

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

नहीं, यह बराबर नहीं है। आप उन दोनों परिवर्तनों को क्रमिक मरम्मत मॉडल में कर सकते हैं (इंटरफ़ेस के लिए: 1. सभी कार्यान्वयन में नई विधि जोड़ें, 2. इंटरफ़ेस में विधि जोड़ें। संरचना फ़ील्ड के लिए: 1. फ़ील्ड के सभी उपयोग निकालें, 2. फ़ील्ड निकालें)। सम प्रकार में केस जोड़ना क्रमिक मरम्मत मॉडल में काम नहीं कर

यह इस बारे में नहीं है कि यह एक ब्रेकिंग परिवर्तन है या नहीं, यह इस बारे में है कि क्या यह एक ब्रेकिंग परिवर्तन है जिसे न्यूनतम रुकावट के साथ व्यवस्थित किया जा सकता है।

लेकिन यह सही और वांछित व्यवहार है।

बिल्कुल। सम प्रकार, उनकी परिभाषा और हर कारण से लोग उन्हें चाहते हैं, क्रमिक कोड मरम्मत के विचार के साथ मौलिक रूप से असंगत हैं।

इंटरफ़ेस-आधारित एएसटी के साथ केवल 2.1.1 मामला सही ढंग से काम करता है।

नहीं, यह 1.2 के मामले में भी सही ढंग से काम करता है (अपरिचित व्याकरण के लिए रनटाइम पर विफल होना पूरी तरह से ठीक है। मैं शायद घबराना नहीं चाहता, लेकिन सिर्फ एक त्रुटि लौटाता हूं) और 2.1 के पूरे मामलों में भी। बाकी सॉफ्टवेयर के उन्नयन के साथ एक बुनियादी मुद्दा है; यदि आप किसी पुस्तकालय में कोई नई सुविधा जोड़ते हैं, तो आपके lib के उपयोगकर्ताओं को इसका उपयोग करने के लिए कोड बदलने की आवश्यकता होती है। इसका मतलब यह नहीं है कि आपका सॉफ़्टवेयर तब तक गलत है जब तक वह ऐसा नहीं करता।

एएसटी को अपने संस्करण को टक्कर देनी है और आपके कोड को इसके संस्करण को टक्कर देने की जरूरत है।

मैं यह नहीं देखता कि आप जो कह रहे हैं, उससे यह कैसे निकलता है। मेरे लिए, "यह नया व्याकरण अभी तक सभी उपकरणों के साथ काम नहीं करेगा, लेकिन यह संकलक के लिए उपलब्ध है" ठीक है। जैसे "यदि आप इस उपकरण को इस नए व्याकरण पर चलाते हैं, तो यह रनटाइम पर विफल हो जाएगा" ठीक है। सबसे खराब स्थिति में, यह केवल क्रमिक मरम्मत प्रक्रिया में एक और कदम जोड़ता है: ए) एएसटी पैकेज और पार्सर में नया नोड जोड़ें। b) नए नोड का लाभ उठाने के लिए AST पैकेज का उपयोग करके उपकरणों को ठीक करें। ग) नए नोड का उपयोग करने के लिए कोड अपडेट करें। हाँ, नया नोड केवल प्रयोग करने योग्य हो जाएगा, a) और b) के बाद; लेकिन इस प्रक्रिया के हर चरण में, बिना किसी रुकावट के, सब कुछ अभी भी संकलित और सही ढंग से काम करेगा।

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

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

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

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

आप इसे इंटरफेस के साथ लागू कर सकते हैं लेकिन यह थकाऊ होगा।

सिकोड़ना यह एक ऐसे मामले में एक बार का प्रयास है जो बहुत कम ही सामने आता है। मुझे ठीक लगता है।

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

@Merovius मुझे क्रमिक कोड मरम्मत के बारे में आपके उत्कृष्ट बिंदुओं पर और सोचना होगा। इस बीच में:

थकावट जांच

मैं वर्तमान में केवल योग प्रकारों की संपूर्ण जाँच धारणा के विरुद्ध बहस कर रहा हूँ।

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

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

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

switch {
case n < 0:
case n == 0:
case n > 0:
}

यह संपूर्ण है यदि n अभिन्न है (फ्लोट के लिए इसमें n != n गुम है) लेकिन प्रकारों के बारे में बहुत सारी जानकारी एन्कोड किए बिना इसे केवल डिफ़ॉल्ट रूप से ध्वजांकित करना आसान है। कुछ इस तरह के लिए:

switch {
case p[0](a, b):
case p[1](a, b):
//...
case p[N](a, b):
}

भले ही p[i] a और b के प्रकारों पर एक समकक्ष संबंध बनाते हैं, यह साबित करने में सक्षम नहीं होगा, इसलिए इसे स्विच को डिफ़ॉल्ट के रूप में चिह्नित करना होगा मामला, जिसका अर्थ है इसे एक मेनिफेस्ट के साथ मौन करने का एक तरीका, स्रोत में एक एनोटेशन, श्वेतसूची में egrep -v लिए एक रैपर स्क्रिप्ट, या स्विच पर एक अनावश्यक डिफ़ॉल्ट जिसका झूठा अर्थ है कि p[i] संपूर्ण नहीं हैं।

किसी भी दर पर लागू करने के लिए तुच्छ लिटर होगा यदि "हमेशा सभी परिस्थितियों में कोई डिफ़ॉल्ट नहीं होने की शिकायत करें" मार्ग लिया जाता है। ऐसा करना दिलचस्प होगा और इसे गो-कॉर्पस पर चलाएं और देखें कि व्यवहार में यह कितना शोर और/या उपयोगी है।

टोकन

वैकल्पिक टोकन कार्यान्वयन:

//Type defined as before
type SimpleToken { Type }
type StringToken { Type; Value string }
type NumberToken { Type; Value float64 }
type Interface interface {
  //some method common to all these types, maybe just token() Interface
}

यह एक अवैध टोकन स्थिति को परिभाषित करने की संभावना से छुटकारा दिलाता है, जहां किसी चीज़ में एक स्ट्रिंग और एक संख्या मान दोनों होते हैं, लेकिन एक StringToken को एक प्रकार के साथ बनाने की अनुमति नहीं देता है जो SimpleToken या इसके विपरीत होना चाहिए विपरीत।

इंटरफेस के साथ ऐसा करने के लिए आपको प्रति टोकन एक प्रकार ( type Plus struct{} , type Mul struct{} , आदि) को परिभाषित करने की आवश्यकता है और अधिकांश परिभाषाएं प्रकार के नाम के लिए बिल्कुल समान हैं। एक बार का प्रयास या नहीं यह बहुत काम है (हालांकि इस मामले में कोड पीढ़ी के लिए उपयुक्त है)।

मुझे लगता है कि स्वीकार्य मूल्यों के आधार पर टोकन के प्रकारों को विभाजित करने के लिए आपके पास टोकन इंटरफेस का "पदानुक्रम" हो सकता है: (इस उदाहरण में यह मानते हुए कि एक से अधिक प्रकार के टोकन हैं जिनमें एक संख्या या स्ट्रिंग हो सकती है, आदि)

type SimpleToken int //implements token.Interface
const (
  Plus SimpleToken = iota
  // ...
}
type NumericToken interface {
  Interface
  Value() float64
  nt() NumericToken
}
type IntToken struct { //implements NumericToken, and a FloatToken
type StringToken interface { // for Var and Func and Const, etc.
  Interface
  Value() string
  st() StringToken
}

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

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

तो, ऐसा लगता है कि किसी भी तरह से, हम दोनों के पास संपूर्ण जाँच में या बाहर निकलने का विकल्प होगा :)

यह आपको नहीं बताता कि आप एक ज्ञात मामले से चूक गए, बस आपने अज्ञात मामले को नहीं संभाला।

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

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

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

बावजूद इसके शोर-शराबा नजर आ रहा है। विचार करना:

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

वैकल्पिक टोकन कार्यान्वयन:

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

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

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

मुझे लगता है कि यह अनुचित हो रहा है।

यह सच है।

मैंने एक त्वरित और गंदा संस्करण लिखा और इसे stdlib पर चलाया। किसी भी स्विच स्टेटमेंट की जाँच में 1956 हिट थे, इसे switch { फॉर्म को छोड़ने के लिए प्रतिबंधित करना उस गिनती को घटाकर 1677 कर दिया। मैंने यह देखने के लिए उन स्थानों में से किसी का भी निरीक्षण नहीं किया है कि परिणाम सार्थक है या नहीं।

https://github.com/jimmyfrasche/switchlint

निश्चित रूप से सुधार की काफी गुंजाइश है। यह बहुत परिष्कृत नहीं है। पुल अनुरोधों का स्वागत है।

(बाकी का जवाब मैं बाद में दूंगा)

संपादित करें: गलत मार्कअप प्रारूप

मुझे लगता है कि यह अब तक सब कुछ का एक (काफी पक्षपातपूर्ण) सारांश है (और मेरा दूसरा प्रस्ताव narcissistically मानते हुए)

पेशेवरों

• संक्षिप्त, स्व-दस्तावेजीकरण तरीके से संक्षेप में कई बाधाओं को लिखना आसान है
• आवंटन का बेहतर नियंत्रण
• अनुकूलित करने में आसान (कंपाइलर को ज्ञात सभी संभावनाएं)
• संपूर्ण जाँच (जब वांछित हो, ऑप्ट आउट कर सकते हैं)

दोष

• सम प्रकार के सदस्यों में कोई भी परिवर्तन एक ब्रेकिंग परिवर्तन है, क्रमिक कोड मरम्मत की अनुमति नहीं देता है जब तक कि सभी बाहरी पैकेज संपूर्णता जांच से बाहर न निकल जाएं
• सीखने के लिए भाषा में एक और बात, मौजूदा सुविधाओं के साथ कुछ वैचारिक ओवरलैप
• कचरा संग्रहकर्ता को पता होना चाहिए कि कौन से सदस्य पॉइंटर्स हैं
• फॉर्म की रकम के लिए अजीब 1 + 1 + ⋯ + 1

वैकल्पिक

• 1 + 1 + ⋯ + 1 . फॉर्म के योग के लिए iota "enum"
• अधिक जटिल रकम (संभवतः उत्पन्न) के लिए एक निर्यात न किए गए टैग विधि के साथ इंटरफेस
• या एक आईओटा एनम और अतिरिक्त-भाषाई नियमों के साथ संरचना जिसके बारे में फ़ील्ड सेट किए गए हैं जो एनम वैल्यू पर निर्भर हैं

ध्यान दिए बगैर

• बेहतर टूलींग, हमेशा बेहतर टूलिंग

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

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

अन्य मामलों की तरह सीधा नहीं है, लेकिन फिर भी काफी संभव है।

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

मान लें कि हम इंटरफ़ेस प्रकारों का उपयोग करते समय एक लिंटर के साथ संपूर्णता जाँच के लिए ऑप्ट-इन करना चाहते हैं, चाहे वे किसी भी पैकेज में परिभाषित किए गए हों।

@Merovius आपकी betterSumType() BetterSumType चाल बहुत अच्छी है, लेकिन इसका मतलब है कि परिभाषित पैकेज में स्विच होना चाहिए (या आप कुछ ऐसा उजागर करते हैं

func CallBeforeSwitches(b BetterSumType) (BetterSumType, bool) {
    if b == nil {
        return nil, false
    }
    b = b.betterSumType()
    if b == nil {
        return nil, false
    }
    return b, true
}

और लिंट भी जिसे हर बार कहा जाता है)।

यह जांचने के लिए आवश्यक मानदंड क्या हैं कि किसी प्रोग्राम में सभी स्विच संपूर्ण हैं?

यह खाली इंटरफ़ेस नहीं हो सकता, क्योंकि तब कुछ भी खेल होता है। तो इसे कम से कम एक विधि की आवश्यकता है।

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

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

पूरी तरह से होने के लिए हमें या तो यह जांचना होगा कि इंटरफ़ेस का शून्य मान कभी भी पास नहीं हुआ है या यह लागू करता है कि एक संपूर्ण स्विच case nil भी जांचता है। (उत्तरार्द्ध आसान है लेकिन पूर्व को प्राथमिकता दी जाती है क्योंकि शून्य सहित "टाइप ए या टाइप बी या टाइप सी" योग को "शून्य या टाइप ए या टाइप बी या टाइप सी" योग में बदल देता है)।

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

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

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

उस मामले के लिए, मान लें कि D ने संयोग से लिंटर को पास कर दिया, इसलिए नहीं कि मेंटेनर इसे चलाता है। D में अपग्रेड करने से D′ के समान ही इनवेरिएंट्स को आसानी से नष्ट किया जा सकता है।

यहां तक ​​​​कि अगर लिंटर कह सकता है "अभी यह 100% संपूर्ण है" जो हमारे बिना कुछ भी बदल सकता है।

"Iota enums" के लिए एक थकावट चेकर आसान लगता है।

सभी type t u जहां u अभिन्न है और t का उपयोग const के रूप में या तो व्यक्तिगत रूप से निर्दिष्ट मानों के साथ किया जाता है या iota जैसे कि शून्य इन स्थिरांकों में u का मान शामिल है।

टिप्पणियाँ:

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

कुछ आशुलिपि के लिए, आइए min(t) स्थिरांक को कॉल करें जैसे कि किसी अन्य स्थिरांक के लिए, C , min(t) <= C , और, इसी तरह, आइए max(t) स्थिरांक को कॉल करें कि किसी अन्य स्थिरांक के लिए, C , C <= max(t) ।

यह सुनिश्चित करने के लिए कि t का व्यापक रूप से उपयोग किया जाता है, हमें यह सुनिश्चित करने की आवश्यकता है

• t मान हमेशा नामित स्थिरांक होते हैं (या कुछ मुहावरेदार स्थितियों में 0, जैसे फ़ंक्शन आमंत्रण)
• min(t) <= v <= max(t) बाहर t , v मान की कोई असमानता तुलना नहीं है
• t मान अंकगणितीय परिचालनों में कभी भी उपयोग नहीं किए जाते हैं + , / , आदि। एक संभावित अपवाद तब हो सकता है जब परिणाम min(t) और max(t) बीच क्लैंप किया जाता है। t ।
• स्विच में t या एक डिफ़ॉल्ट केस के सभी स्थिरांक होते हैं।

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

मेरी समझ यह है कि यह, प्रकार के उपनामों के समान, परिवर्तन नहीं करेगा, तो इसे गो 2 के लिए क्यों रखें?

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

टाइप एलियास एक ऐसी समस्या को ठीक कर रहा है जिसके लिए कोई समाधान नहीं था। सम प्रकार टाइप सुरक्षा में एक लाभ प्रदान करते हैं, लेकिन यह एक शो स्टॉपर नहीं है जो उनके पास नहीं है।

@rogpeppe के मूल प्रस्ताव जैसी किसी चीज़ के पक्ष में सिर्फ एक (मामूली) बिंदु। पैकेज में http , इंटरफ़ेस प्रकार Handler और एक फ़ंक्शन प्रकार है जो इसे लागू करता है, HandlerFunc । अभी, किसी फ़ंक्शन को http.Handle पर पास करने के लिए, आपको स्पष्ट रूप से इसे HandlerFunc बदलना होगा। यदि http.Handle बजाय HandlerFunc | Handler प्रकार के तर्क को स्वीकार किया जाता है, तो यह HandlerFunc लिए निर्दिष्ट किसी भी फ़ंक्शन/क्लोजर को सीधे स्वीकार कर सकता है। संघ प्रभावी रूप से एक प्रकार के संकेत के रूप में कार्य करता है जो संकलक को बताता है कि कैसे अज्ञात प्रकार वाले मानों को इंटरफ़ेस प्रकार में परिवर्तित किया जा सकता है। चूंकि HandlerFunc लागू होता है Handler , Handler जैसा व्यवहार करेगा।

@griesemer एनम थ्रेड में आपकी टिप्पणी के जवाब में, https://github.com/golang/go/issues/19814#issuecomment -322752526, मुझे लगता है कि इस धागे में मेरा प्रस्ताव पहले https://github.com/golang/ go/issues/19412#issuecomment -289588569 इस सवाल को संबोधित करता है कि गो में योग प्रकार ("स्विफ्ट स्टाइल एनम") को कैसे काम करना होगा। जितना मैं उन्हें चाहते हैं, मैं अगर वे जाने के लिए एक आवश्यक अतिरिक्त होगा पता नहीं है, लेकिन मुझे लगता है कि अगर वे जोड़ा गया था वे देखो होगा / इस तरह एक बहुत काम करते हैं लगता है।

वह पोस्ट पूर्ण नहीं है और इस पूरे सूत्र में, पहले और बाद में स्पष्टीकरण हैं, लेकिन मुझे उन बिंदुओं को दोहराने या संक्षेप में बताने में कोई आपत्ति नहीं है क्योंकि यह धागा काफी लंबा है।

यदि आपके पास एक प्रकार के टैग के साथ एक इंटरफ़ेस द्वारा सिम्युलेट किया गया योग प्रकार है और इसे एम्बेड करके पूरी तरह से दरकिनार नहीं किया जा सकता है, तो यह सबसे अच्छा बचाव है जिसके साथ मैं आया हूं: https://play.golang.org/p/FqdKfFojp-

@jimmyfrasche मैंने इसे कुछ समय पहले लिखा था।

एक और संभावित तरीका यह है: https://play.golang.org/p/p2tFm984S8

@rogpeppe अगर आप प्रतिबिंब का उपयोग करने जा रहे हैं तो प्रतिबिंब का उपयोग क्यों न करें?

मैंने यहां और अन्य मुद्दों पर टिप्पणियों के आधार पर अपने दूसरे प्रस्ताव का एक संशोधित संस्करण लिखा है।

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

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

संपादित 2: स्पष्ट किया कि जब किसी अन्य पैकेज में पिक परिभाषित किया जाता है तो फ़ील्ड नाम दावे और स्विच के साथ कैसे काम करते हैं।

संपादित 3: प्रतिबंधित एम्बेडिंग और स्पष्ट निहित फ़ील्ड नाम

संपादित करें 4: स्विच में डिफ़ॉल्ट स्पष्ट करें

प्रकार चुनें

एक पिक एक संरचना के समान वाक्य रचनात्मक रूप से एक समग्र प्रकार है:

pick {
  A, B S
  C, D T
  E U "a pick tag"
}

उपरोक्त में, A , B , C , D , और E पिक और S के फ़ील्ड नाम हैं T , और U उन क्षेत्रों के संबंधित प्रकार हैं। फ़ील्ड नाम निर्यात या निर्यात नहीं किए जा सकते हैं।

संकेत के बिना एक पिक रिकर्सिव नहीं हो सकता है।

कानूनी

type p pick {
    //...
    p *p
}

अवैध

type p pick {
    //...
    p p
}

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

फ़ील्ड नाम के बिना एक प्रकार एक फ़ील्ड को उसी प्रकार के नाम से परिभाषित करने के लिए शॉर्टहैंड है। (यह एक त्रुटि है यदि प्रकार का नाम नहीं है, *T अपवाद के साथ जहां नाम T )।

उदाहरण के लिए,

type p pick {
    io.Reader
    io.Writer
    string
}

तीन फ़ील्ड हैं Reader , Writer , और string संबंधित प्रकारों के साथ। ध्यान दें कि फ़ील्ड string का निर्यात नहीं किया जाता है, भले ही वह ब्रह्मांड के दायरे में हो।

पिक प्रकार के मान में एक गतिशील फ़ील्ड और उस फ़ील्ड का मान होता है।

पिक प्रकार का शून्य मान स्रोत क्रम में उसका पहला फ़ील्ड और उस फ़ील्ड का शून्य मान होता है।

एक ही पिक प्रकार के दो मानों को देखते हुए, a और b , पिक वैल्यू को किसी अन्य मान के रूप में असाइन किया जा सकता है

a = b

गैर-पिक मान असाइन करना, यहां तक ​​कि पिक में फ़ील्ड में से किसी एक प्रकार का भी, अवैध है।

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

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

निम्नलिखित मान्य हैं

pick{A string; B int}{A: "string"} //value is (B, "string")
pick{A, B int}{B: 1} //value is (B, 1)
pick{A, B string}{} //value is (A, "")

संकलन समय त्रुटियाँ निम्नलिखित हैं:

pick{A int; B string}{A: 1, B: "string"} //a pick can only have one value at a time
pick{A int; B uint}{1} //pick composite literals must be keyed

निम्नलिखित असाइनमेंट के प्रकार p का मान pick {A int; B string} दिया गया है

p.B = "hi"

p के गतिशील क्षेत्र को B और B के मान को "हाय" पर सेट करता है।

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

type P pick {
    A, B image.Point
}

var p P
fmt.Println(P) //{A: {0 0}}

p.A.X = 1 //A is the dynamic field, update
fmt.Println(P) //{A: {1 0}}

p.B.Y = 2 //B is not the dynamic value, create zero image.Point first
fmt.Println(P) //{B: {0 2}}

किसी पिक में रखे गए मान को केवल फ़ील्ड मुखर या फ़ील्ड स्विच द्वारा ही एक्सेस किया जा सकता है।

x := p.[X] //panics if X is not the dynamic field of p
x, ok := p.[X] //returns the zero value of X and false if X is not the dynamic field of p

switch v := p.[var] {
case A:
case B, C: // v is only defined in this case if fields B and C have identical type names
case D:
default: // always legal even if all fields are exhaustively listed above
}

फ़ील्ड अभिकथन और फ़ील्ड स्विच में फ़ील्ड नाम उस प्रकार की संपत्ति हैं, न कि उस पैकेज में जिसे परिभाषित किया गया था। वे pick को परिभाषित करने वाले पैकेज नाम से योग्य नहीं हैं और न ही हो सकते हैं।

यह मान्य है:

_, ok := externalPackage.ReturnsPick().[Field]

यह अमान्य है:

_, ok := externalPackage.ReturnsPick().[externalPackage.Field]

फ़ील्ड अभिकथन और फ़ील्ड स्विच हमेशा डायनामिक फ़ील्ड के मान की एक प्रति लौटाते हैं।

निर्यात न किए गए फ़ील्ड नामों को केवल उनके परिभाषित पैकेज में ही बताया जा सकता है।

प्रकार के अभिकथन और टाइप स्विच भी पिक्स पर काम करते हैं।

//removed, see note at top
//v, ok := p.(fmt.Stringer) //holds if the type of the dynamic field implements fmt.Stringer
//v, ok := p.(int) //holds if the type of the dynamic field is an int

प्रकार के दावे और प्रकार स्विच हमेशा गतिशील फ़ील्ड के मान की एक प्रति लौटाते हैं।

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

यदि सभी प्रकार के पिक समानता ऑपरेटरों का समर्थन करते हैं तो:

• उस पिक के मूल्यों का उपयोग मानचित्र कुंजियों के रूप में किया जा सकता है
• एक ही पिक के दो मान == यदि उनके पास समान गतिशील क्षेत्र है और इसके मान ==
• अलग-अलग डायनामिक फ़ील्ड वाले दो मान != भले ही मान == ।

पिक प्रकार के मानों पर कोई अन्य ऑपरेटर समर्थित नहीं है।

पिक प्रकार P का मान किसी अन्य पिक प्रकार में परिवर्तित किया जा सकता है Q यदि फ़ील्ड नामों का सेट और P में उनके प्रकार फ़ील्ड नामों का एक सबसेट है और उनके Q में टाइप करें।

यदि P और Q को अलग-अलग पैकेजों में परिभाषित किया गया है और निर्यात न किए गए फ़ील्ड हैं, तो उन फ़ील्ड को नाम और प्रकार की परवाह किए बिना अलग माना जाता है।

उदाहरण:

type P pick {A int; B string}
type Q pick {B string; A int; C float64}

//legal
var p P
q := Q(p)

//illegal
var q Q
p := P(Q) //cannot handle field C

दो पिक प्रकारों के बीच असाइनमेंट को परिवर्तनीयता के रूप में परिभाषित किया जाता है, जब तक कि एक से अधिक प्रकारों को परिभाषित नहीं किया जाता है।

परिभाषित पिक प्रकार पर विधियों को घोषित किया जा सकता है।

मैंने एक अनुभव रिपोर्ट बनाई (और विकी में जोड़ी) https://gist.github.com/jimmyfrasche/ba2b709cdc390585ba8c43c989797325

संपादित करें: और: दिल: @mewmew को जिसने उस सार पर एक उत्तर के रूप में एक बेहतर और अधिक विस्तृत रिपोर्ट छोड़ी

क्या होगा यदि हमारे पास किसी दिए गए प्रकार T लिए कहने का कोई तरीका है, प्रकारों की सूची जिसे T प्रकार में परिवर्तित किया जा सकता है या T प्रकार के चर के लिए असाइन किया जा सकता है? उदाहरण के लिए

type T interface{} restrict { string, error }

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

func FindOrFail(m map[int]string, key int) T {
    if v, ok := m[key]; ok {
        return v
    }
    return errors.New("no such key")
}

func Lookup() {
    v := FindOrFail(m, key)
    if err, ok := v.(error); ok {
        log.Fatal(err)
    }
    s := v.(string) // This type assertion must succeed.
}

इस तरह के दृष्टिकोण से योग प्रकार (या पिक प्रकार) के कौन से प्रमुख तत्व संतुष्ट नहीं होंगे?

s := v.(string) // This type assertion must succeed.

यह कड़ाई से सच नहीं है, क्योंकि v भी nil । इस संभावना को दूर करने के लिए भाषा में काफी बड़ा बदलाव करना होगा, क्योंकि इसका मतलब उन प्रकारों को पेश करना होगा जिनमें शून्य मान नहीं हैं और जो कुछ भी शामिल है। शून्य मान भाषा के कुछ हिस्सों को सरल करता है, लेकिन इस प्रकार की सुविधाओं को डिजाइन करना और भी कठिन बना देता है।

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

@ianlancetaylor

गुण

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

विपक्ष

• वे केवल लाभों के साथ इंटरफेस कर रहे हैं और वास्तव में एक अलग प्रकार का नहीं है (हालांकि अच्छे लाभ!)
• आपके पास अभी भी शून्य है इसलिए यह वास्तव में सैद्धांतिक अर्थों में एक योग प्रकार नहीं है। जो कुछ भी A + B + C आप निर्दिष्ट करते हैं वह वास्तव में एक 1 + A + B + C जिसके बारे में आपके पास कोई विकल्प नहीं है। जैसा कि @stevenblenkinsop ने इस पर काम करते हुए बताया।
• सबसे महत्वपूर्ण बात यह है कि उस निहित सूचक के कारण आपके पास हमेशा एक संकेत होता है। पिक प्रस्ताव के साथ आप p या *p चुनना चुन सकते हैं जिससे आपको मेमोरी ट्रेड ऑफ पर अधिक नियंत्रण मिल सके। आप उन्हें एक अनुकूलन के रूप में भेदभावपूर्ण यूनियनों (सी अर्थ में) के रूप में लागू नहीं कर सके।
• शून्य मान का कोई विकल्प नहीं है, जो वास्तव में एक अच्छी संपत्ति है, खासकर जब से गो में जितना संभव हो उतना उपयोगी शून्य मान होना बहुत महत्वपूर्ण है
• संभवतः आप T पर विधियों को परिभाषित नहीं कर सकते (लेकिन संभवतः आपके पास इंटरफ़ेस के तरीके होंगे जो प्रतिबंधित संशोधित करता है लेकिन प्रतिबंध के प्रकारों को इसे संतुष्ट करने की आवश्यकता होगी? अन्यथा मुझे इसका बिंदु नहीं दिख रहा है न सिर्फ type T restrict {string, error} )
• यदि आप फ़ील्ड/सारांश/आपके पास क्या है, के लिए लेबल खो देते हैं, तो जब यह इंटरफ़ेस प्रकारों के साथ इंटरैक्ट करता है तो यह भ्रमित हो जाता है। आप योग प्रकार की मजबूत "बिल्कुल यह या बिल्कुल वह" संपत्ति खो देते हैं। आप एक io.Reader डाल सकते हैं और एक io.Writer निकाल सकते हैं। यह (अप्रतिबंधित) इंटरफेस के लिए समझ में आता है लेकिन योग प्रकार नहीं।
• यदि आप चाहते हैं कि दो समान प्रकारों का मतलब अलग-अलग चीजें हों, तो आपको स्पष्ट करने के लिए रैपर प्रकारों का उपयोग करने की आवश्यकता होगी; इस तरह के टैग को किसी प्रकार के स्ट्रक्चर फ़ील्ड के प्रकार तक सीमित होने के बजाय बाहरी नामस्थान में होना चाहिए
• यह आपके विशिष्ट शब्दों में बहुत अधिक पढ़ रहा हो सकता है, लेकिन ऐसा लगता है कि यह असाइनमेंट के प्रकार के आधार पर असाइनमेंट के नियमों को बदलता है (मैं इसे यह कहते हुए पढ़ रहा हूं कि आप error को असाइन करने योग्य कुछ असाइन नहीं कर सकते हैं करने के लिए T बिल्कुल एक त्रुटि होनी चाहिए)।

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

मैंने मान लिया कि टाइप अभिकथन नियम लागू होते हैं। तो प्रकार को या तो एक ठोस प्रकार के समान होना चाहिए या इंटरफ़ेस प्रकार के लिए असाइन करने योग्य होना चाहिए। मूल रूप से, यह बिल्कुल एक इंटरफ़ेस की तरह काम करता है लेकिन कोई भी मूल्य ( nil ) सूचीबद्ध प्रकारों में से कम से कम एक के लिए मुखर होना चाहिए।

@jimmyfrasche
आपके अद्यतन प्रस्ताव में, क्या निम्नलिखित असाइनमेंट संभव होगा, यदि प्रकार के सभी तत्व अलग-अलग प्रकार के हैं:

type p pick {
    A int
    B string
}

func Foo(P p) {
}

var P p = 42
var Q p = "foo"

Foo(42)
Foo("foo")

ऐसे असाइनमेंट संभव होने पर योग प्रकारों की उपयोगिता बहुत बड़ी होती है।

पिक प्रस्ताव के साथ आप p या *p चुनना चुन सकते हैं जो आपको मेमोरी ट्रेड ऑफ पर अधिक नियंत्रण प्रदान करता है।

स्केलर मानों को संग्रहीत करने के लिए इंटरफेस आवंटित करने का कारण यह है कि आपको यह तय करने के लिए एक प्रकार का शब्द पढ़ने की ज़रूरत नहीं है कि दूसरा शब्द एक सूचक है या नहीं; चर्चा के लिए #8405 देखें। समान कार्यान्वयन विचार संभवतः एक पिक प्रकार के लिए लागू होंगे, जिसका अर्थ यह हो सकता है कि व्यवहार में p अंत में आवंटित करना और गैर-स्थानीय होना।

@urandom नहीं, आपकी परिभाषाओं को देखते हुए इसे

var p P = P{A: 42} // p := P{A: 42}
var q P = P{B: "foo")
Foo(P{A: 42}) // or Foo({A: 42}) if types can be elided here
Foo(P{B: "foo"})

उन्हें एक ऐसी संरचना के रूप में सोचना सबसे अच्छा है जिसमें एक समय में केवल एक फ़ील्ड सेट हो सकता है।

आपको लगता है कि नहीं है, तो और फिर आप एक जोड़ने C uint करने के लिए p क्या करने के लिए होता p = 42 ?

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

सबसे अच्छे मामले में एक परिवर्तन अस्पष्टता की कमी पर निर्भर सभी कोड को तोड़ देता है और कहता है कि इसे फिर से संकलित करने से पहले आपको इसे p = int(42) या p = uint(42) बदलने की आवश्यकता है। एक पंक्ति परिवर्तन के लिए सौ पंक्तियों को ठीक करने की आवश्यकता नहीं होनी चाहिए। खासकर यदि वे लाइनें आपके कोड के आधार पर लोगों के पैकेज में हैं।

आपको या तो 100% स्पष्ट होना चाहिए या बहुत नाजुक प्रकार का होना चाहिए जिसे कोई छू न सके क्योंकि यह सब कुछ तोड़ सकता है।

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

@ जोशेरियन तो अगर मैं सही ढंग से पढ़ रहा हूं तो दूसरे क्षेत्र में शब्द-आकार के मूल्यों को छिपाने के बजाय iface अब हमेशा (*type, *value) जैसा कि पहले किया गया था ताकि समवर्ती जीसी को दोनों का निरीक्षण करने की आवश्यकता न हो यह देखने के लिए कि क्या दूसरा सूचक है - यह केवल यह मान सकता है कि यह हमेशा है। क्या मैने इसे सही समझा?

दूसरे शब्दों में, यदि पिक प्रकार लागू किया गया था (सी नोटेशन का उपयोग करके) जैसे

struct {
    int which;
    union {
         A a;
         B b;
         C c;
    } summands;
}

GC को which का निरीक्षण करने के लिए लॉक (या कुछ फैंसी लेकिन समकक्ष) लेने की आवश्यकता होगी ताकि यह निर्धारित किया जा सके कि summands को स्कैन करने की आवश्यकता है या नहीं?

दूसरे क्षेत्र में शब्द-आकार के मानों को छिपाने के बजाय iface अब हमेशा (* प्रकार, * मान) है, जैसा कि पहले किया गया था ताकि समवर्ती जीसी को दोनों क्षेत्रों का निरीक्षण करने की आवश्यकता न हो यह देखने के लिए कि दूसरा सूचक है या नहीं —यह सिर्फ यह मान सकता है कि यह हमेशा है।

ये सही है।

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

pick {
  a uintptr
  b string
  c []byte
}

मोटे तौर पर रखा जा सकता है:

[ word 1 (ptr) ] [ word 2 (non-ptr) ] [ word 3 (non-ptr) ]
[    <nil>         ] [                 a           ] [                              ]
[       b.ptr      ] [            b.len          ] [                              ]
[       c.ptr      ] [             c.len         ] [        c.cap             ]

लेकिन अन्य पिक प्रकार ऐसी इष्टतम पैकिंग की अनुमति नहीं दे सकते हैं। (टूटे हुए एएससीआईआई के बारे में खेद है, मैं गिटहब को इसे सही तरीके से प्रस्तुत करने के लिए प्रतीत नहीं कर सकता। आपको बिंदु मिल गया है, मुझे आशा है।)

स्थिर लेआउट करने की यह क्षमता पिक प्रकारों को शामिल करने के पक्ष में एक प्रदर्शन तर्क भी हो सकती है; यहाँ मेरा लक्ष्य केवल आपके लिए प्रासंगिक कार्यान्वयन विवरणों को फ़्लैग करना है।

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

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

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

अच्छे आकार के गुणों को खोना शर्म की बात होगी लेकिन यह वास्तव में सिर्फ एक अनुकूलन है।

यहां तक ​​​​कि अगर यह हमेशा 1 + बराबर संरचना का आकार होता है, भले ही उनमें कोई पॉइंटर्स न हो, फिर भी आवंटन पर नियंत्रण सहित, इस प्रकार के अन्य सभी अच्छे गुण होंगे। अतिरिक्त अनुकूलन समय के साथ जोड़े जा सकते हैं और कम से कम संभव होगा जैसा कि आप बताते हैं।

type p pick {
    A int
    B string
}

क्या A और B का होना आवश्यक है? एक प्रकार के सेट से एक पिक चुनता है, तो क्यों न उनके पहचानकर्ता नामों को पूरी तरह से फेंक दिया जाए:

type p pick {
    int
    string
}
q := p{string: "hello"}

मेरा मानना ​​है कि यह फॉर्म स्ट्रक्चर के लिए पहले से ही मान्य है। एक बाधा हो सकती है कि इसे लेने के लिए आवश्यक है।

@as यदि फ़ील्ड का नाम छोड़ा गया है तो यह उस प्रकार के समान है, इसलिए आपका उदाहरण काम करता है, लेकिन चूंकि उन फ़ील्ड नामों को निर्यात नहीं किया जाता है, इसलिए उन्हें केवल परिभाषित पैकेज के भीतर से ही सेट/एक्सेस किया जा सकता है।

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

@ क्षमा करें, मुझे अभी एहसास हुआ कि मैंने जो पढ़ा है उससे कुछ अलग है।

आपका फॉर्मूलेशन काम करता है लेकिन फिर आपके पास ऐसी चीजें हैं जो स्ट्रक्चर फ़ील्ड की तरह दिखती हैं लेकिन सामान्य निर्यात/निर्यातित चीज़ों के कारण अलग-अलग व्यवहार करती हैं।

क्या स्ट्रिंग p को परिभाषित करने वाले पैकेज के बाहर से सुलभ है क्योंकि यह ब्रह्मांड में है?

व्हाट अबाउट

type t struct {}
type P pick {
  t
  //other stuff
}

?

फ़ील्ड नाम को प्रकार के नाम से अलग करके आप जैसे काम कर सकते हैं

pick {
  unexported Exported
  Exported unexported
}

या और भी

pick { Recoverable, Fatal error }

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

@jimmyfrasche
गो पहले से ही अज्ञात प्रकारों को structs के अंदर एम्बेड करने का समर्थन करता है, इसलिए स्कोप का प्रतिबंध वह है जो पहले से ही भाषा में मौजूद है, और मेरा मानना ​​​​है कि समस्या उपनाम प्रकार द्वारा हल की जा रही है। लेकिन स्वीकार करें कि मैंने हर संभावित उपयोग के मामले के बारे में नहीं सोचा है। ऐसा लगता है कि यह मुहावरा गो में आम है या नहीं:

package p
type T struct{
    Exported t
}
type t struct{}

छोटा _t_ एक पैकेज में मौजूद है जहां इसे बड़े T में एम्बेड किया गया है, और यह केवल ऐसे निर्यात किए गए प्रकारों के माध्यम से एक्सपोजर है।

@जैसा

मुझे यकीन नहीं है कि मैं पूरी तरह से अनुसरण करता हूं, हालांकि:

//with the option to have field names
pick { //T is in the namespace of the pick and the type isn't exposed to other packages
  T t
  //...
}

//without
type T = t //T has to be defined in the outer scope and now t is exposed to other packages
pick {
  T
  //...
}

साथ ही, यदि आपके पास लेबल के लिए केवल प्रकार का नाम था, तो इसमें शामिल करने के लिए []string आपको type Strings = []string करने की आवश्यकता होगी।

जिस तरह से मैं पिक प्रकारों को लागू करना चाहता हूं, वह बहुत अधिक है। में
विशेष रूप से, यह है कि रस्ट और C++ (प्रदर्शन के लिए स्वर्ण मानक) कैसे करते हैं
यह।

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

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

अगस्त 18, 2017 12:01 पीएम, "jimmyfrasche" [email protected] लिखा है:

@josarian https://github.com/josarian तो अगर मैं इसे सही ढंग से पढ़ रहा हूं
कारण iface अब हमेशा (*type, *value) छिपाने के बजाय है
दूसरे क्षेत्र में शब्द-आकार का मान जैसा कि गो ने पहले किया था ताकि
समवर्ती जीसी को यह देखने के लिए दोनों क्षेत्रों का निरीक्षण करने की आवश्यकता नहीं है कि दूसरा
एक सूचक है—यह केवल यह मान सकता है कि यह हमेशा है। क्या मैने इसे सही समझा?

दूसरे शब्दों में, यदि पिक प्रकार लागू किया गया था (सी नोटेशन का उपयोग करके) जैसे

संरचना {
इंट जो;
संघ {
ए ए;
बी बी;
सी सी;
} समन;
}

जीसी को लॉक (या कुछ फैंसी लेकिन समकक्ष) लेने की आवश्यकता होगी
निरीक्षण करें कि क्या यह निर्धारित करना है कि क्या समन को स्कैन करने की आवश्यकता है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/19412#issuecomment-323393003 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB3Ayi31dYwotewcfgmCQL-XVrfxIks5sZbVrgaJpZM4MTmSr
.

@DemiMarie

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

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

एक उदाहरण के रूप में यह सच क्यों है, भावी पीढ़ी के लिए, विचार करें

v := pick{ A int; B bool }{A: 5}
p := &v.[A] //(this would be illegal but pretending it's not for a second)
v.B = true

यदि v को अनुकूलित किया जाता है ताकि फ़ील्ड A और B स्मृति में समान स्थिति ले लें तो p एक int को इंगित नहीं कर रहा है: यह इंगित कर रहा है एक बूल को। स्मृति सुरक्षा का उल्लंघन किया गया था।

@jimmyfrasche

दूसरा कारण यह है कि आप नहीं चाहते कि सामग्री पता योग्य हो, उत्परिवर्तन शब्दार्थ है। यदि मान कुछ परिस्थितियों में परोक्ष रूप से संग्रहीत किया जाता है, तो

v := pick{ A int; ... }{A: 5}
v2 := v

v2.[A] = 6 // (this would be illegal under the proposal, but would be 
           // permitted if `v2.[A]` were addressable)

fmt.Println(v.[A]) // would print 6 if the contents of the pick are stored indirectly

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

संपादित करें: उफ़ (नीचे देखें)

@jimmyfrasche

पिक प्रकार का शून्य मान स्रोत क्रम में उसका पहला फ़ील्ड और उस फ़ील्ड का शून्य मान होता है।

ध्यान दें कि यह काम नहीं करेगा यदि पहले फ़ील्ड को अप्रत्यक्ष रूप से संग्रहीत करने की आवश्यकता है, जब तक कि आप विशेष मामले में शून्य मान नहीं रखते हैं ताकि v.[A] और v.(error) सही काम करें।

@stevenblenkinsop मुझे यकीन नहीं है कि "पहले फ़ील्ड को अप्रत्यक्ष रूप से संग्रहीत करने की आवश्यकता है" से आपका क्या मतलब है। मुझे लगता है कि आपका मतलब है कि पहला फ़ील्ड एक सूचक या एक प्रकार है जिसमें निहित रूप से एक सूचक होता है। यदि ऐसा है, तो नीचे एक उदाहरण है। यदि नहीं, तो क्या आप कृपया स्पष्ट कर सकते हैं?

दिया गया

var p pick { A error; B int }

शून्य मान, p , में गतिशील क्षेत्र A और A का मान शून्य है।

मैं pick में एक पॉइंटर होने/युक्त होने में संग्रहीत मूल्य का जिक्र नहीं कर रहा था, मैं कचरा कलेक्टर द्वारा लगाए गए लेआउट बाधाओं के कारण अप्रत्यक्ष रूप से संग्रहीत एक गैर-पॉइंटर मान का जिक्र कर रहा था, जैसा कि @josarian द्वारा वर्णित है .

आपके उदाहरण में, p.B —एक सूचक नहीं है— p.A साथ अतिव्यापी भंडारण साझा करने में सक्षम नहीं होगा, जिसमें दो पॉइंटर्स शामिल हैं। यह सबसे अधिक संभावना परोक्ष रूप से संग्रहित किया जा करने के लिए होगा (यानी के रूप में प्रतिनिधित्व किया एक *int कि स्वचालित रूप से dereferenced हो जाता है जब आप इसे उपयोग, बल्कि एक के रूप में की तुलना में int )। यदि p.B पहला फ़ील्ड था, तो pick का शून्य मान new(int) , जो स्वीकार्य शून्य मान नहीं है क्योंकि इसे आरंभीकरण की आवश्यकता है। आपको इसे विशेष मामले की आवश्यकता होगी ताकि शून्य *int को new(int) रूप में माना जा सके।

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

संपादित करें: ओह, दौड़ की स्थिति। पोस्ट किया तो आपकी टिप्पणी देखी।

@stevenblenkinsop आह, ठीक है, मैं देखता हूं कि आपका क्या मतलब है। लेकिन यह कोई समस्या नहीं है।

अतिव्यापी भंडारण साझा करना एक अनुकूलन है। यह ऐसा कभी नहीं कर सका: प्रकार के अर्थशास्त्र महत्वपूर्ण बिट हैं।

यदि कंपाइलर स्टोरेज को ऑप्टिमाइज़ कर सकता है और ऐसा करना चुनता है, तो यह एक अच्छा बोनस है।

आपके उदाहरण में, कंपाइलर इसे ठीक उसी तरह स्टोर कर सकता है जैसे यह समतुल्य संरचना (एक टैग जोड़कर यह जानने के लिए कि कौन सा सक्रिय क्षेत्र है)। यह होगा

struct {
  which_field int // 0 = A, 1 = B
  A error
  B int
}

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

महत्वपूर्ण हिस्सा यह सुनिश्चित कर रहा है कि एक निश्चित समय में केवल एक ही क्षेत्र खेल में है।

चुनने पर प्रकार के दावे/स्विच की अनुमति देने के लिए प्रेरणा थी, उदाहरण के लिए, यदि पिक में प्रत्येक प्रकार fmt.Stringer संतुष्ट है तो आप पिक पर एक विधि लिख सकते हैं

func (p P) String() string {
  return p.(fmt.Stringer).String()
}

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

यदि पिछले उदाहरण में पिक P में एक फ़ील्ड था जिसका प्रकार स्वयं fmt.Stringer है तो String विधि घबराएगी यदि वह गतिशील क्षेत्र था और इसका मूल्य nil । आप किसी भी चीज़ के लिए nil इंटरफ़ेस टाइप नहीं कर सकते, यहाँ तक कि स्वयं भी नहीं। https://play.golang.org/p/HMYglwyVbl हालांकि यह हमेशा सच रहा है, यह नियमित रूप से नहीं आता है, लेकिन यह अधिक नियमित रूप से चयन के साथ सामने आ सकता है।

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

यह भी आश्चर्यजनक होगा, यदि आप पिक पर विधियों को लागू कर सकते हैं, तो उन विधियों का उपयोग किसी प्रकार के दावे को पूरा करने के लिए नहीं किया जाता है।

type Num pick { A int; B float32 }

func (n Num) String() string {
      switch v := n.[var] {
      case A:
          return fmt.Sprint(v)
      case B:
          return fmt.Sprint(v)
      }
}
...
n := Num{A: 5}
s1, ok := p.(fmt.Stringer) // ok == false
var i interface{} = p
s2, ok := i.(fmt.Stringer) // ok == true

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

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

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

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

हालांकि, लिखने के लिए कोड जनरेशन का उपयोग करना काफी आसान होगा

func (p Pick) String() string {
  switch v := p.[var] {
  case A:
    return v.String()
  case B:
    return v.String()
  //etc
  }
}

बस आगे बढ़े और प्रकार के दावे छोड़े। शायद उन्हें जोड़ा जाना चाहिए लेकिन वे प्रस्ताव का एक आवश्यक हिस्सा नहीं हैं।

मैं @ianlancetaylor की पिछली टिप्पणी पर वापस आना चाहता हूं, क्योंकि त्रुटि-प्रबंधन के बारे में कुछ और सोचने के बाद मुझे इस पर कुछ नया दृष्टिकोण मिला है (विशेष रूप से, https://github.com/golang/go/issues/21161# मुद्दा टिप्पणी-320294933)।

विशेष रूप से, नए प्रकार का प्रकार हमें क्या देता है जो हमें इंटरफ़ेस प्रकारों से नहीं मिलता है?

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

वर्तमान में हमारे पास फॉर्म के बहुत सारे कार्य हैं

func F(…) (T, error) {
    …
}

उनमें से कुछ, जैसे io.Reader.Read और io.Reader.Write , T के साथ error लौटाते हैं, जबकि अन्य या तो T लौटाते हैं या एक error लेकिन दोनों कभी नहीं। एपीआई की पूर्व शैली के लिए, त्रुटि के मामले में T को अनदेखा करना अक्सर एक बग होता है (उदाहरण के लिए, यदि त्रुटि io.EOF ); बाद की शैली के लिए, एक गैर-शून्य T लौटाना बग है।

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

उदाहरण के लिए, proto.Marshal का उद्देश्य "मान और त्रुटि" शैली होना है यदि त्रुटि RequiredNotSetError , लेकिन अन्यथा "मान या त्रुटि" शैली प्रतीत होती है। चूंकि टाइप सिस्टम दोनों के बीच अंतर नहीं करता है, इसलिए गलती से रिग्रेशन शुरू करना आसान है: या तो एक मूल्य वापस नहीं करना चाहिए, या जब हमें नहीं करना चाहिए तो एक मूल्य वापस करना। और proto.Marshaler कार्यान्वयन ने मामले को और जटिल बना दिया है।

दूसरी ओर, यदि हम इस प्रकार को एक संघ के रूप में व्यक्त कर सकते हैं, तो हम इसके बारे में और अधिक स्पष्ट हो सकते हैं:

type PartialMarshal struct {
    Data []byte // The marshalled value, ignoring unset required fields.
    MissingFields []string
}

func Marshal(pb Message) []byte | PartialMarshal | error

@ianlancetaylor , मैं कागज पर आपके प्रस्ताव के साथ खेल रहा हूं। क्या आप मुझे बता सकते हैं कि क्या नीचे कुछ गलत है?

दिया गया

var r interface{} restrict { uint, int } = 1

r का गतिशील प्रकार int , और

var _ interface{} restrict { uint32, int32 } = 1

अवैध है।

दिया गया

type R interface{} restrict { struct { n int }, etc }
type S struct { n int }

तो var _ R = S{} अवैध होगा।

लेकिन दिया

type R interface{} restrict { int, error }
type A interface {
  error
  foo()
}
type C struct { error }
func (C) foo() {}

var _ R = C{} और var _ R = A(C{}) दोनों कानूनी होंगे।

दोनों

interface{} restrict { io.Reader, io.Writer }

तथा

interface{} restrict { io.Reader, io.Writer, *bytes.Buffer }

समकक्ष हैं।

इसी तरह,

interface{} restrict { error, net.Error }

के बराबर है

interface { Error() string }

दिया गया

type IO interface{} restrict { io.Reader, io.Writer }
type R interface{} restrict {
  interface{} restrict { int, uint },
  IO,
}

तो अंतर्निहित प्रकार का R बराबर है

interface{} restrict { io.Writer, uint, io.Reader, int }

संपादित करें: इटैलिक में छोटा सुधार

@jimmyfrasche मैं यह नहीं कहूंगा कि मैंने जो ऊपर लिखा था वह एक प्रस्ताव था। यह एक विचार की तरह अधिक था। मुझे आपकी टिप्पणियों के बारे में सोचना होगा, लेकिन पहली नज़र में वे प्रशंसनीय लगते हैं।

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

केवल एक चीज जिसे मैं बदलने पर विचार करूंगा वह है टैग को बदलना: foo.X = 0 ऐसा लगता है कि यह foo = Foo{X: 0} ; कुछ और वर्ण, लेकिन अधिक स्पष्ट है कि यह टैग को रीसेट कर रहा है और मान को शून्य कर रहा है। यह एक छोटी सी बात है, और मुझे तब भी बहुत खुशी होगी यदि उनके प्रस्ताव को यथास्थिति में स्वीकार कर लिया जाता है।

@ ns-cweber धन्यवाद, लेकिन मैं शून्य मान व्यवहार का श्रेय नहीं ले सकता। विचार कुछ समय के लिए इधर-उधर तैर रहे थे और @rogpeppe के प्रस्ताव में थे जो इससे पहले आए थे (जैसा कि आप काफी लंबे समय तक बताते हैं)। मेरा औचित्य वही था जो तुमने दिया था।

जहां तक foo.X = 0 बनाम foo = Foo{X: 0} , मेरा प्रस्ताव वास्तव में दोनों को अनुमति देता है। उत्तरार्द्ध उपयोगी है यदि पिक का वह क्षेत्र एक संरचना है तो आप foo.X.Y = 0 बजाय foo = Foo{X: image.Point{X: foo.[X].X, 0}} कर सकते हैं जो वर्बोज़ होने के अलावा रनटाइम पर विफल हो सकता है।

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

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

@jimmyfrasche मुझे शून्य-मूल्य व्यवहार के बारे में सही करने के लिए धन्यवाद। मैं सहमत हूं कि आपका प्रस्ताव दोनों उत्परिवर्तकों के लिए अनुमति देता है, और मुझे लगता है कि आपका लिफ्ट पिच बिंदु एक अच्छा है। आपके प्रस्ताव के लिए आपका स्पष्टीकरण समझ में आता है, हालांकि मैं खुद को foo.XY सेट करते हुए देख सकता था, यह महसूस नहीं कर रहा था कि यह स्वचालित रूप से पिक फ़ील्ड को बदल देगा। यदि आपका प्रस्ताव सफल होता है, तब भी मैं सकारात्मक रूप से प्रसन्न रहूंगा, यहां तक ​​​​कि उस मामूली आरक्षण के साथ भी।

अंत में, पिक एम्बेडिंग के लिए आपका सरल प्रस्ताव ऐसा लगता है जैसे मैं इसे समझूंगा। भले ही हम अपना विचार बदल दें, हम मौजूदा कोड को तोड़े बिना साधारण प्रस्ताव से जटिल प्रस्ताव पर जा सकते हैं, लेकिन इसका उल्टा सच नहीं है।

@ns-cweber

मैं खुद को foo.XY सेट करते हुए देख सकता था, यह महसूस नहीं कर रहा था कि यह स्वचालित रूप से पिक फ़ील्ड को बदल देगा

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

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

जब आप इस तरह की गलती करते हैं तो यह कष्टप्रद हो सकता है लेकिन, ओह, यह "मैंने bar.X = 0 सेट किया है, लेकिन मेरा मतलब bar.Y = 0 सेट करना है" क्योंकि काल्पनिक आप पर निर्भर नहीं है कि foo एक पिक प्रकार है।

इसी तरह i.Foo() , p.Foo() , और v.Foo() सभी एक जैसे दिखते हैं लेकिन अगर i एक nil इंटरफ़ेस है, तो p एक शून्य सूचक है और Foo उस मामले को संभाल नहीं करता है, पहले दो घबरा सकते हैं जबकि यदि v एक मूल्य विधि रिसीवर का उपयोग करता है तो यह नहीं कर सकता (कम से कम आमंत्रण से ही नहीं, वैसे भी) .

-

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

योग प्रकारों में अक्सर एक मूल्यहीन क्षेत्र होता है। उदाहरण के लिए, database/sql पैकेज में, हमारे पास है:

type NullString struct {
    String string
    Valid  bool // Valid is true if String is not NULL
}

यदि हमारे पास योग प्रकार / चयन / संघ थे, तो इसे इस प्रकार व्यक्त किया जा सकता है:

type NullString pick {
  Null   struct{}
  String string
}

इस मामले में एक संरचना पर एक योग प्रकार के स्पष्ट फायदे हैं। मुझे लगता है कि यह एक सामान्य पर्याप्त उपयोग है कि यह किसी भी प्रस्ताव में एक उदाहरण के रूप में शामिल करने लायक होगा।

बाइकशेडिंग (क्षमा करें), मेरा तर्क है कि यह वाक्यात्मक समर्थन और संरचना क्षेत्र एम्बेडिंग सिंटैक्स के साथ असंगति के लायक है:

type NullString union {
  Null
  String string
}

@नील्ड

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

type Null = struct{} //though this puts Null in the same scope as NullString
type NullString pick {
  Null
  String string
}

अपने मुख्य बिंदु पर वापस, हालांकि, हाँ, यह एक उत्कृष्ट उपयोग है। वास्तव में, आप इसका उपयोग एनम बनाने के लिए कर सकते हैं: type Stoplight pick { Stop, Slow, Go struct{} } । यह एक कॉन्स्ट/आईओटा फॉक्स-एनम जैसा होगा। यह एक ही आउटपुट के लिए भी संकलित होगा। इस मामले में प्रमुख लाभ यह है कि राज्य का प्रतिनिधित्व करने वाली संख्या पूरी तरह से एनकैप्सुलेटेड है और आप उन तीन सूचीबद्ध राज्यों के अलावा किसी भी राज्य में नहीं डाल सकते हैं।

दुर्भाग्य से, Stoplight मूल्यों को बनाने और सेट करने के लिए कुछ अजीब वाक्यविन्यास है जो इस मामले में तेज हो गया है:

light := Stoplight{Slow: struct{}{}}
light.Go = struct{}{}

{} या _ को struct{}{} लिए शॉर्टहैंड होने की अनुमति देने से, जैसा कि कहीं और प्रस्तावित है, मदद मिलेगी।

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

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

func Stop() Stoplight {
  return Stoplight{Stop: struct{}{}}
}
func Slow() Stoplight {
  return Stoplight{Slow: struct{}{}}
}
func Go() Stoplight {
  return Stoplight{Go: struct{}{}}
}

और आपके NullString उदाहरण के लिए यह इस तरह दिखेगा:

func Null() NullString {
  return NullString{Null: struct{}{}}
}
func String(s string) NullString {
  return NullString{String: s}
}

यह सुंदर नहीं है, लेकिन यह go generate दूर है और संभवत: बहुत आसानी से इनलाइन है।

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

अधिक सिंटैक्स बाइकशेडिंग:

type NullString union {
  Null
  Value string
}

var _ = NullString{Null}
var _ = NullString{Value: "some value"}
var _ = NullString{Value} // equivalent to NullString{Value: ""}.

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

यह मिश्रित शाब्दिक के अन्य उपयोगों के साथ वाक्यात्मक रूप से असंगत होगा। दूसरी तरफ, यह एक ऐसा उपयोग है जो संघ/पिक/योग प्रकार (कम से कम मेरे लिए) के संदर्भ में समझदार और सहज ज्ञान युक्त लगता है, क्योंकि बिना किसी कुंजी के संघ प्रारंभकर्ता की कोई समझदार व्याख्या नहीं है।

@नील्ड

यह मिश्रित शाब्दिक के अन्य उपयोगों के साथ वाक्यात्मक रूप से असंगत होगा।

यह मेरे लिए बहुत बड़ा नकारात्मक लगता है, हालांकि यह संदर्भ में समझ में आता है।

यह भी ध्यान दें कि

var ns NullString // == NullString{Null: struct{}{}} == NullString{}
ns.String = "" // == NullString{String: ""}

struct{}{} से निपटने के लिए जब मैं map[T]struct{} का उपयोग कर रहा हूं तो मैं फेंक देता हूं

var set struct{}

कहीं और theMap[k] = set , इसी तरह की पसंद के साथ काम करेगा

आगे बाइकशेडिंग: खाली प्रकार (योग प्रकार के संदर्भ में) को पारंपरिक रूप से "इकाई" नाम दिया गया है, न कि "शून्य"।

@bcmills सॉर्टा ।

कार्यात्मक भाषाओं में, जब आप एक योग प्रकार बनाते हैं, तो इसके लेबल वास्तव में ऐसे कार्य होते हैं जो उस प्रकार के मान बनाते हैं, (यद्यपि विशेष कार्य "टाइप कंस्ट्रक्टर" या "टाइकॉन" के रूप में जाने जाते हैं जिन्हें संकलक पैटर्न मिलान की अनुमति देने के बारे में जानता है), इसलिए

data Bool = False | True

डेटा प्रकार Bool और एक ही दायरे में दो फ़ंक्शन बनाता है, True और False , प्रत्येक हस्ताक्षर () -> Bool ।

यहां () है कि आप किस प्रकार उच्चारित इकाई लिखते हैं—वह प्रकार जिसमें केवल एक मान होता है। गो में इस प्रकार को कई अलग-अलग तरीकों से लिखा जा सकता है लेकिन इसे मुहावरेदार तरीके से लिखा जाता है struct{} ।

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

@बीसीमिल्स

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

एक वैकल्पिक परिप्रेक्ष्य के लिए, मैं इसे गो में योग प्रकार के एक बड़े नुकसान के रूप में देखता हूं।

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

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

यदि नया कोड टुपल्स (मान, त्रुटि) को वापस करने के लिए सम प्रकार का उपयोग करता है, तो वह पारिस्थितिकी तंत्र खंडित हो जाएगा।

यदि हम गो 2 में योग प्रकार जोड़ते हैं और उनका समान रूप से उपयोग करते हैं, तो समस्या माइग्रेशन में से एक में कम हो जाती है, विखंडन नहीं: गो 1 (मान, त्रुटि) एपीआई को गो 2 (मान | त्रुटि) में परिवर्तित करना संभव होगा। ) एपीआई और इसके विपरीत, लेकिन वे कार्यक्रम के गो 2 भागों में अलग-अलग प्रकार के हो सकते हैं।

यदि हम गो 2 में योग प्रकार जोड़ते हैं और उनका समान रूप से उपयोग करते हैं

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

इरादा गो 1 और गो 2 के लिए एक ही परियोजना में मूल रूप से सह-अस्तित्व में सक्षम होने के लिए है, इसलिए मुझे नहीं लगता कि चिंता यह है कि कोई व्यक्ति "किसी कारण से" गो 1 कंपाइलर के साथ फंस सकता है और उपयोग करने में असमर्थ हो सकता है। 2 पुस्तकालय जाओ। हालाँकि, यदि आपके पास निर्भरता A जो बदले में B पर निर्भर करती है, और B अपने एपीआई में pick जैसी नई सुविधा का उपयोग करने के लिए अपडेट करती है, तो वह निर्भरता को तोड़ देगा A जब तक कि यह B के नए संस्करण का उपयोग करने के लिए अद्यतन न हो। A केवल विक्रेता B कर सकता है और पुराने संस्करण का उपयोग करना जारी रख सकता है, लेकिन यदि पुराने संस्करण को सुरक्षा बग आदि के लिए बनाए नहीं रखा जा रहा है ... या यदि आपको नए संस्करण का उपयोग करने की आवश्यकता है B सीधे और किसी कारण से आपके प्रोजेक्ट में दो संस्करण नहीं हो सकते हैं, जो समस्या पैदा कर सकते हैं।

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

type ReadResult pick(N int, Err error) {
    N
    PartialResult struct { N; Err }
    Err
}

संकलक केवल ReadResult विभाजित कर सकता है जब इसे विरासत कोड द्वारा एक्सेस किया जाता है, यदि कोई फ़ील्ड किसी विशेष संस्करण में मौजूद नहीं है तो शून्य मानों का उपयोग कर। मुझे यकीन नहीं है कि दूसरी तरफ कैसे जाना है या क्या यह इसके लायक है। एपीआई जैसे template.Must को केवल pick बजाय कई मूल्यों को स्वीकार करना पड़ सकता है और अंतर बनाने के लिए विभाजन पर भरोसा करना पड़ सकता है। या ऐसा कुछ इस्तेमाल किया जा सकता है:

type ReadResult pick(N int, Err error) {
case Err == nil:
    N
default:
    PartialResult struct { N; Err }
case N == 0:
    Err
}

यह चीजों को जटिल करता है, लेकिन मैं देख सकता हूं कि एपीआई को कैसे लिखा

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

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

यह वास्तव में सार है इसलिए यहाँ एक उदाहरण है

संस्करण 1 रकम के बिना

func Take(i interface{}) error {
  switch i.(type) {
  case int: //do something
  case string:
  default: return fmt.Errorf("invalid %T", i)
  }
}
func Give() (interface{}, error) {
   i := f() //something
   if i == nil {
     return nil, errors.New("whoops v:)v")
  }
  return i
}

राशि के साथ संस्करण 2

type Value pick {
  I int
  S string
}
func TakeSum(v Value) {
  // do something
}
// Deprecated: use TakeSum
func Take(i interface{}) error {
  switch x := i.(type) {
  case int: TakeSum(Value{I: x})
  case string: TakeSum(Value{S: x})
  default: return fmt.Errorf("invalid %T", i)
  }
}
type ErrValue pick {
  Value
  Err error
}
func GiveSum() ErrValue { //though honestly (Value, error) is fine
  return f()
}
// Deprecated: use GiveSum
func Give() (interface{}, error) {
  switch v := GiveSum().(var) {
  case Value:
    switch v := v.(var) {
    case I: return v, nil
    case S: return v, nil
    }
  case Err:
    return nil, v
  }
}

संस्करण 3 गिव/टेक को हटा देगा

संस्करण 4 देने/लेने के लिए गिवसम/टेकसम के कार्यान्वयन को स्थानांतरित करेगा, गिवसम/टेकसम को बस कॉल करें/ले लें और गिवसम/टेकसम को हटा दें।

संस्करण 5 गिवसम/टेकसम को हटा देगा

यह सुंदर या तेज़ नहीं है लेकिन यह समान प्रकृति के किसी भी अन्य बड़े पैमाने पर व्यवधान के समान है और इसके लिए भाषा से अतिरिक्त कुछ भी नहीं चाहिए

मुझे लगता है कि (अधिकांश) एक योग प्रकार की उपयोगिता को एक प्रकार के इंटरफ़ेस {} को संकलन समय पर असाइनमेंट को बाधित करने के लिए एक तंत्र के साथ महसूस किया जा सकता है।

मेरे सपनों में ऐसा दिखता है:

type T1 switch {T2,T3} // only nil, T2 and T3 may be assigned to T1
type T2 struct{}
type U switch {} // only nil may be assigned to U
type V switch{interface{} /* ,... */} // V equivalent to interface{}
type Invalid switch {T2,T2} // only uniquely named types
type T3 switch {int,uint} // switches can contain switches but... 

... यह एक स्विच प्रकार पर जोर देने के लिए एक संकलन-समय त्रुटि भी होगी, एक प्रकार स्पष्ट रूप से परिभाषित नहीं है:

var t1 T1
i,ok := t1.(int) // T1 can't be int, only T2 or T3 (but T3 could be int)
switch t := t1.(type) {
    case int: // compile error, T1 is just nil, T2 or T3
}

और गो वेट टी3 जैसे प्रकारों के लिए अस्पष्ट निरंतर असाइनमेंट के बारे में कार्प करेगा लेकिन सभी उद्देश्यों और उद्देश्यों के लिए (रनटाइम पर) var x T3 = 32 होगा var x interface{} = 32 । हो सकता है कि किसी पैकेज में बिल्टिन के लिए कुछ पूर्वनिर्धारित स्विच प्रकार स्विच या टट्टू जैसे कुछ नाम भी ग्रोवी हों।

@j7b , @ianlancetaylor ने https://github.com/golang/go/issues/19412#issuecomment -323256891 में एक समान विचार प्रस्तुत किया

मैंने पोस्ट किया जो मुझे विश्वास है कि इसके बाद के तार्किक परिणाम https://github.com/golang/go/issues/19412#issuecomment -325048452 पर होंगे

ऐसा लगता है कि उनमें से अधिकतर समान रूप से समान रूप से लागू होंगे।

यह वास्तव में बहुत अच्छा होगा अगर ऐसा कुछ काम करेगा। इंटरफेस से इंटरफेस + प्रतिबंधों में संक्रमण करना आसान होगा (विशेषकर इयान के सिंटैक्स के साथ: इंटरफेस के साथ निर्मित मौजूदा छद्म-राशि के अंत में बस restrict से निपटें)। इसे लागू करना आसान होगा क्योंकि रनटाइम के दौरान वे अनिवार्य रूप से इंटरफेस के समान होंगे और अधिकांश काम सिर्फ कंपाइलर को अतिरिक्त त्रुटियों का उत्सर्जन करेंगे जब उनके इनवेरिएंट टूट जाएंगे।

लेकिन मुझे नहीं लगता कि इसे काम करना संभव है।

सब कुछ इतना करीब आता है कि यह एक फिट जैसा दिखता है, लेकिन आप ज़ूम इन करते हैं और यह बिल्कुल सही नहीं

शायद मुझे कुछ याद आ रहा है।

प्रतिबंधित इंटरफ़ेस प्रस्ताव में कुछ भी गलत नहीं है जब तक कि आप मामलों के साथ ठीक हैं, जरूरी नहीं कि वे अलग हों। मुझे नहीं लगता कि यह उतना आश्चर्यजनक है जितना आप करते हैं कि दो इंटरफ़ेस प्रकारों (जैसे io.Reader / io.Writer ) के बीच एक संघ अलग नहीं है। यह पूरी तरह से इस तथ्य के अनुरूप है कि आप यह निर्धारित नहीं कर सकते हैं कि interface{} को असाइन किया गया मान io.Reader या io.Writer रूप में संग्रहीत किया गया था यदि यह दोनों को लागू करता है। तथ्य यह है कि जब तक प्रत्येक मामला एक ठोस प्रकार है, तब तक आप एक असंबद्ध संघ का निर्माण कर सकते हैं, पूरी तरह से पर्याप्त लगता है।

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

@jimmyfrasche type T switch {io.Reader,io.Writer} लिए टी को रीडवाइटर असाइन करना ठीक है लेकिन आप केवल यह कह सकते हैं कि टी एक io.Reader या Io.Writer है, आपको io.Reader या io.Writer पर जोर देने के लिए एक और दावा की आवश्यकता होगी। एक रीडवाइटर, जो इसे एक उपयोगी दावा होने पर इसे स्विचटाइप में जोड़ने के लिए प्रोत्साहित करना चाहिए।

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

और, दूसरी ओर, @ianlancetaylor का सिंटैक्स अनुमति देगा

type IR interface {
  Foo()
  Bar()
} restrict { A, B, C }

जो तब तक संकलित होगा जब तक A , B , और C प्रत्येक में Foo और Bar तरीके हैं (हालांकि आपको चिंता करनी होगी लगभग nil मान)।

संपादित करें: इटैलिक में स्पष्टीकरण

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

//MyGroup can be any of these. It can contain other groups, interfaces, structs, or primitive types
type MyGroup group {
   MyOtherGroup
   MyInterface
   MyStruct
   int
   string
   //..possibly some other types as well
}

//type definitions..
type MyInterface interface{}
type MyStruct struct{}
//etc..

func DoWork(item MyGroup) {
   switch t:=item.(type) {
      //do work here..
   }
}

पारंपरिक खाली इंटरफ़ेस interface{} दृष्टिकोण पर इस दृष्टिकोण के कई लाभ हैं:

• फ़ंक्शन का उपयोग करते समय स्थिर प्रकार की जाँच
• उपयोगकर्ता यह अनुमान लगा सकता है कि फ़ंक्शन कार्यान्वयन को देखे बिना, केवल फ़ंक्शन हस्ताक्षर से किस प्रकार के तर्क की आवश्यकता है

खाली इंटरफ़ेस interface{} तब उपयोगी होता है जब इसमें शामिल प्रकारों की संख्या अज्ञात हो। रनटाइम सत्यापन पर भरोसा करने के अलावा आपके पास वास्तव में कोई विकल्प नहीं है। दूसरी ओर, जब संकलन समय के दौरान प्रकारों की संख्या सीमित और ज्ञात होती है, तो क्यों न हमारी सहायता करने के लिए संकलक प्राप्त किया जाए?

@henryas मुझे लगता है कि एक अधिक उपयोगी तुलना वर्तमान में (खुले) योग प्रकारों को करने का अनुशंसित तरीका होगा: गैर-खाली इंटरफेस (यदि कोई स्पष्ट इंटरफ़ेस डिस्टिल्ड नहीं किया जा सकता है, तो अनएक्सपोर्टेड मार्कर फ़ंक्शंस का उपयोग करके)।
मुझे नहीं लगता कि आपके तर्क उस पर महत्वपूर्ण रूप से लागू होते हैं।

गो प्रोटोबफ्स के संबंध में एक अनुभव रिपोर्ट यहां दी गई है:

• प्रोटो 2 सिंटैक्स "वैकल्पिक" फ़ील्ड के लिए अनुमति देता है, जो ऐसे प्रकार हैं जहां शून्य मान और एक अनसेट मान के बीच अंतर होता है। वर्तमान समाधान एक पॉइंटर का उपयोग करना है (उदाहरण के लिए, *int ), जहां एक शून्य पॉइंटर अनसेट इंगित करता है, जबकि एक सेट पॉइंटर वास्तविक मान को इंगित करता है। इच्छा एक दृष्टिकोण है जो शून्य और अनसेट के बीच अंतर करने की अनुमति देता है, केवल मूल्य तक पहुंचने की आवश्यकता के सामान्य मामले को जटिल किए बिना (जहां शून्य मान ठीक है तो ठीक है)।

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

• प्रोटो भाषा "एक के लिए" की अनुमति देती है, जो कि योग प्रकार के प्रोटो संस्करण हैं। वर्तमान में लिया गया दृष्टिकोण इस प्रकार है ( सकल उदाहरण ):

  • एक छिपी हुई विधि के साथ एक इंटरफ़ेस प्रकार परिभाषित करें (उदाहरण के लिए, type Communique_Union interface { isCommunique_Union() } )
  • संघ में अनुमत प्रत्येक संभावित गो प्रकारों के लिए, एक रैपर संरचना को परिभाषित करें, जिसका एकमात्र उद्देश्य प्रत्येक अनुमत प्रकार को लपेटना है (उदाहरण के लिए, type Communique_Number struct { Number int32 } ) जहां प्रत्येक प्रकार में isCommunique_Union विधि है।
  • यह भी गैर-निष्पादक है क्योंकि रैपर आवंटन का कारण बनते हैं। एक योग प्रकार मदद करेगा क्योंकि हम जानते हैं कि सबसे बड़ा मूल्य (एक टुकड़ा) 24B से अधिक नहीं होगा।

@henryas मुझे लगता है कि एक अधिक उपयोगी तुलना वर्तमान में (खुले) योग प्रकारों को करने का अनुशंसित तरीका होगा: गैर-खाली इंटरफेस (यदि कोई स्पष्ट इंटरफ़ेस डिस्टिल्ड नहीं किया जा सकता है, तो अनएक्सपोर्टेड मार्कर फ़ंक्शंस का उपयोग करके)।
मुझे नहीं लगता कि आपके तर्क उस पर महत्वपूर्ण रूप से लागू होते हैं।

आपका मतलब किसी ऑब्जेक्ट में एक डमी अनएक्सपोर्टेड मेथड जोड़ना है ताकि ऑब्जेक्ट को एक इंटरफ़ेस के रूप में पारित किया जा सके, जैसा कि निम्नानुसार है?

type MyInterface interface {
   belongToMyInterface() //dummy method definition
}

type MyObject struct{}
func (MyObject) belongToMyInterface(){} //dummy method

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

_dummy method_ दृष्टिकोण के साथ ये समस्याएं हैं:

• ऑब्जेक्ट और इंटरफ़ेस को अव्यवस्थित करने वाली अनावश्यक विधियाँ और विधि परिभाषाएँ।
• हर बार एक नया _group_ जोड़ा जाता है, आपको ऑब्जेक्ट के कार्यान्वयन को संशोधित करने की आवश्यकता होती है (उदाहरण के लिए डमी विधियों को जोड़ना)। यह गलत है (अगला बिंदु देखें)।
• बीजीय डेटा प्रकार (या व्यवहार के बजाय _domain_ पर आधारित समूहीकरण) डोमेन-विशिष्ट है । डोमेन के आधार पर, आपको ऑब्जेक्ट संबंध को अलग तरह से देखने की आवश्यकता हो सकती है। एक लेखाकार समूह एक गोदाम प्रबंधक से अलग तरह से दस्तावेज करता है। यह समूहन वस्तु के उपभोक्ता से संबंधित है, न कि स्वयं वस्तु से। वस्तु को उपभोक्ता की समस्या के बारे में कुछ भी जानने की आवश्यकता नहीं है, और इसकी आवश्यकता नहीं होनी चाहिए। क्या किसी चालान को लेखांकन के बारे में कुछ जानने की आवश्यकता है? यदि ऐसा नहीं होता है, तो इनवॉइस को इसके कार्यान्वयन को बदलने की आवश्यकता क्यों है _(उदाहरण के लिए नई डमी विधियों को जोड़ना)_ हर बार लेखांकन नियम में परिवर्तन होने पर _(जैसे। नए दस्तावेज़ समूहन को लागू करना)_? _dummy method_ दृष्टिकोण का उपयोग करके, आप अपनी वस्तु को उपभोक्ता के डोमेन से जोड़ते हैं और उपभोक्ता के डोमेन के बारे में महत्वपूर्ण धारणा बनाते हैं। आपको ऐसा करने की आवश्यकता नहीं होनी चाहिए। यह खाली इंटरफ़ेस interface{} दृष्टिकोण से भी बदतर है। बेहतर दृष्टिकोण उपलब्ध हैं।

@ हेनरीस

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

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

@as मेरा कहना यह है कि हर बार एक नया _रिलेशनशिप व्यू_ बनाया जाता है, इस दृश्य के लिए कुछ आवास बनाने के लिए प्रासंगिक ठोस वस्तुओं को अद्यतन किया जाना चाहिए। यह गलत लगता है, क्योंकि ऐसा करने के लिए, वस्तुओं को अक्सर उपभोक्ता के डोमेन के बारे में एक निश्चित धारणा बनानी चाहिए। यदि वस्तुएं और उपभोक्ता निकट से संबंधित हैं या एक ही डोमेन के भीतर रहते हैं, जैसे कि गो पार्सर मामले में, यह ज्यादा मायने नहीं रखता। हालाँकि, यदि ऑब्जेक्ट कई अन्य डोमेन द्वारा उपभोग की जाने वाली बुनियादी कार्यक्षमता प्रदान करते हैं, तो यह एक समस्या बन जाती है। वस्तुओं को अब काम करने के लिए _dummy method_ दृष्टिकोण के लिए अन्य सभी डोमेन के बारे में थोड़ा सा जानने की जरूरत है।

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

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

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

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

[1] विशेष रूप से, यह आसान नहीं है, लेकिन फिर भी संभव है , जैसे आप कर सकते हैं

type Node interface {
    node()
}

type Foo struct {
    bar.Baz
}

func (foo) node() {}

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

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

मैं आपके दूसरे नकारात्मक बिंदु से असहमत हूं।

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

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

इस प्रकार का श्वेत-श्याम तर्क वास्तव में मदद नहीं करता है । मैं सहमत हूं, कि योग प्रकार कुछ मामलों में दर्द को कम करेगा। टाइप-सिस्टम को और अधिक शक्तिशाली बनाने वाला प्रत्येक परिवर्तन कुछ मामलों में दर्द को कम करेगा - लेकिन यह कुछ मामलों में दर्द का कारण भी

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

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

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

एक और सवाल:

तथ्य यह है कि मानक पुस्तकालय में बहुत सारे स्थान हैं जो योग प्रकारों से अत्यधिक लाभान्वित होंगे

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

database/sql/driver.Value योग प्रकार होने से लाभ हो सकता है (जैसा कि #23077 में बताया गया है)।
https://godoc.corp.google.com/pkg/database/sql/driver#Value

हालांकि, database/sql.Rows.Scan में अधिक सार्वजनिक इंटरफ़ेस कार्यक्षमता में कमी के बिना नहीं होगा। स्कैन उन मानों में पढ़ सकता है जिनका अंतर्निहित प्रकार है, उदाहरण के लिए, int ; अपने गंतव्य पैरामीटर को एक योग प्रकार में बदलने के लिए इसके इनपुट को सीमित प्रकार के सेट तक सीमित करने की आवश्यकता होगी।
https://godoc.corp.google.com/pkg/database/sql#Rows.Scan

@मेरोवियस

मैं खुले योग प्रकारों के विरोध में नहीं होता (अर्थात प्रत्येक योग प्रकार में एक निहित या स्पष्ट "समथिंग एल्स" -केस होता है), क्योंकि यह उनमें से अधिकांश तकनीकी डाउनसाइड्स को कम कर देगा (ज्यादातर यह कि उन्हें विकसित करना कठिन होता है)

कम से कम दो अन्य विकल्प हैं जो बंद रकम की "कठिन विकसित" समस्या को कम करते हैं।

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

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

database/sql/driver.Value योग प्रकार होने से लाभ हो सकता है

सहमत, उस के बारे में नहीं पता था। धन्यवाद :)

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

दिलचस्प समाधान।

@Merovius इंटरफेस अनिवार्य रूप से अनंत-योग प्रकार का एक परिवार है। सभी योग प्रकार, अनंत या अन्यथा, एक default: मामला है। परिमित योग प्रकारों के बिना, हालांकि, default: अर्थ है या तो एक वैध मामला जिसे आप इसके बारे में नहीं जानते थे या एक अमान्य मामला जो प्रोग्राम में कहीं एक बग है - सीमित रकम के साथ यह केवल पूर्व है और बाद वाला कभी नहीं।

json.Token और sql.Null* प्रकार अन्य विहित उदाहरण हैं। go/types उसी तरह लाभान्वित होंगे जैसे go/ast करता है। मैं अनुमान लगा रहा हूं कि ऐसे कई उदाहरण हैं जो निर्यात किए गए एपीआई में नहीं हैं जहां आंतरिक स्थिति के डोमेन को सीमित करके कुछ जटिल नलसाजी को डीबग करना और परीक्षण करना आसान होगा। मैं उन्हें आंतरिक स्थिति और अनुप्रयोग बाधाओं के लिए सबसे उपयोगी पाता हूं जो अक्सर सामान्य पुस्तकालयों के लिए सार्वजनिक एपीआई में नहीं आते हैं, हालांकि उनके पास कभी-कभी उपयोग भी होते हैं।

व्यक्तिगत रूप से मुझे लगता है कि योग के प्रकार गो को पर्याप्त अतिरिक्त शक्ति देते हैं लेकिन बहुत अधिक नहीं। गो टाइप सिस्टम पहले से ही बहुत अच्छा और लचीला है, हालांकि इसकी कमियां हैं। टाइप सिस्टम में Go2 जोड़ने से उतनी शक्ति नहीं मिलने वाली है जितनी पहले से है—जो आवश्यक है उसका 80-90% पहले से ही मौजूद है। मेरा मतलब है, यहां तक ​​कि जेनरिक भी आपको मौलिक रूप से कुछ नया करने की अनुमति नहीं देंगे: यह आपको उन चीजों को करने देगा जो आप पहले से ही अधिक सुरक्षित, अधिक आसानी से, अधिक कुशलता से करते हैं, और इस तरह से बेहतर टूलींग को सक्षम बनाता है। योग प्रकार समान हैं, आईएमओ (हालांकि स्पष्ट रूप से अगर यह एक या अन्य जेनेरिक प्राथमिकता लेते हैं (और वे अच्छी तरह से जोड़ते हैं))।

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

json.Token और sql.Null* प्रकार अन्य विहित उदाहरण हैं।

टोकन - ज़रूर। एएसटी-समस्या का एक और उदाहरण (मूल रूप से किसी भी पार्सर को योग प्रकारों से लाभ होता है)।

मुझे एसक्यूएल के लिए लाभ नहीं दिख रहा है। नल *, हालांकि। जेनरिक के बिना (या कुछ "जादुई" जेनेरिक वैकल्पिक बिलिन जोड़ने से), आपके पास अभी भी प्रकार होने जा रहे हैं और type NullBool enum { Invalid struct{}; Value Int } और type NullBool struct { Valid bool; Value Int } बीच कोई महत्वपूर्ण अंतर नहीं लगता है। हां, मुझे पता है कि एक अंतर है, लेकिन यह बहुत छोटा है।

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

ऊपर देखो। जिन्हें मैं खुली रकम कहता हूं, मैं उनका कम विरोध करता हूं।

जिन्हें मैं खुली रकम कहता हूं, मैं उनका कम विरोध करता हूं।

मेरा विशिष्ट प्रस्ताव है https://github.com/golang/go/issues/19412#issuecomment -323208336 और मेरा मानना ​​है कि यह आपके खुलेपन की परिभाषा को पूरा कर सकता है, हालांकि यह अभी भी थोड़ा मोटा है और मुझे यकीन है कि अभी और भी बहुत कुछ है हटाओ और पॉलिश करो। विशेष रूप से मैंने देखा कि यह स्पष्ट नहीं था कि एक डिफ़ॉल्ट मामला स्वीकार्य था, भले ही सभी मामले सूचीबद्ध हों इसलिए मैंने इसे अभी अपडेट किया है।

सहमत हैं कि वैकल्पिक प्रकार योग प्रकार के हत्यारे ऐप नहीं हैं। हालांकि वे काफी अच्छे हैं और जैसा कि आप जेनेरिक परिभाषित करने के साथ इंगित करते हैं a

type Nullable(T) pick { // or whatever syntax (on all counts)
  Null struct{}
  Value T
}

एक बार और सभी मामलों को कवर करना बहुत अच्छा होगा। लेकिन, जैसा कि आप भी बताते हैं, हम एक सामान्य उत्पाद (संरचना) के साथ भी ऐसा ही कर सकते हैं। Valid = false, Value != 0 की अमान्य स्थिति है। उस परिदृश्य में इसे रूट करना आसान होगा यदि यह समस्या पैदा कर रहा था क्योंकि 2 T छोटा है, भले ही यह 1 + T जितना छोटा न हो।

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

टोकन - ज़रूर। एएसटी-समस्या का एक और उदाहरण (मूल रूप से किसी भी पार्सर को योग प्रकारों से लाभ होता है)।

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

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

गो के साथ विशेष रूप से एक जगह जहां मैं योग प्रकारों का उपयोग करता हूं, चैनलों के एक समूह पर चयन करने वाला एक गोरआउटिन है जहां मुझे एक गोरौटाइन को 3 चान और दूसरे को 2 देने की आवश्यकता होती है। यह मुझे ट्रैक करने में मदद करेगा कि chan pick { a A; b B; c C } से अधिक chan A , chan B , chan C का उपयोग करने में सक्षम होने के लिए क्या हो रहा है, हालांकि chan stuct { kind MsgKind; a A; b B; c C } कर सकते हैं अतिरिक्त स्थान और कम सत्यापन की कीमत पर चुटकी में काम करें।

एक नए प्रकार के बजाय मौजूदा इंटरफ़ेस प्रकार स्विच सुविधा के अतिरिक्त संकलन-समय प्रकार सूची की जांच के बारे में क्या?

func main() {
    if FlipCoin() == false {
        printCertainTypes(FlipCoin(), int(5))
    } else {
        printCertainTypes(FlipCoin(), string("5"))
    }
}

// this function compiles with main
func printCertainTypes(flip bool, in interface{}) {
    if flip == false {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        default:
            fmt.Println(v)
        }
    } else {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        case string:
            fmt.Printf(“string %v\n”, v)
        }
    }
}

// this function compiles with main
func printCertainTypes(flip bool, in interface{}) {
    switch v := in.(type) {
    case int:
        fmt.Printf(“integer %v\n”, v)   
    case bool:
        fmt.Printf(“bool %v\n”, v)
    }
    fmt.Println(flip)
    switch v := in.(type) {
    case string:
        fmt.Printf(“string %v\n”, v)
    case bool:
        fmt.Printf(“bool 2 %v\n”, v)
    }
}

// this function emits a type switch not complete error when compiled with main
func printCertainTypes(flip bool, in interface{}) {
    if flip == false {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        case bool:
            fmt.Printf(“bool %v\n”, v)
        }
    } else {
        switch v := in.(type) {
        case string:
            fmt.Printf(“string %v\n”, v)
        case bool:
            fmt.Printf(“bool %v\n”, v)
        }
    }
}

// this function emits a type switch not complete error when compiled with main
func printCertainTypes(flip bool, in interface{}) {
    fmt.Println(flip)
    switch v := in.(type) {
    case int:
        fmt.Printf(“integer %v\n”, v)
    case bool:
        fmt.Printf(“bool %v\n”, v)
    }
}

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

मानक साधन एक इंटरफ़ेस है जिसमें एक टैग के रूप में एक गैर-निर्यातित, कुछ भी न करने की विधि है।

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

type Sum interface { sum() }
type sum struct{}
func (sum) sum() {}

और बस उस 0-चौड़ाई वाले टैग को हमारे स्ट्रक्चर्स में एम्बेड करें।

हम एक रैपर पेश करके अपने योग में बाहरी प्रकार जोड़ सकते हैं

type External struct {
  sum
  *pkg.SomeType
}

हालांकि यह थोड़ा अटपटा है।

यदि योग में सभी सदस्य सामान्य व्यवहार साझा करते हैं, तो हम उन विधियों को इंटरफ़ेस परिभाषा में शामिल कर सकते हैं।

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

import "p"
var member struct {
  p.Sum
}

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

रनटाइम पर कुछ प्रकार की सुरक्षा को पुनर्प्राप्त करने के कई तरीके हैं। मैंने एक func के साथ मिलकर योग इंटरफ़ेस की परिभाषा में valid() error विधि शामिल की है

func valid(s Sum) error {
  switch s.(type) {
  case nil:
    return errors.New("pkg: Sum must be non-nil")
  case A, B, C, ...: // listing each valid member
    return s.valid()
  }
  return fmt.Errorf("pkg: %T is not a valid member of Sum")
}

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

type alwaysValid struct{}
func (alwaysValid) valid() error { return nil }

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

//A Node is one of (list of types).
type Node interface { node() }

लिखो

//A Node is only valid if it is defined in this package.
type Node interface { 
  //Node is a dummy method that signifies that a type is a Node.
  Node()
}

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

यह पैटर्न तब उपयोगी होता है जब योग के अधिकांश प्रकारों को एक ही पैकेज में परिभाषित किया जाता है। जब कोई नहीं होता है, तो सामान्य सहारा interface{} वापस गिरना है, जैसे json.Token या driver.Value । हम पिछले पैटर्न का उपयोग प्रत्येक के लिए रैपर प्रकारों के साथ कर सकते थे लेकिन अंत में यह interface{} जितना कहता है,

//Sum is one of int64, float64, or bool.
type Sum interface{}
func New(v interface{}) (Sum, error) {
  switch v.(type) {
  case nil:
    return errors.New("pkg: Sum must be non-nil")
  case int64, float64, bool:
     return v
  }
  return fmt.Printf("pkg: %T is not a valid member of Sum")
}

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

*T मान लें कि आप nil सूचक के रूप में कोई मान नहीं दर्शाते हैं और एक (संभवतः) शून्य मान एक गैर-शून्य सूचक को डीरेफ़ेंस करने के परिणाम के रूप में दर्शाते हैं।

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

वैकल्पिक के लिए इसे sql पैकेज से तकनीक का उपयोग करके टाला जा सकता है

type OptionalT struct {
  Valid bool
  Value T
}

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

योग प्रकार का सबसे सरल रूप तब होता है जब आप पहचान की परवाह करते हैं, न कि मूल्य: गणना।

गो में इसे संभालने का पारंपरिक तरीका है const/iota:

type Enum int
const (
  A Enum = iota
  B
  C
)

OptionalT प्रकार की तरह इसमें कोई अनावश्यक संकेत नहीं है। इंटरफ़ेस योग की तरह, यह डोमेन को सीमित नहीं करता है: केवल तीन मान्य मान और कई अमान्य मान हैं, इसलिए हमें रनटाइम पर सत्यापित करने की आवश्यकता है। यदि ठीक दो मान हैं तो हम बूल का उपयोग कर सकते हैं।

इस प्रकार की मौलिक संख्या-नेस का मुद्दा भी है। A+B == C । हम टाइप न किए गए अभिन्न स्थिरांक को इस प्रकार में थोड़ा बहुत आसानी से बदल सकते हैं। ऐसे बहुत से स्थान हैं जहां यह वांछनीय है, लेकिन हमें यह मिलता है चाहे कुछ भी हो। थोड़े से अतिरिक्त काम के साथ, हम इसे केवल पहचान तक सीमित कर सकते हैं:

type Enum struct { v int }
var (
  A = Enum{0}
  B = Enum{1}
  C = Enum{2}
)

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

func A() Enum { return Enum{0} }
func B() Enum { return Enum{1} }
func C() Enum { return Enum{2} }

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

हालांकि, यह कुछ मायनों में इंटरफ़ेस योग से बेहतर है क्योंकि हमने इस प्रकार को लगभग पूरी तरह से बंद कर दिया है। बाहरी कोड केवल A() , B() , या C() । वे var उदाहरण की तरह लेबल को स्वैप नहीं कर सकते हैं और वे A() + B() नहीं कर सकते हैं और हम Enum पर जो भी तरीके चाहते हैं उन्हें परिभाषित करने के लिए स्वतंत्र हैं। यह अभी भी एक ही पैकेज में कोड के लिए गलत तरीके से एक मूल्य बनाने या संशोधित करने के लिए संभव होगा, लेकिन अगर हम यह सुनिश्चित करने के लिए ध्यान रखते हैं कि ऐसा नहीं होता है, तो यह पहला योग प्रकार है जिसे सत्यापन कोड की आवश्यकता नहीं है: यदि यह मौजूद है, तो यह मान्य है .

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

type Value struct {
  Which int // could have consts for A, B, C, D, E, F
  String string
  Int int
}

यह ऊपर दिए गए OptionalT प्रकार की तरह है, लेकिन एक बूल के बजाय इसकी एक गणना है और ऐसे कई फ़ील्ड हैं जिन्हें Which के मूल्य के आधार पर सेट (या नहीं) किया जा सकता है। सत्यापन में सावधानी बरतनी चाहिए कि ये उचित रूप से सेट (या नहीं) हैं।

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

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

इस तरह की रचनाएँ मान लें कि एक प्रकार योग में है, लेकिन यह हमें यह नहीं कहने देता कि उस योग में क्या नहीं है। अनिवार्य शून्य मामले के अतिरिक्त, एक ही एम्बेडिंग चाल का उपयोग बाहरी पैकेजों द्वारा किया जा सकता है जैसे
[…]
पैकेज के भीतर हमें उन मूल्यों को मान्य करने के लिए ध्यान रखना होगा जो संकलित हैं लेकिन अवैध हैं।

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

कहा जा रहा है, आप इंटरफ़ेस को type Sum interface { sum() Sum } बदलकर उस समस्या को रोक सकते हैं और प्रत्येक मान स्वयं ही वापस आ सकता है। इस तरह, आप केवल sum() की वापसी का उपयोग कर सकते हैं, जो एम्बेडिंग के तहत भी अच्छी तरह से व्यवहार किया जाएगा।

इस पैटर्न के बारे में अधिक आम शिकायतों में से एक यह है कि यह गोडोक में सदस्यता को स्पष्ट रूप से स्पष्ट नहीं करता है।

यह आपकी मदद कर सकता है ।

इसका प्रमुख पहलू यह है कि यह अमान्य स्थिति को एन्कोडिंग की अनुमति देता है: मान्य गलत हो सकता है और मान गैर-शून्य हो सकता है।

यह मेरे लिए अमान्य स्थिति नहीं है। शून्य मान जादुई नहीं हैं। sql.NullInt64{false,0} और NullInt64{false,42} बीच कोई अंतर नहीं है, IMO। दोनों SQL NULL के मान्य और समकक्ष प्रतिनिधित्व हैं। यदि सभी कोड Value का उपयोग करने से पहले Valid की जांच करते हैं, तो अंतर प्रोग्राम के लिए देखने योग्य नहीं है।

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

इस प्रकार की मौलिक संख्या-नेस का मुद्दा भी है। A+B == C. हम टाइप न किए गए अभिन्न स्थिरांक को इस प्रकार में थोड़ा बहुत आसानी से बदल सकते हैं।

क्या यह एक सैद्धांतिक चिंता है या यह व्यवहार में सामने आई है?

प्रोग्रामर यह जांचने के तुच्छ रखरखाव के बजाय महत्वपूर्ण सत्यापन कोड पर ध्यान केंद्रित कर सकते हैं कि कोई मान वास्तव में सही डोमेन में है।

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

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

मानक साधन एक इंटरफ़ेस है जिसमें एक टैग के रूप में एक गैर-निर्यातित, कुछ भी न करने की विधि है।

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

दूसरी ओर, कुछ ऐसा होना:

func foo(val string|int|error) {
    switch v:= val.(type) {
    case string:
        ...
    }
}

सम प्रकार के मूल्य का उपयोग करने में उपभोक्ता को पूरी शक्ति देता है। इसका मूल्य ठोस है, व्याख्या के लिए खुला नहीं है।

@मेरोवियस
आपके द्वारा उल्लिखित इन "खुली रकम" में कुछ लोगों को एक महत्वपूर्ण कमी के रूप में वर्गीकृत किया जा सकता है, जिसमें वे उन्हें "फीचर रेंगना" के लिए दुरुपयोग करने की अनुमति देंगे। यही कारण दिया गया है कि वैकल्पिक फ़ंक्शन तर्कों को एक विशेषता के रूप में क्यों खारिज कर दिया गया है।

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

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

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

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

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

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

@मेरोवियस

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

मैं इसे हमेशा या कभी नहीं के रूप में

अगर कोई खराब इनपुट पास कर रहा है तो वह तुरंत फट जाएगा, मैं सत्यापन कोड से परेशान नहीं हूं।

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

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

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

गोडोक -विश्लेषण

मुझे पता है लेकिन मुझे यह उपयोगी नहीं लगता। मेरे द्वारा ^C को हिट करने से पहले यह मेरे कार्यक्षेत्र पर 40 मिनट तक चला और इसे हर बार किसी पैकेज को स्थापित या संशोधित करने के लिए ताज़ा करने की आवश्यकता होती है। हालांकि #20131 (इस धागे से कांटा गया है!)

ऐसा कहा जा रहा है, आप इंटरफ़ेस को type Sum interface { sum() Sum } बदलकर उस समस्या को रोक सकते हैं और प्रत्येक मान स्वयं ही वापस आ सकता है। इस तरह, आप केवल sum() की वापसी का उपयोग कर सकते हैं, जो एम्बेडिंग के तहत भी अच्छी तरह से व्यवहार किया जाएगा।

मुझे यह उपयोगी नहीं लगा। यह स्पष्ट सत्यापन से अधिक लाभ प्रदान नहीं करता है और यह कम सत्यापन प्रदान करता है।

क्या [तथ्य यह है कि आप एक कॉन्स्ट/आईओटा एन्यूमरेशन के सदस्यों को जोड़ सकते हैं] एक सैद्धांतिक चिंता है या यह व्यवहार में आई है?

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

क्या [तथ्य यह है कि आप एक कॉन्स्ट/आईओटा एन्यूमरेशन के लिए एक अनटाइप्ड इंटीग्रल असाइन कर सकते हैं] एक सैद्धांतिक चिंता है या यह व्यवहार में आई है?

वह व्यवहार में सामने आया है। यह पता लगाने में देर नहीं लगी कि क्या गलत हुआ, लेकिन इसमें और भी कम समय लगता अगर संकलक ने कहा था "वहाँ, वह पंक्ति - वह गलत है"। उस विशेष मामले को संभालने के अन्य तरीकों की बात हो रही है, लेकिन मैं यह नहीं देखता कि वे सामान्य उपयोग कैसे होंगे।

यह मेरे लिए अमान्य स्थिति नहीं है। शून्य मान जादुई नहीं हैं। आईएमओ, sql.NullInt64{false,0} और NullInt64{false,42} बीच कोई अंतर नहीं है। दोनों SQL NULL के मान्य और समकक्ष प्रतिनिधित्व हैं। यदि सभी कोड Value का उपयोग करने से पहले Valid की जांच करते हैं, तो अंतर प्रोग्राम के लिए देखने योग्य नहीं है।

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

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

और, निश्चित रूप से, मैं वैकल्पिक प्रकारों के लिए *T पसंद करता हूं, हालांकि इसके साथ गैर-शून्य लागतें जुड़ी हुई हैं, निष्पादन स्पेसटाइम और कोड की पठनीयता दोनों में।

(उस विशेष उदाहरण के लिए पिक प्रस्ताव के साथ वास्तविक मूल्य या सही शून्य मान प्राप्त करने के लिए कोड v, _ := nullable.[Value] जो संक्षिप्त और सुरक्षित है।)

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

अन्यथा उनका उपयोग एक प्रदर्शन दंड के साथ आता है जो हो सकता है
गवारा नहीं। मेरे लिए, पास 10:41 AM, "जोश ब्लेचर स्नाइडर" <
सूचनाएं@github.com> ने लिखा:

पिक प्रस्ताव के साथ आप एपी या *पी आपको और अधिक देना चुन सकते हैं
मेमोरी ट्रेडऑफ़ पर अधिक नियंत्रण।

स्केलर मानों को संग्रहीत करने के लिए इंटरफेस आवंटित करने का कारण यह है कि आप नहीं करते हैं
यह तय करने के लिए कि क्या दूसरा शब्द a . है, एक प्रकार के शब्द को पढ़ना होगा
सूचक; देखें #8405 https://github.com/golang/go/issues/8405 for
विचार - विमर्श। समान कार्यान्वयन विचार संभवतः a . के लिए लागू होंगे
प्रकार चुनें, जिसका अर्थ व्यवहार में हो सकता है कि पी अंत में आवंटन और जा रहा है
वैसे भी गैर-स्थानीय।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/19412#issuecomment-323371837 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWB-wQD75N44TGoU6LWQhjED_uhKGUks5sZaKbgaJpZM4MTmSr
.

@urandom

उस स्थिति में क्या होता है जब डमी विधि निर्यात की जाती है और कोई तीसरा पक्ष "सम प्रकार" को लागू कर सकता है?

निर्यात की जाने वाली विधि और निर्यात किए जा रहे प्रकार के बीच अंतर है। ऐसा लगता है कि हम एक-दूसरे से बात कर रहे हैं। मेरे लिए, यह खुले और बंद रकम के बीच किसी भी अंतर के बिना ठीक काम करता प्रतीत होता है:

type X interface { x() X }
type IntX int
func (v IntX) x() X { return v }
type StringX string
func (v StringX) x() X { return v }
type StructX struct{
    Foo bool
    Bar int
}
func (v StructX) x() X { return v }

पैकेज के बाहर कोई विस्तार संभव नहीं है, फिर भी पैकेज के उपभोक्ता किसी अन्य की तरह ही मूल्यों का उपयोग, निर्माण और आसपास कर सकते हैं।

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

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

एक सत्यापनकर्ता को कॉल करना जो "ऐसा न करें" संदेश से घबराता है, ऐसा लगता है कि इसे संभालने का कम से कम आश्चर्यजनक तरीका है और कॉलर को अपना कोड ठीक करने देता है।

यदि वह func x को कॉल करता है तो यह या तो घबरा जाता है […]

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

समस्या यह है कि कोई ऐसा प्रकार बना सकता है जो उस योग में नहीं है जो संकलित करता है और आपके पैकेज में पारित किया जा सकता है।

भाषा में उचित योग प्रकार जोड़े बिना, इसे संभालने के लिए तीन विकल्प हैं

1. स्थिति को अनदेखा करें
2. सत्यापित करें और घबराएं/त्रुटि लौटाएं
3. एम्बेडेड मान को निहित रूप से निकालने और इसका उपयोग करके "जो आपका मतलब है" करने का प्रयास करें

3 मुझे 1 और 2 का अजीब मिश्रण लगता है: मैं नहीं देखता कि यह क्या खरीदता है।

मैं सहमत हूं कि "यदि आप आश्चर्यचकित हैं, कि अमान्य मूल्य का आपका जानबूझकर निर्माण अमान्य है, तो आपको अपनी अपेक्षाओं पर पुनर्विचार करने की आवश्यकता है", लेकिन, 3 के साथ, यह नोटिस करना बहुत कठिन हो सकता है कि कुछ गलत हो गया है और यहां तक ​​​​कि जब आप करते हैं यह पता लगाना मुश्किल होगा कि क्यों।

2 सबसे अच्छा लगता है क्योंकि यह दोनों कोड को अमान्य स्थिति में फिसलने से बचाता है और अगर कोई गड़बड़ करता है तो उसे यह बताता है कि वे गलत क्यों हैं और इसे कैसे ठीक किया जाए।

क्या मैं पैटर्न के इरादे को गलत समझ रहा हूं या क्या हम इसे अलग-अलग दर्शन से प्राप्त कर रहे हैं?

@urandom मैं स्पष्टीकरण की भी सराहना

समस्या यह है कि कोई ऐसा प्रकार बना सकता है जो उस योग में नहीं है जो संकलित करता है और आपके पैकेज में पारित किया जा सकता है।

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

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

मुझे लगता है कि यह गुणात्मक रूप से अलग है: जब लोग इस तरह से एम्बेडिंग का दुरुपयोग करते हैं (कम से कम proto.Message और इसे लागू करने वाले ठोस प्रकारों के साथ), वे आम तौर पर इस बारे में नहीं सोच रहे हैं कि क्या यह सुरक्षित है और यह कौन से अपरिवर्तनीय टूट सकता है . (उपयोगकर्ता मानते हैं कि इंटरफेस पूरी तरह से आवश्यक व्यवहारों का वर्णन करते हैं, लेकिन जब इंटरफेस को संघ या योग प्रकार के रूप में नियोजित किया जाता है तो वे अक्सर ऐसा नहीं करते हैं। https://github.com/golang/protobuf/issues/364 भी देखें।)

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

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

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

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

सुरक्षा का एक अन्य पक्ष लाभ का अर्थ है कि संकलक के पास अधिक जानकारी है और वह बेहतर तेज़ कोड उत्पन्न कर सकता है।

एक तथ्य यह भी है कि छद्म-योग को इंटरफेस के साथ बदलने में सक्षम होने के अलावा आप छद्म-योग "इन नियमित प्रकारों में से एक" जैसे json.Token या driver.Value को प्रतिस्थापित कर सकते हैं। वे कुछ और बहुत दूर हैं लेकिन यह एक कम जगह होगी जहां interface{} आवश्यक है।

यह असुरक्षित को अमान्य मान बनाने का एकमात्र तरीका भी बना देगा

मुझे नहीं लगता कि मैं "अमान्य मूल्य" की परिभाषा को समझता हूं जो इस कथन की ओर ले जाता है।

@neild अगर आपके पास था

var v pick {
  None struct{}
  A struct { X int; Y *T}
  B int
}

इसे स्मृति में रखा जाएगा जैसे

struct {
  activeField int //which of None (0), A (1), or B (2) is the current field
  theInt int // If None always 0
  thePtr *T // If None or B, always nil
}

और असुरक्षित के साथ आप thePtr सेट कर सकते हैं, भले ही activeField 0 या 2 था या theInt का मान सेट कर सकते थे, भले ही activeField 0 था।

किसी भी मामले में यह उन मान्यताओं को अमान्य कर देगा जो संकलक बना रहे होंगे और उसी तरह की सैद्धांतिक बग की अनुमति देंगे जो आज हमारे पास हो सकती हैं।

लेकिन जैसा कि @bcmills ने बताया कि यदि आप असुरक्षित उपयोग कर रहे हैं तो आपको बेहतर पता होगा कि आप क्या कर रहे हैं क्योंकि यह परमाणु विकल्प है।

जो मुझे समझ में नहीं आता है वह अमान्य मान बनाने का एकमात्र तरीका असुरक्षित क्यों है।

var t time.Timer

t एक अमान्य मान है; t.C सेट नहीं है, t.Stop कॉल करने से घबराहट होगी, आदि। किसी असुरक्षित की आवश्यकता नहीं है।

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

@neild हाँ क्षमा करें मैं अपनी परिभाषाओं के साथ ढीला हो रहा हूं।

मुझे योग प्रकार के अपरिवर्तनीयों के संबंध में अमान्य कहना चाहिए था।

योग में अलग-अलग प्रकार निश्चित रूप से अमान्य स्थिति में हो सकते हैं।

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

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

func F(sum SumInterface) {
    switch v := sum {
    case Screwdriver:
             ...
    default:
           panic ("Someone implementing a new type which gets passed to F and causes a runtime panic 3 weeks into production")
    }
}

तो, मुझे ऐसा प्रतीत होता है कि इंटरफ़ेस-आधारित योग-प्रकार अनुकरण के साथ लोगों के अधिकांश मुद्दों को टोलिंग और/या सम्मेलन द्वारा हल किया जा सकता है। उदाहरण के लिए, यदि किसी इंटरफ़ेस में एक गैर-निर्यातित विधि है, तो सभी संभव (हां, जानबूझकर छेड़छाड़) कार्यान्वयन को समझना मुश्किल होगा। इसी तरह, आईओटा-आधारित एनम के साथ अधिकांश मुद्दों को संबोधित करने के लिए, "एक एनम एक type Foo int फॉर्म की घोषणा के साथ एक सरल सम्मेलन है const ( FooA Foo = iota; FooB; FooC ) " व्यापक और सटीक उपकरण लिखने में सक्षम होगा उनके लिए भी।

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

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

@Merovius यह एक अच्छी स्थिति है।

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

भले ही, इसे एक्सप्लोर करना एक उचित विचार है, तो आइए इसे एक्सप्लोर करें।

गो में स्यूडोसम के सबसे आम परिवारों को संक्षेप में प्रस्तुत करना है: (मोटे तौर पर घटना के क्रम में)

• कॉन्स्ट/आईओटा एनम।
• एक ही पैकेज में परिभाषित प्रकार के योग के लिए टैग विधि के साथ इंटरफेस।
• *T एक वैकल्पिक के लिए T
• एक एनम के साथ संरचना जिसका मूल्य निर्धारित करता है कि कौन से फ़ील्ड सेट किए जा सकते हैं (जब एनम एक बूल है और केवल एक अन्य फ़ील्ड है तो यह एक अन्य प्रकार का वैकल्पिक T )
• interface{} जो कि सीमित प्रकार के ग्रैब बैग तक सीमित है।

उन सभी का उपयोग योग प्रकार और गैर-योग प्रकार दोनों के लिए किया जा सकता है। पहले दो का उपयोग किसी और चीज के लिए शायद ही कभी किया जाता है कि यह केवल यह मानने के लिए समझ में आता है कि वे योग प्रकारों का प्रतिनिधित्व करते हैं और कभी-कभी झूठी सकारात्मक स्वीकार करते हैं। इंटरफ़ेस रकम के लिए, यह बिना किसी पैरामीटर या रिटर्न के और किसी भी सदस्य पर कोई निकाय नहीं के साथ गैर-निर्यातित विधि तक सीमित कर सकता है। Enums के लिए यह केवल उन्हें पहचानने के लिए समझ में आता है जब वे केवल Type = iota इसलिए जब अभिव्यक्ति के हिस्से के रूप में आईओटा का उपयोग किया जाता है तो इसे ट्रिप नहीं किया जाता है।

*T के लिए एक वैकल्पिक T वास्तव में एक नियमित रूप से सूचक से भेद करना मुश्किल हो जाएगा। इसे कन्वेंशन type O = *T दिया जा सकता है। यह पता लगाना संभव होगा, हालांकि थोड़ा मुश्किल है क्योंकि उपनाम नाम प्रकार का हिस्सा नहीं है। type O *T का पता लगाना आसान होगा लेकिन कोड में काम करना कठिन होगा। दूसरी ओर जो कुछ भी करने की आवश्यकता है वह अनिवार्य रूप से प्रकार में बनाया गया है, इसलिए इसे पहचानने से टूलिंग में बहुत कम लाभ होता है। आइए इस एक को अनदेखा करें। (जेनेरिक संभवतः type Optional(T) *T की तर्ज पर कुछ की अनुमति देगा जो इन्हें "टैगिंग" को सरल करेगा)।

एक एनम के साथ संरचना टूलिंग के बारे में तर्क करना कठिन होगा, कौन से क्षेत्र एनम के लिए किस मूल्य के साथ जाते हैं? हम इसे कन्वेंशन के लिए सरल बना सकते हैं कि एनम में प्रति सदस्य एक फ़ील्ड होना चाहिए और यह कि एनम मान और फ़ील्ड मान समान होना चाहिए, उदाहरण के लिए:

type Which int
const (
  A Which = iota
  B
  C
)
type Sum struct {
  Which
  A struct{} // has to be included to line up with the value of Which
  B struct { X int; Y float64 }
  C struct { X int; Y int } 
}

उसे वैकल्पिक प्रकार नहीं मिलेंगे, लेकिन हम पहचानकर्ता में "2 फ़ील्ड्स, फर्स्ट इज बूल" विशेष केस कर सकते हैं।

interface{} का उपयोग हड़पने वाले बैग के योग के लिए //gosum: int, float64, string, Foo जैसी जादुई टिप्पणी के बिना पता लगाना असंभव होगा

वैकल्पिक रूप से, निम्नलिखित परिभाषाओं के साथ एक विशेष पैकेज हो सकता है:

package sum
type (
  Type struct{}
  Enum int
  OneOf interface{}
)

और केवल अगर वे type MyEnum sum.Enum फॉर्म के हैं, तो केवल एनम को पहचानें, केवल इंटरफेस और स्ट्रक्चर्स को तभी पहचानें जब वे एम्बेड करें sum.Type , और केवल interface{} हड़पने वाले बैग जैसे type GrabBag sum.OneOf पहचानें
पेशेवरों

• कोड में स्पष्ट: यदि यह इतना चिह्नित है तो यह 100% योग प्रकार है, कोई झूठी सकारात्मक नहीं है।
• उन परिभाषाओं में दस्तावेज हो सकते हैं जो बताते हैं कि उनका क्या मतलब है और पैकेज दस्तावेज उन उपकरणों से लिंक हो सकता है जिनका उपयोग इन प्रकारों के साथ किया जा सकता है
• कुछ में प्रतिबिंब में कुछ दृश्यता होगी
  दोष
• पुराने कोड और stdlib से बहुत सारे झूठे नकारात्मक (जो उनका उपयोग नहीं करेंगे)।
• उन्हें उपयोगी होने के लिए उपयोग करना होगा ताकि गोद लेने की गति धीमी हो और संभवतः कभी भी 100% न हो और इस विशेष पैकेज को मान्यता देने वाले उपकरणों की प्रभावशीलता गोद लेने का एक कार्य होगा, हालांकि प्रयोग दिलचस्प है लेकिन संभवतः अवास्तविक है।

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

हम मोटे तौर पर टूलींग को जनरेटिव (जैसे स्ट्रिंगर) और आत्मनिरीक्षण (जैसे गोलिंट) में समूहित कर सकते हैं।

सबसे सरल जनरेटिव कोड लापता मामलों के साथ एक स्विच स्टेटमेंट भरने के लिए एक उपकरण होगा। इसका उपयोग संपादकों द्वारा किया जा सकता है। एक बार एक योग प्रकार को एक योग प्रकार के रूप में पहचाना जाता है तो यह छोटा होता है (थोड़ा थकाऊ लेकिन वास्तविक पीढ़ी तर्क भाषा समर्थन के साथ या बिना समान होगा)।

सभी मामलों में एक ऐसा फ़ंक्शन उत्पन्न करना संभव होगा जो "इनमें से एक" अपरिवर्तनीय को मान्य करे।

Enums के लिए स्ट्रिंगर जैसे और टूल हो सकते हैं। https://github.com/golang/go/issues/19814#issuecomment -291002852 में मैंने कुछ संभावनाओं का उल्लेख किया है।

सबसे बड़ा जनरेटिव टूल कंपाइलर है जो इस जानकारी के साथ बेहतर मशीन कोड तैयार कर सकता है, लेकिन आह ठीक है।

मैं इस समय किसी अन्य के बारे में नहीं सोच सकता। क्या किसी की इच्छा सूची में कुछ है?

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

1. सुनिश्चित करें कि सभी संभावित राज्यों को संभाला जाता है
2. सुनिश्चित करें कि कोई अमान्य स्थिति नहीं बनाई गई है (जो 1 द्वारा किए गए कार्य को अमान्य कर देगा)

1 छोटा है, लेकिन इसके लिए सभी संभावित राज्यों और एक डिफ़ॉल्ट मामले की आवश्यकता होगी क्योंकि 2 को 100% सत्यापित नहीं किया जा सकता है (यहां तक ​​​​कि असुरक्षित को भी अनदेखा कर रहा है) और आप उम्मीद नहीं कर सकते कि आपके कोड का उपयोग करने वाले सभी कोड इस लिटर को वैसे भी चलाते हैं।

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

दूसरी बड़ी बात गोडोक में दिखाई देगी। Godoc पहले से ही const/iota को समूहित करता है और #20131 इंटरफ़ेस स्यूडोसम के साथ मदद करेगा। संरचना संस्करण के साथ वास्तव में कुछ भी नहीं है जो कि अपरिवर्तनीय निर्दिष्ट करने के अलावा परिभाषा में स्पष्ट नहीं है।

साथ ही ऑफ-लाइन टूल—लिंटर, कोड जेनरेटर आदि।

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

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

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

तो, मेरा सवाल जानबूझकर था: इस जानकारी को रनटाइम पर उपलब्ध कराने का उपयोग मामला क्या होगा?

भले ही, इसे एक्सप्लोर करना एक उचित विचार है, तो आइए इसे एक्सप्लोर करें।

जब मैंने कहा "इसे एक्सप्लोर करें", मेरा मतलब यह नहीं था "उनकी गणना करें और उनके बारे में एक शून्य में बहस करें", मेरा मतलब था "उन उपकरणों को लागू करें जो इन सम्मेलनों का उपयोग करते हैं और देखते हैं कि वे कितने उपयोगी/आवश्यक/व्यावहारिक हैं"।

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

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

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

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

यह निश्चित रूप से शुरू करने के लिए एक अच्छी जगह है और इसे पैकेजों के एक बड़े सेट पर चलाने के बाद डायल किया जा सकता है और यह देखने के लिए कि कितने झूठे सकारात्मक/नकारात्मक हैं

https://godoc.org/github.com/jimmyfrasche/closed

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

cmds/closed-exporer में उपयोग का एक उदाहरण है जो इसके आयात पथ द्वारा निर्दिष्ट पैकेज में पाए गए सभी बंद प्रकारों को भी सूचीबद्ध करेगा।

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

Enums के साथ मैं दूसरी तरफ गया और परिभाषित प्रकार के हर गैर-बिटसेट कॉन्स को रिकॉर्ड किया। मैं खोजे गए बिटसेट को भी बेनकाब करने की योजना बना रहा हूं।

यह वैकल्पिक संरचनाओं का पता नहीं लगाता है या खाली इंटरफेस को परिभाषित नहीं करता है, क्योंकि उन्हें किसी प्रकार की मार्कर टिप्पणी की आवश्यकता होगी, लेकिन यह विशेष मामला है जो stdlib में है।

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

मुझे यह मददगार लगेगा यदि आप कुछ ऐसे उदाहरण प्रदान कर सकते हैं जो नहीं थे।

@Merovius क्षमा करें मैंने एक सूची नहीं रखी। मैंने उन्हें stdlib.sh (cmds/बंद-एक्सप्लोरर में) चलाकर पाया। अगर मैं अगली बार इसके साथ खेलने के लिए एक अच्छा उदाहरण चलाता हूं तो मैं इसे पोस्ट करूंगा।

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

@jimmyfrasche मैं तर्क दूंगा कि उन्हें बंद रकम के रूप में ठीक से माना जाना चाहिए। मैं तर्क दूंगा कि यदि वे गतिशील प्रकार (यानी केवल इंटरफ़ेस में विधियों को कॉल करना) की परवाह नहीं करते हैं, तो एक स्थिर लिंटर शिकायत नहीं करेगा, क्योंकि "सभी स्विच संपूर्ण हैं" - इसलिए उनका इलाज करने के लिए कोई नकारात्मक पक्ष नहीं है बंद रकम के रूप में। हैं, OTOH, वे टाइप स्विच करते हैं कभी कभी और एक मामले को छोड़, शिकायत सही होगा - कि वास्तव में बात यह है कि लिंटर पकड़ माना जाता है की तरह होगा।

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

भाषा की कल्पना को इसका उल्लेख करने की आवश्यकता नहीं है, लेकिन ऐसा लगता है कि कुछ छोटे संघ प्रकारों के लिए किसी सरणी के स्मृति उपयोग को आधे में काटने से यूनियनों के लिए एक बहुत ही आकर्षक तर्क हो सकता है? यह आपको कुछ ऐसा करने देता है, जहां तक ​​मुझे पता है कि आज गो में करना असंभव है। इसके विपरीत, इंटरफेस के शीर्ष पर यूनियनों को लागू करने से कार्यक्रम की शुद्धता और समझ में मदद मिल सकती है, लेकिन मशीन स्तर पर कुछ भी नया नहीं करता है।

मैंने कोई प्रदर्शन परीक्षण नहीं किया है; सिर्फ अनुसंधान के लिए एक दिशा की ओर इशारा करते हुए।

आप एक मान को एक असुरक्षित के रूप में लागू कर सकते हैं। इसके बजाय सूचक।

फ़र, 6, 2018 3:54 pm पर, "ब्रायन Slesinsky" [email protected] लिखा है:

मैं यह पता लगाने के लिए एक अच्छा शब्द रखना चाहता हूं कि संघ के प्रकार कैसे कम हो सकते हैं
स्मृति प्रयोग। मैं गो में एक दुभाषिया लिख ​​रहा हूं और एक मान प्रकार है कि
आवश्यक रूप से एक इंटरफ़ेस के रूप में कार्यान्वित किया जाता है क्योंकि मान पॉइंटर्स हो सकते हैं
विभिन्न प्रकार के लिए। इसका संभावित रूप से मतलब है कि [] मान दोगुना से अधिक लेता है
एक छोटे से टैग के साथ पॉइंटर को पैक करने की तुलना में मेमोरी जैसा आप कर सकते थे
सी में यह बहुत कुछ लगता है?

भाषा की कल्पना को इसका उल्लेख करने की आवश्यकता नहीं है, लेकिन यह स्मृति को काटने जैसा लगता है
कुछ छोटे संघ प्रकारों के लिए आधे में एक सरणी का उपयोग एक सुंदर हो सकता है
संघों के लिए सम्मोहक तर्क? यह आपको कुछ ऐसा करने देता है जहाँ तक I
आज गो में करना असंभव है। इसके विपरीत, यूनियनों को लागू करना
इंटरफेस के शीर्ष कार्यक्रम की शुद्धता में मदद कर सकते हैं और
समझ में आता है, लेकिन मशीन स्तर पर कुछ भी नया नहीं करता है।

मैंने कोई प्रदर्शन परीक्षण नहीं किया है; बस के लिए एक दिशा की ओर इशारा करते हुए
अनुसंधान।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/19412#issuecomment-363561070 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AGGWBz-L3t0YosVIJmYNyf2iQ-YgIXLGks5tSLv9gaJpZM4MTmSr
.

@skybrian यह राशि प्रकारों के कार्यान्वयन के संबंध में बहुत ही

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

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

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

@Merovius हाँ, पैक मेमोरी लेआउट को समझने के लिए इसे रनटाइम और कचरा कलेक्टर को बदलने की आवश्यकता है। इस तरह की बात है; पॉइंटर्स को गो रनटाइम द्वारा प्रबंधित किया जाता है, इसलिए यदि आप सुरक्षित तरीके से इंटरफेस से बेहतर करना चाहते हैं, तो आप इसे लाइब्रेरी या कंपाइलर में नहीं कर सकते।

लेकिन मैं आसानी से स्वीकार करूंगा कि एक तेज़ दुभाषिया लिखना एक असामान्य उपयोग का मामला है। शायद अन्य हैं? ऐसा लगता है कि किसी भाषा सुविधा को प्रेरित करने का एक अच्छा तरीका उन चीज़ों को ढूंढना है जो आज गो में आसानी से नहीं की जा सकतीं।

यह सच है।

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

6 फरवरी, 2018 को शाम 6:15 बजे, "ब्रायन स्लेसिंस्की" नोटिफिकेशन @github.com ने लिखा:

@DemiMarie https://github.com/demimarie असुरक्षित.पॉइंटर ऐप पर काम नहीं करता है
इंजन, और किसी भी मामले में, यह आपको बिना बिट्स पैक करने नहीं देगा
कूड़ा उठाने वाले के साथ खिलवाड़। संभव होता तो भी नहीं होता
पोर्टेबल।

@metrovius हाँ, इसे रनटाइम और कचरा संग्रहकर्ता को बदलने की आवश्यकता है
पैक्ड मेमोरी लेआउट को समझने के लिए। इस तरह की बात है; संकेत हैं
गो रनटाइम द्वारा प्रबंधित, इसलिए यदि आप इंटरफ़ेस से बेहतर करना चाहते हैं a
सुरक्षित तरीका, आप इसे पुस्तकालय में या संकलक में नहीं कर सकते।

लेकिन मैं आसानी से स्वीकार करूंगा कि एक तेज़ दुभाषिया लिखना एक असामान्य उपयोग है
मामला। शायद अन्य हैं? यह प्रेरित करने का एक अच्छा तरीका लगता है a
भाषा की विशेषता उन चीजों को ढूंढना है जो आज गो में आसानी से नहीं की जा सकती हैं।

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

मुझे @rogpeppe का प्रस्ताव काफी आकर्षक लगता है। मुझे यह भी आश्चर्य है कि क्या @griesemer द्वारा पहले से पहचाने गए लोगों के साथ जाने के लिए अतिरिक्त लाभों को अनलॉक करने की क्षमता है।

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

लेकिन एक प्रकार सिर्फ एक विधि सेट से अधिक है। क्या होगा यदि योग प्रकार इसके घटक प्रकारों द्वारा समर्थित संचालन के प्रतिच्छेदन का समर्थन करता है?

उदाहरण के लिए, विचार करें:

var x int|float64

विचार यह है कि निम्नलिखित काम करेगा।

x += 5

यह पूर्ण प्रकार के स्विच को लिखने के बराबर होगा:

switch i := x.(type) {
case int:
    x = i + 5
case float64:
    x = i + 5
}

एक अन्य प्रकार में एक प्रकार का स्विच शामिल होता है जहां एक घटक प्रकार स्वयं एक योग प्रकार होता है।

type Num int | float64
type StringOrNum string | Num 
var x StringOrNum

switch i := x.(type) {
case string:
    // Do string stuff.
case Num:
    // Would be nice if we could use i as a Num here.
}

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

var x int|float64

var x, y int | float64 बारे में क्या? इन्हें जोड़ते समय यहां क्या नियम हैं? कौन सा हानिपूर्ण रूपांतरण किया जाता है (और क्यों)? परिणाम का प्रकार क्या होगा?

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

और भी अधिक मनोरंजन के लिए:

var x, y, z int|string|rune
x = 42
y = 'a'
z = "b"
fmt.Println(x + y + z)
fmt.Println(x + z + y)
fmt.Println(y + x + z)
fmt.Println(y + z + x)
fmt.Println(z + x + y)
fmt.Println(z + y + x)

सभी int , string और rune में एक + ऑपरेटर है; उपरोक्त छपाई क्या है, क्यों और सबसे बढ़कर, परिणाम पूरी तरह से भ्रमित करने वाला कैसे नहीं हो सकता है?

var x, y int | float64 बारे में क्या? इन्हें जोड़ते समय यहां क्या नियम हैं? कौन सा हानिपूर्ण रूपांतरण किया जाता है (और क्यों)? परिणाम का प्रकार क्या होगा?

@Merovius कोई हानिकारक रूपांतरण निहित रूप से नहीं x + y संकलित नहीं होगा क्योंकि यह एक संभावित निहित रूपांतरण का तात्पर्य है। लेकिन निम्नलिखित में से कोई भी संकलित होगा:

z = int(x) + int(y)
z = float64(x) + float64(y)

इसी प्रकार आपका xyz उदाहरण संकलित नहीं होगा क्योंकि इसके लिए संभावित निहित रूपांतरणों की आवश्यकता होती है।

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

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

सभी int, string और rune में एक + ऑपरेटर होता है; उपरोक्त छपाई क्या है, क्यों और सबसे बढ़कर, परिणाम पूरी तरह से भ्रमित करने वाला कैसे नहीं हो सकता है?

बस यह जोड़ना चाहता था कि मेरा "क्या होगा यदि योग प्रकार इसके घटक प्रकारों द्वारा समर्थित संचालन के प्रतिच्छेदन का समर्थन करता है?" गो स्पेक के एक प्रकार के विवरण से प्रेरित था क्योंकि "एक प्रकार उन मूल्यों के लिए विशिष्ट संचालन और विधियों के साथ मूल्यों का एक सेट निर्धारित करता है।"।

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

एक और उदाहरण शून्य से तुलना है:

var x []int | []string
fmt.Println(x == nil)  // Prints true
x = []string(nil)
fmt.Println(x == nil)  // Still prints true

दोनों घटक प्रकार हैं कम से कम एक प्रकार शून्य से तुलनीय है, इसलिए हम योग प्रकार को बिना किसी प्रकार के स्विच के शून्य से तुलना करने की अनुमति देते हैं। बेशक यह कुछ हद तक अंतर है कि वर्तमान में इंटरफेस कैसे व्यवहार करते हैं, लेकिन यह प्रति https://github.com/golang/go/issues/22729 एक बुरी बात नहीं हो सकती है

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

समस्या यह है, कि परिणाम या तो a) में वही समस्याएं होंगी जो स्वचालित रूपांतरणों में होती हैं या b) अत्यंत (और IMO भ्रामक रूप से) दायरे में सीमित होंगी - अर्थात्, सभी ऑपरेटर केवल अनपेक्षित शाब्दिक के साथ काम करेंगे, सबसे अच्छा।

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

बहुत छोटे (यदि कोई हो) मूर्त लाभ के लिए यह सब मेरे लिए वास्तव में गन्दा लगता है।

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

ओह और इसके बारे में भी स्पष्ट होना: इसका तात्पर्य है कि आप कभी भी यह तय

@Merovius ध्यान दें कि संगतता समस्या का एक प्रकार मूल प्रस्ताव के साथ पहले से मौजूद है क्योंकि "योग प्रकार का विधि सेट विधि सेट का प्रतिच्छेदन रखता है
इसके सभी घटक प्रकारों का"। इसलिए यदि आप एक नया घटक प्रकार जोड़ते हैं जो उस विधि सेट को लागू नहीं करता है, तो वह एक गैर-पश्चगामी संगत परिवर्तन होगा।

ओह और इसके बारे में भी स्पष्ट होना: इसका तात्पर्य है कि आप कभी भी यह तय नहीं कर सकते कि आप एक पैरामीटर या रिटर्न प्रकार या चर का विस्तार करना चाहते हैं या ... एक सिंगलटन-प्रकार से योग तक। क्योंकि कोई भी नया प्रकार जोड़ने से कुछ ऑपरेशन (जैसे असाइनमेंट) कंपाइल करने में विफल हो जाएंगे

असाइनमेंट व्यवहार @rogpeppe द्वारा वर्णित के रूप में रहेगा लेकिन कुल मिलाकर मुझे यकीन नहीं है कि मैं इस बिंदु को समझता हूं।

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

var x int | float64
fmt.Println(x == "hello")  // compilation error?
x = 0.0
fmt.Println(x == 0) // true or false?  I vote true :-)

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

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

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

असाइनमेंट व्यवहार वैसा ही रहेगा जैसा @rogpeppe . द्वारा बताया गया है

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

fmt.Println(x == "hello") // compilation error?

यह संभवत: उनके प्रस्ताव में भी जोड़ा जाएगा। हमारे पास पहले से ही इंटरफेस के लिए एक समान विशेष मामला

गैर-इंटरफ़ेस प्रकार X का मान x और इंटरफ़ेस प्रकार T का मान t तुलनीय है जब प्रकार X के मान तुलनीय हैं और X T को लागू करता है। वे समान हैं यदि t का गतिशील प्रकार X के समान है और t का गतिशील मान x के बराबर है .

fmt.Println(x == 0) // true or false? I vote true :-)

बहुधा झूठा। यह देखते हुए कि समान

var x int|float64 = 0.0
y := 0
fmt.Println(x == y)

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

हालांकि, इस प्रश्न का उत्तर किसी भी तरह से देने की आवश्यकता नहीं है, सभी अभिव्यक्तियों को योग प्रकारों का उपयोग करने की अनुमति देने की आवश्यकता नहीं है जो घटक भागों के लिए समझ में आ सकते हैं।

लेकिन दोहराना: मैं रकम के लिए एक अलग प्रस्ताव के पक्ष में बहस नहीं कर रहा हूं। मैं इसके खिलाफ बहस कर रहा हूं।

fmt.Println(x == "hello") // compilation error?

यह संभवत: उनके प्रस्ताव में भी जोड़ा जाएगा।

सुधार: युक्ति पहले से ही इस संकलन त्रुटि को कवर करती है, यह देखते हुए कि इसमें कथन शामिल है

किसी भी तुलना में, पहला ऑपरेंड दूसरे ऑपरेंड के प्रकार के लिए असाइन करने योग्य होना चाहिए, या इसके विपरीत।

@Merovius आप प्रस्ताव के मेरे संस्करण के बारे में कुछ अच्छी बातें करते हैं। मैं उन पर और बहस करने से बचूंगा, लेकिन मैं 0 प्रश्न की तुलना में थोड़ा और आगे बढ़ना चाहूंगा क्योंकि यह मूल प्रस्ताव पर समान रूप से लागू होता है।

fmt.Println(x == 0) // true or false? I vote true :-)

बहुधा झूठा। यह देखते हुए कि समान

var x int|float64 = 0.0
y := 0
fmt.Println(x == y)
एक संकलन-त्रुटि होनी चाहिए (जैसा कि हमने ऊपर निष्कर्ष निकाला है),

मुझे यह उदाहरण बहुत सम्मोहक नहीं लगता क्योंकि यदि आप पहली पंक्ति को var x float64 = 0.0 बदलते हैं तो आप उसी तर्क का उपयोग यह तर्क देने के लिए कर सकते हैं कि फ्लोट64 से 0 की तुलना करना गलत होना चाहिए। (मामूली बिंदु: (ए) मुझे लगता है कि आप पहली पंक्ति पर फ्लोट 64 (0) का मतलब है, क्योंकि 0.0 int को असाइन करने योग्य है। (बी) x == y आपके उदाहरण में संकलन त्रुटि नहीं होनी चाहिए। हालांकि इसे झूठा प्रिंट करना चाहिए।)

मुझे लगता है कि आपका विचार है कि "यह एक इंटरफ़ेस प्रकार के लिए निरंतर निर्दिष्ट करने के समान है और इस प्रकार इसका डिफ़ॉल्ट प्रकार होना चाहिए" अधिक आकर्षक है (मान लीजिए कि आपका मतलब योग प्रकार है), तो उदाहरण होगा:

var x,y int|float64 = float64(0), 0
fmt.Println(x == y) // झूठा

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

मुझे यह उदाहरण बहुत सम्मोहक नहीं लगता क्योंकि यदि आप पहली पंक्ति को var x float64 = 0.0 में बदलते हैं तो आप उसी तर्क का उपयोग यह तर्क देने के लिए कर सकते हैं कि float64 से 0 की तुलना करना गलत होना चाहिए।

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

ध्यान दें, कि float64(0) से int(0) (यानी var x float64 = 0.0 द्वारा प्रतिस्थापित योग के साथ उदाहरण) false , हालांकि, यह एक संकलन-समय है त्रुटि (जैसा होना चाहिए)। ठीक यही मेरी बात है ; आपका प्रस्ताव वास्तव में केवल तभी उपयोगी होता है जब अप्रकाशित स्थिरांक के साथ जोड़ा जाता है, क्योंकि किसी और चीज के लिए यह संकलित नहीं होगा।

(ए) मुझे लगता है कि आप पहली पंक्ति पर फ्लोट 64 (0) का मतलब है, क्योंकि 0.0 int को असाइन करने योग्य है।

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

(बी) x==y आपके उदाहरण में एक संकलन त्रुटि नहीं होनी चाहिए। हालांकि इसे झूठा प्रिंट करना चाहिए।)

नहीं, यह संकलन समय त्रुटि होनी चाहिए। आपने कहा है, कि ऑपरेशन e1 == y , जिसमें e1 एक योग-प्रकार की अभिव्यक्ति है, की अनुमति दी जानी चाहिए यदि और केवल अगर अभिव्यक्ति घटक प्रकार के किसी भी विकल्प के साथ संकलित होगी। यह देखते हुए कि मेरे उदाहरण में, x का प्रकार int|float64 और y का प्रकार int और यह दिया गया है कि float64 और int तुलनीय नहीं हैं, इस शर्त का स्पष्ट रूप से उल्लंघन किया गया है।

इस संकलन को बनाने के लिए आपको इस शर्त को छोड़ना होगा कि किसी भी घटक टाइप किए गए अभिव्यक्ति को प्रतिस्थापित करने के लिए भी संकलित करने की आवश्यकता है; किस बिंदु पर हम नियम स्थापित करने की स्थिति में हैं कि इन अभिव्यक्तियों में उपयोग किए जाने पर प्रकारों को कैसे बढ़ावा दिया जाता है या परिवर्तित किया जाता है (जिसे "सी मेस" भी कहा जाता है)।

पिछली आम सहमति यह रही है कि योग प्रकार इंटरफ़ेस प्रकारों में बहुत अधिक नहीं जोड़ते हैं।

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

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

उदाहरण

स्यूडोकोड में iotuils.WriteFile -जैसे फ़ंक्शन पर विचार करें। अनिवार्य प्रवाह इस तरह दिखेगा

file = open(name, os.write)
if file is error
    return error("cannot open " + name + " writing: " + file.error)
if file.write(data) is error:
    return error("cannot write into " + name + " : " + file.error)
return ok

और यह Rust . में कैसा दिखता है

match open(name, os.write)
    file
        match file.write(data, os.write)
            err
                return error("cannot open " + name + " writing: " + err)
            ok
                return ok
    err
        return error("cannot write into " + name + " : " + err)

यह सुरक्षित है लेकिन बदसूरत है।

और मेरा प्रस्ताव:

type result[T, Err] oneof {
    default T
    Error Err
}

और प्रोग्राम कैसा दिख सकता है ( result[void, string] = !void )

file := os.Open(name, ...)
if !file {
    return result.Error("cannot open " + name + " writing: " + file.Error)
}
if res := file.Write(data); !res {
    return result.Error("cannot write into " + name + " : " + res.Error)
}
return ok

यहां डिफ़ॉल्ट शाखा अज्ञात है और त्रुटि शाखा को .Error साथ एक्सेस किया जा सकता है (एक बार यह ज्ञात हो जाने पर परिणाम त्रुटि है)। एक बार जब यह ज्ञात हो जाता है कि फ़ाइल सफलतापूर्वक खोली गई थी तो उपयोगकर्ता इसे चर के माध्यम से ही एक्सेस कर सकता है। सबसे पहले अगर हम सुनिश्चित करते हैं कि file सफलतापूर्वक खोला गया था या अन्यथा बाहर निकल गया था (और इस प्रकार आगे के बयानों को पता है कि फ़ाइल कोई त्रुटि नहीं है)।

जैसा कि आप देखते हैं, यह दृष्टिकोण अनिवार्य प्रवाह को संरक्षित करता है और प्रकार की सुरक्षा प्रदान करता है। एनपीडी हैंडलिंग इसी तरह से की जा सकती है:

type Reference[T] oneof {
    default T
    nil
}
// Reference[T] = *T

हैंडलिंग परिणाम के समान है

@ सिर्कोन , आपका जंग उदाहरण मुझे विश्वास नहीं दिलाता है कि जंग में सीधे योग प्रकार के साथ कुछ भी गलत है। इसके बजाय, यह सुझाव देता है कि if कथनों का उपयोग करके योग प्रकारों पर पैटर्न-मिलान को और अधिक गो-जैसी बनाया जा सकता है। कुछ इस तरह:

ferr := os.Open(name, ...)
if err(e) := ferr {           // conditional match and unpack, initializing e
  return fmt.Errorf("cannot open %v: %v", name, e)
}
ok(f) := ferr                  // unconditional match and unpack, initializing f
werr := f.Write(data)
...

(योग प्रकार की भावना में, यह संकलन त्रुटि होगी यदि संकलक यह साबित नहीं कर सकता कि एक बिना शर्त मैच हमेशा सफल होता है क्योंकि ठीक एक मामला शेष है।)

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

@sirkon

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

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

एनपीडी हैंडलिंग इसी तरह से की जा सकती है

मुझे लगता है कि यह वास्तव में दिखाता है कि आपका दृष्टिकोण वास्तव में कोई महत्वपूर्ण मूल्य नहीं जोड़ता है। जैसा कि आप इंगित करते हैं, यह केवल dereference के लिए एक अलग वाक्यविन्यास जोड़ता है। लेकिन AFAICT कुछ भी प्रोग्रामर को उस सिंटैक्स का उपयोग शून्य-मूल्य पर करने से नहीं रोक रहा है (जो संभावित रूप से अभी भी घबराएगा)। यानी प्रत्येक प्रोग्राम जो *p का उपयोग करके मान्य है, p.T (या यह p.default का उपयोग करके भी मान्य है? यह बताना मुश्किल है कि आपका विचार विशेष रूप से क्या है ) और इसके विपरीत।

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

@मेरोवियस

और यह देखते हुए कि इसके डेवलपर्स का एक महत्वपूर्ण हिस्सा Google में काम करता है, आपको बस यह मान लेना चाहिए कि वे आपसे बेहतर जानते हैं,

धन्य हैं विश्वासी।

जैसा कि आप इंगित करते हैं, यह केवल dereference के लिए एक अलग वाक्यविन्यास जोड़ता है।

फिर

var written int64
...
res := os.Stdout.Write(data) // Write([]byte) -> Result[int64, string] ≈ !int64
written += res // Will not compile as res is a packed result type
if !res {
    // we are living on non-default res branch thus the only choice left is the default
    return Result.Error(...)
}
written += res // is OK

@skybrian

ferr := os.Open(...)

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

@ सिरकोन जाहिर तौर पर आपको लोगों से आंखों से बात करने में बहुत कम दिलचस्पी है। मैं इसे उस पर छोड़ दूँगा।

आइए हम अपनी बातचीत को सभ्य रखें, और गैर-रचनात्मक टिप्पणियों से बचें। हम चीजों पर असहमत हो सकते हैं, लेकिन फिर भी एक सम्मानजनक प्रवचन बनाए रख सकते हैं। https://golang.org/conduct।

और यह देखते हुए कि इसके डेवलपर्स का एक महत्वपूर्ण हिस्सा Google में काम करता है, आपको बस यह मान लेना चाहिए कि वे आपसे बेहतर जानते हैं

मुझे संदेह है कि आप Google पर उस तरह का तर्क दे सकते हैं।

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

@ सिरकोन वही आपके लिए जाता है। एड-होमिनम और सामाजिक तर्क उपयोगी नहीं हैं। यह एक सीओसी समस्या से कहीं अधिक है। मैंने देखा है कि इस तरह के "सामाजिक तर्क" अक्सर मुख्य भाषा के बारे में होते हैं: संकलक देव बेहतर जानते हैं, भाषा डिजाइनर बेहतर जानते हैं, Google लोग बेहतर जानते हैं।

नहीं, वे नहीं करते। कोई बौद्धिक अधिकार नहीं है। सिर्फ निर्णय प्राधिकरण है। इससे छुटकारा मिले।

बातचीत को रीसेट करने के लिए कुछ टिप्पणियों को छिपाना (और इसे वापस पटरी पर लाने की कोशिश के लिए @agnivade को धन्यवाद)।

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

कृपया मुझे इस चर्चा में अपने 2-सेंट जोड़ने की अनुमति दें:

हमें विभिन्न प्रकारों को उनके विधि सेट (इंटरफ़ेस के साथ) के अलावा अन्य सुविधाओं द्वारा एक साथ समूहित करने का एक तरीका चाहिए। एक नई ग्रुपिंग सुविधा में आदिम (या बुनियादी) प्रकार शामिल होने चाहिए, जिनमें कोई विधि नहीं है, और इंटरफ़ेस प्रकारों को प्रासंगिक रूप से समान के रूप में वर्गीकृत किया जाना चाहिए। हम आदिम प्रकार (बूलियन, न्यूमेरिक, स्ट्रिंग, और यहां तक ​​​​कि [] बाइट, [] int, आदि) को वैसे ही रख सकते हैं, लेकिन उन प्रकारों के बीच अंतर से दूर करने में सक्षम होते हैं जहां एक प्रकार की परिभाषा उन्हें एक परिवार में समूहित करती है।

मेरा सुझाव है कि हम भाषा में एक प्रकार _family_ निर्माण की तरह कुछ जोड़ें।

वाक्य रचना

एक प्रकार के परिवार को किसी अन्य प्रकार की तरह ही परिभाषित किया जा सकता है:

type theFamilyName family {
    someType
    anotherType
}

औपचारिक वाक्यविन्यास कुछ ऐसा होगा:
FamilyType = "family" "{" { TypeName ";" } "}" .

एक प्रकार के परिवार को फ़ंक्शन हस्ताक्षर के अंदर परिभाषित किया जा सकता है:

func Display(s family{string; fmt.Stringer}) { /* function body */ }

यही है, एक-पंक्ति परिभाषा के लिए प्रकार के नामों के बीच अर्धविराम की आवश्यकता होती है।

परिवार के प्रकार का शून्य मान शून्य है, जैसे शून्य इंटरफ़ेस के साथ।

(हुड के तहत पारिवारिक अमूर्तता के पीछे बैठे एक मूल्य को एक इंटरफेस की तरह लागू किया जाता है।)

तर्क

हमें खाली इंटरफ़ेस की तुलना में कुछ अधिक सटीक चाहिए जहां हम यह निर्दिष्ट करना चाहते हैं कि किसी फ़ंक्शन के तर्क के रूप में या फ़ंक्शन के रिटर्न के रूप में कौन से प्रकार मान्य हैं।

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

मुद्दा यह है कि _Go कोड अधिक स्व-दस्तावेजीकरण_ होना चाहिए। तर्क के रूप में कोई फ़ंक्शन क्या ले सकता है, कोड में ही बनाया जाना चाहिए।

बहुत अधिक कोड गलत तरीके से इस तथ्य का फायदा उठाते हैं कि "इंटरफ़ेस {} कुछ नहीं कहता है।" यह थोड़ा शर्मनाक है कि गो में इस तरह का व्यापक रूप से इस्तेमाल किया गया (और दुर्व्यवहार) निर्माण, जिसके बिना हम बहुत कुछ नहीं कर पाएंगे, _Nothing_ कहते हैं।

कुछ उदाहरण

sql.Rows.Scan फ़ंक्शन के दस्तावेज़ में एक बड़ा ब्लॉक शामिल है जो यह बताता है कि फ़ंक्शन में किस प्रकार को पारित किया जा सकता है:

Scan converts columns read from the database into the following common Go types and special types provided by the sql package:
 *string
 *[]byte
 *int, *int8, *int16, *int32, *int64
 *uint, *uint8, *uint16, *uint32, *uint64
 *bool
 *float32, *float64
 *interface{}
 *RawBytes
 any type implementing Scanner (see Scanner docs)

और sql.Row.Scan फ़ंक्शन के लिए दस्तावेज़ में "पंक्तियों पर दस्तावेज़ देखें। विवरण के लिए स्कैन करें" वाक्य शामिल है। विवरण के लिए _some अन्य function_ के लिए दस्तावेज़ देखें? यह गो-जैसी नहीं है—और इस मामले में यह वाक्य सही नहीं है क्योंकि वास्तव में Rows.Scan *RawBytes मान ले सकता है लेकिन Row.Scan नहीं कर सकता।

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

जब किसी फ़ंक्शन के लिए दस्तावेज़ कहते हैं कि फ़ंक्शन किसी अन्य फ़ंक्शन की तरह काम करता है- "तो उस अन्य फ़ंक्शन के लिए दस्तावेज़ देखें" - आप लगभग गारंटी दे सकते हैं कि फ़ंक्शन का कभी-कभी दुरुपयोग किया जाएगा। मैं शर्त लगा सकता हूँ कि ज्यादातर लोगों को, अपने आप की तरह, सिर्फ बाहर पाया है कि एक *RawBytes में एक तर्क के रूप की अनुमति नहीं है Row.Scan केवल से एक त्रुटि प्राप्त करने के बाद Row.Scan ( कह रहा है "एसक्यूएल: रो पर रॉबाइट्स की अनुमति नहीं है। स्कैन")। यह दुख की बात है कि टाइप सिस्टम ऐसी गलतियों की अनुमति देता है।

इसके बजाय हमारे पास हो सकता है:

type Value family {
    *string
    *[]byte
    *int; *int8; *int16; *int32; *int64
    *uint; *uint8; *uint16; *uint32; *uint64
    *bool
    *float32; *float64
    *interface{}
    *RawBytes
    Scanner
}

इस तरह, पास किया गया मान दिए गए परिवार के प्रकारों में से एक होना चाहिए, और Rows.Scan फ़ंक्शन के अंदर प्रकार स्विच को किसी भी अप्रत्याशित या डिफ़ॉल्ट मामलों से निपटने की आवश्यकता नहीं होगी; Row.Scan समारोह के लिए एक और परिवार होगा।

इस बात पर भी विचार करें कि कैसे cloud.google.com/go/datastore.Property संरचना में interface{} प्रकार का "मान" फ़ील्ड है और इस सभी दस्तावेज़ीकरण की आवश्यकता है:

// Value is the property value. The valid types are:
// - int64
// - bool
// - string
// - float64
// - *Key
// - time.Time
// - GeoPoint
// - []byte (up to 1 megabyte in length)
// - *Entity (representing a nested struct)
// Value can also be:
// - []interface{} where each element is one of the above types
// This set is smaller than the set of valid struct field types that the
// datastore can load and save. A Value's type must be explicitly on
// the list above; it is not sufficient for the underlying type to be
// on that list. For example, a Value of "type myInt64 int64" is
// invalid. Smaller-width integers and floats are also invalid. Again,
// this is more restrictive than the set of valid struct field types.
//
// A Value will have an opaque type when loading entities from an index,
// such as via a projection query. Load entities into a struct instead
// of a PropertyLoadSaver when using a projection query.
//
// A Value may also be the nil interface value; this is equivalent to
// Python's None but not directly representable by a Go struct. Loading
// a nil-valued property into a struct will set that field to the zero
// value.

यह हो सकता है:

type PropertyVal family {
  int64
  bool
  string
  float64
  *Key
  time.Time
  GeoPoint
  []byte
  *Entity
  nil
  []int64; []bool; []string; []float64; []*Key; []time.Time; []GeoPoint; [][]byte; []*Entity
}

(आप कल्पना कर सकते हैं कि इसे कैसे साफ-सुथरे दो परिवारों में विभाजित किया जा सकता है।)

json.Token प्रकार का उल्लेख ऊपर किया गया था। इसकी प्रकार परिभाषा होगी:

type Token family {
    Delim
    bool
    float64
    Number
    string
    nil
}

एक और उदाहरण जो मुझे हाल ही में मिला है:
कॉल करते समय sql.DB.Exec , या sql.DB.Query , या कोई भी फ़ंक्शन जो interface{} एक विविध सूची लेता है जहां प्रत्येक तत्व को एक विशेष सेट में एक प्रकार होना चाहिए और स्वयं नहीं होना चाहिए एक स्लाइस_, ऐसे फ़ंक्शन में []interface{} से तर्कों में गुजरते समय "स्प्रेड" ऑपरेटर का उपयोग करना याद रखना महत्वपूर्ण है: यह कहना गलत है DB.Exec("some query with placeholders", emptyInterfaceSlice) ; सही तरीका है: DB.Exec("the query...", emptyInterfaceSlice...) जहां emptyInterfaceSlice का प्रकार []interface{} । ऐसी गलतियों को असंभव बनाने का एक शानदार तरीका यह होगा कि इस फ़ंक्शन को Value का एक भिन्न तर्क दिया जाए, जहां Value को ऊपर वर्णित परिवार के रूप में परिभाषित किया गया है।

इन उदाहरणों की बात यह है कि interface{} की अशुद्धि के कारण _असली गलतियां की जा रही हैं_।

var x int | float64 | string | rune
z = int(x) + int(y)
z = float64(x) + float64(y)

यह निश्चित रूप से एक कंपाइलर त्रुटि होनी चाहिए क्योंकि x का प्रकार वास्तव में संगत नहीं है जिसे पास किया जा सकता है int() ।

मुझे family होने का विचार पसंद है। यह अनिवार्य रूप सूचीबद्ध प्रकार के लिए एक इंटरफेस विवश (constricted?) होगा और संकलक हर समय के खिलाफ आप कर रहे हैं मिलान सुनिश्चित करने और इसी के स्थानीय संदर्भ में चर के प्रकार में परिवर्तन कर सकते हैं case ।

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

वास्तव में यही कारण है कि मैं कुछ चीजों को नापसंद करने लगा जैसे

func foo() (..., error) 

क्योंकि आपको पता नहीं है कि यह किस प्रकार की त्रुटि देता है।

और कुछ अन्य चीजें जो एक ठोस प्रकार के बजाय एक इंटरफ़ेस लौटाती हैं। कुछ कार्य
वापसी net.Addr और कभी-कभी यह पता लगाने के लिए स्रोत कोड के माध्यम से खोदना थोड़ा मुश्किल होता है कि यह वास्तव में किस प्रकार का net.Addr लौटाता है और फिर इसे उचित रूप से उपयोग करता है। एक ठोस प्रकार को वापस करने में वास्तव में बहुत अधिक नकारात्मकता नहीं है (क्योंकि यह इंटरफ़ेस लागू करता है और इस प्रकार कहीं भी उपयोग किया जा सकता है जहां इंटरफ़ेस का उपयोग किया जा सकता है) सिवाय इसके कि जब आप
बाद में एक अलग प्रकार की net.Addr वापस करने के लिए अपनी विधि का विस्तार करने की योजना बनाएं। लेकिन अगर आपका
एपीआई का उल्लेख है कि यह OpError लौटाता है तो क्यों न "संकलन समय" युक्ति का वह हिस्सा बनाया जाए?

उदाहरण के लिए:

 OpError is the error type usually returned by functions in the net package. It describes the operation, network type, and address of an error. 

आमतौर पर? आपको बिल्कुल नहीं बताता कि कौन से फ़ंक्शन इस त्रुटि को वापस करते हैं। और यह प्रकार के लिए दस्तावेज़ीकरण है, फ़ंक्शन नहीं। Read दस्तावेज़ में कहीं भी उल्लेख नहीं है कि यह OpError देता है। इसके अलावा, यदि आप करते हैं

err := blabla.(*OpError)

एक अलग प्रकार की त्रुटि लौटाने के बाद यह क्रैश हो जाएगा। इसलिए मैं वास्तव में इसे फ़ंक्शन घोषणा के हिस्से के रूप में देखना चाहता हूं। कम से कम *OpError | error आपको बताएगा कि यह वापस आ गया है
ऐसी त्रुटि और संकलक सुनिश्चित करता है कि आप भविष्य में अपने प्रोग्राम को क्रैश करने वाला एक अनियंत्रित प्रकार का दावा नहीं करते हैं।

BTW: क्या हास्केल के प्रकार के बहुरूपता जैसी प्रणाली पर अभी तक विचार किया गया था? या एक 'विशेषता' आधारित प्रकार प्रणाली अर्थात:

func calc(a < add(a, a) a >, b a) a {
   return add(a, b)
}

func drawWidgets(widgets []< widgets.draw() error >) error {
  for _, widgets := range widgets {
    err := widgets.draw()
    if err != nil {
      return err
    }
  }
  return nil
}

a < add(a, a) a अर्थ है "जो कुछ भी एक प्रकार है, वहां एक फ़ंक्शन ऐड (टाइपऑफ ए, टाइपऑफ ए) टाइपऑफ ए) मौजूद होना चाहिए"। < widgets.draw() error> अर्थ है कि "जो भी विजेट का प्रकार है, उसे एक विधि ड्रा प्रदान करना चाहिए जो एक त्रुटि देता है"। यह अधिक सामान्य कार्यों को बनाने की अनुमति देगा:

func Sum(a []< add(a,a) a >) a {
  sum := a[0]
  for i := 1; i < len(a); i++ {
    sum = add(sum,a[i])
  }
  return sum
}

(ध्यान दें कि यह पारंपरिक "जेनेरिक" के बराबर नहीं है)।

एक ठोस प्रकार को वापस करने में वास्तव में बहुत अधिक नकारात्मकता नहीं है (क्योंकि यह इंटरफ़ेस को लागू करता है और इस प्रकार कहीं भी उपयोग किया जा सकता है जहां इंटरफ़ेस का उपयोग किया जा सकता है) सिवाय इसके कि जब आप बाद में एक अलग तरह के net.Addr को वापस करने के लिए अपनी विधि का विस्तार करने की योजना बनाते हैं। .

इसके अलावा, जाओ, संस्करण subtyping नहीं है तो आप उपयोग नहीं कर सकते एक func() *FooError के रूप में एक func() error जहां की जरूरत है। जो इंटरफेस संतुष्टि के लिए विशेष रूप से महत्वपूर्ण है। और अंत में, यह संकलित नहीं करता है:

func Foo() (FooVal, FooError) {
    // ...
}

func Bar(f FooVal) (BarVal, BarError) {
    // ...
}

func main() {
    foo, err := Foo()
    if err != nil {
        log.Fatal(err)
    }
    bar, err := Bar(foo) // Type error: Can not assign BarError to err (type FooError)
    if err != nil {
        log.Fatal(err)
    }
}

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

साथ ही, गो के पास वैरिएंट सबटाइपिंग नहीं है, इसलिए आप func() *FooError को func() त्रुटि के रूप में जहां आवश्यक हो, उपयोग नहीं कर सकते। जो इंटरफेस संतुष्टि के लिए विशेष रूप से महत्वपूर्ण है। और अंत में, यह संकलित नहीं करता है:

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

func main() {
    foo, err := Foo()
    if err != nil {
        log.Fatal(err)
    }
    bar, err := Bar(foo) // Type error: Can not assign BarError to err (type FooError)
    if err != nil {
        log.Fatal(err)
    }
}

मुझे ऐसी किसी भी भाषा के बारे में पता नहीं है जो इसकी अनुमति देती है (ठीक है, एसोलंग्स को छोड़कर) लेकिन आपको बस एक "टाइप वर्ल्ड" रखना होगा (जो मूल रूप से variable -> type का नक्शा है) और यदि आप फिर से - वेरिएबल को असाइन करें जिसे आप "टाइप वर्ल्ड" में अपना प्रकार अपडेट करते हैं।

मुझे नहीं लगता कि आपको ऐसा करने के लिए जटिल प्रकार के अनुमान की आवश्यकता है, लेकिन आपको चर के प्रकारों पर नज़र रखने की आवश्यकता है, लेकिन मुझे लगता है कि आपको वैसे भी ऐसा करने की आवश्यकता है क्योंकि

var int i = 0;
i = "hi";

आपको निश्चित रूप से किसी भी तरह याद रखना होगा कि कौन से चर/घोषणाएं किस प्रकार हैं और i = "hi" आपको यह जांचने के लिए i पर "टाइप लुकअप" बनाने की आवश्यकता है कि आप इसे एक स्ट्रिंग असाइन कर सकते हैं या नहीं।

क्या ऐसे व्यावहारिक मुद्दे हैं जो func () *ConcreteError को func() error को असाइन करने को जटिल बनाते हैं, इसके अलावा टाइप चेकर इसका समर्थन नहीं कर रहा है (जैसे रनटाइम कारण/संकलित कोड कारण)? मुझे लगता है कि वर्तमान में आपको इसे इस तरह के फ़ंक्शन में लपेटना होगा:

type MyFunc func() error

type A struct {
}

func (_ *A) Error() string { return "" }

func NewA() *A {
    return &A{}
}

func main() {
    var err error = &A{}
    fmt.Println(err.Error())
    var mf MyFunc = MyFunc(func() error { return NewA() }) // type checks fine
        //var mf MyFunc = MyFunc(NewA) // doesn't type check
    _ = mf
}

यदि आप func (a, b) c सामना कर रहे हैं, लेकिन एक func (x, y) z प्राप्त करें, तो केवल यह जांचना है कि z c (और a , b को x , y को असाइन करने योग्य होना चाहिए) जिसमें कम से कम प्रकार के स्तर पर जटिल प्रकार का अनुमान शामिल नहीं है (इसमें केवल यह जांचना शामिल है कि क्या एक प्रकार असाइन करने योग्य/दूसरे प्रकार के साथ/संगत है)। बेशक, क्या यह रनटाइम/संकलन के साथ मुद्दों का कारण बनता है ... मुझे नहीं पता लेकिन कम से कम सख्ती से प्रकार के स्तर को देखकर मुझे नहीं लगता कि इसमें जटिल प्रकार का अनुमान क्यों शामिल होगा। टाइप चेकर पहले से ही जानता है कि x को a को सौंपा जा सकता है या नहीं, इस प्रकार यह भी आसानी से जानता है कि func () x को func () a को सौंपा जा सकता है या नहीं। बेशक, व्यावहारिक कारण हो सकते हैं (रनटाइम अभ्यावेदन के बारे में सोचना) यह आसानी से संभव क्यों नहीं होगा। (मुझे संदेह है कि यहां असली क्रूक्स है, वास्तविक प्रकार की जांच नहीं)।

सैद्धांतिक रूप से आप _संभावित रूप से विशाल_ डाउनसाइड के साथ स्वचालित रूप से रैपिंग फ़ंक्शंस (जैसे उपरोक्त स्निपेट में) के साथ रनटाइम मुद्दों (यदि वहां हैं) को हल कर सकते हैं कि यह funcs के साथ funcs की तुलना को खराब कर देता है (क्योंकि लपेटा func func के बराबर नहीं होगा लपेटता है)।

मुझे ऐसी किसी भी भाषा के बारे में पता नहीं है जो इसकी अनुमति देती है (ठीक है, एसोलंग्स को छोड़कर)

बिल्कुल नहीं, लेकिन मैं तर्क दूंगा कि शक्तिशाली प्रकार की प्रणालियों वाली भाषाएं आमतौर पर कार्यात्मक भाषाएं होती हैं जो वास्तव में चर का उपयोग नहीं करती हैं (और इसलिए वास्तव में पहचानकर्ताओं का पुन: उपयोग करने की क्षमता की आवश्यकता नहीं होती है)। एफडब्ल्यूआईडब्ल्यू, मैं तर्क दूंगा कि उदाहरण के लिए हास्केल की प्रकार प्रणाली इससे ठीक से निपटने में सक्षम होगी - कम से कम जब तक आप FooError या BarError किसी अन्य गुण का उपयोग नहीं कर रहे हैं, इसे चाहिए यह अनुमान लगाने में सक्षम हो कि err error और इससे निपटें। बेशक, फिर से, यह एक काल्पनिक है, क्योंकि यह सटीक स्थिति आसानी से एक कार्यात्मक भाषा में स्थानांतरित नहीं होती है।

लेकिन मुझे लगता है कि आपको वैसे भी ऐसा करने की ज़रूरत है क्योंकि

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

क्या ऐसे व्यावहारिक मुद्दे हैं जो func () *ConcreteError को func() error को असाइन करने को जटिल बनाते हैं, इसके अलावा टाइप चेकर इसका समर्थन नहीं कर रहा है (जैसे रनटाइम कारण/संकलित कोड कारण)?

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

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

funcs तुलनीय नहीं हैं।

वैसे भी, टीबीएच, यह सब इस मुद्दे के लिए थोड़ा सा विषय लगता है :)

एफवाईआई: मैंने अभी यह किया है । यह अच्छा नहीं है, लेकिन यह निश्चित रूप से टाइप-सुरक्षित है। (# 19814 एफडब्ल्यूआईडब्ल्यू के लिए भी यही किया जा सकता है)

मुझे पार्टी में थोड़ी देर हो गई है, लेकिन मैं भी गो के 4 साल बाद अपनी भावनाओं को आपके साथ साझा करना चाहता हूं:

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

उन पिछले 4 वर्षों में मुझे इससे जुड़ी कई समस्याएं मिली हैं:

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

हालांकि, उन सभी मुद्दों को ठीक करने के लिए आवश्यक परिवर्तनों के लिए वास्तव में पिछड़े असंगत गो 2.0.0 (गो 2 नहीं) संस्करण की आवश्यकता होगी, जिसे कभी भी महसूस नहीं किया जाएगा, मुझे लगता है। वैसे भी...

त्रुटि प्रबंधन इस तरह दिखना चाहिए था:

// Divide returns either a float64 or an arbitrary error
func Divide(dividend, divisor float64) float64 | error {
  if dividend == 0 {
    return errors.New("dividend is zero")
  }
  if divisor == 0 {
    return errors.New("divisor is zero")
  }
  return dividend / divisor
}

func main() {
  // type-switch statements enforce completeness:
  switch v := Divide(1, 0).(type) {
  case float64:
    log.Print("1/0 = ", v)
  case error:
    log.Print("1/0 = error: ", v)
  }

  // type-assertions, however, do not:
  divisionResult := Divide(3, 1)
  if v, ok := divisionResult.(float64); ok {
    log.Print("3/1 = ", v)
  }
  if v, ok := divisionResult.(error); ok {
    log.Print("3/1 = error: ", v.Error())
  }
  // yet they don't allow asserting types not included in the union:
  if v, ok := divisionResult.(string); ok { // compile-time error!
    log.Print("3/1 = string: ", v)
  }
}

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

बहुत बार मैंने लोगों को _non-nil इंटरफेस से nil value_ : https://play.golang.org/p/JzigZ2Q6E6F के बारे में पूरी तरह से भ्रमित होते देखा है । आम तौर पर, लोग भ्रमित हो जाते हैं जब एक error इंटरफ़ेस एक कस्टम त्रुटि प्रकार के सूचक को इंगित कर रहा है जो इंगित कर रहा है nil , यही कारण है कि मुझे लगता है कि इंटरफेस को शून्य-सक्षम बनाना एक गलती थी।

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

भेदभावपूर्ण यूनियनों को वैकल्पिक (शायद-प्रकार) के लिए इस्तेमाल किया जाना चाहिए था और इंटरफेस के लिए nil पॉइंटर्स पास करने से घबराहट होनी चाहिए थी:

type CustomErr struct {}
func (err *CustomErr) Error() string { return "custom error" }

func CouldFail(foo int) error | nil {
  var err *customErr
  if foo > 10 {
    // you can't return a nil pointer as an interface value
    return err // this will panic!
  }
  // no error
  return nil
}

func main() {
  // assume no error
  if err, ok := CouldFail().(error); ok {
    log.Fatalf("it failed, Jim! %s", err)
  }
}

पॉइंटर्स और शायद-प्रकार विनिमेय नहीं हैं। वैकल्पिक प्रकारों के लिए पॉइंटर्स का उपयोग करना खराब है क्योंकि यह भ्रमित करने वाले एपीआई की ओर जाता है:

// P returns a pointer to T, but it's not clear whether or not the pointer
// will always reference a T instance. It might be an optional T,
// but the documentation usually doesn't tell you.
func P() *T {}

// O returns either a pointer to T or nothing, this implies (but still doesn't guarantee)
// that the pointer is always expected to not be nil, in any other case nil is returned.
func O() *T | nil {}

फिर JSON भी है। यह यूनियनों के साथ कभी नहीं हो सकता है क्योंकि संकलक आपको उपयोग करने से पहले उन्हें जांचने के लिए मजबूर करता है । यदि आवश्यक फ़ील्ड (सूचक प्रकार के फ़ील्ड सहित) JSON दस्तावेज़ में शामिल नहीं है, तो JSON unmarshaller विफल हो जाना चाहिए:

type DataModel struct {
  // Optional needs to be type-checked before use
  // and is therefore allowed to no be included in the JSON document
  Optional string | nil `json:"optional,omitempty"`
  // Required won't ever be nil
  // If the JSON document doesn't include it then unmarshalling will return an error
  Required *T `json:"required"`
}

पी.एस.
मैं इस समय एक कार्यात्मक भाषा डिजाइन पर भी काम कर रहा हूं और इस तरह मैं वहां त्रुटि प्रबंधन के लिए भेदभावपूर्ण यूनियनों का उपयोग करता हूं:

read = (s String) -> (Array<Byte> or Error) => match s {
  "A" then Error<NotFound>
  "B" then Error<AccessDenied>
  "C" then Error<MemoryLimitExceeded>
  else Array<Byte>("this is fine")
}

main = () -> ?Error => {
  // assume the result is a byte array
  // otherwise throw the error up the stack wrapped in a "type-assertion-failure" error
  r = read("D") as Array<Byte>
  log::print("data: %s", r)
}

मैं इसे एक दिन सच होते देखना पसंद करूंगा। तो आइए देखें कि क्या मैं थोड़ी मदद कर सकता हूं:

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

मेरे दृष्टिकोण से, यह सरलीकृत संस्करण केवल nil से संबंधित होगा । यहां मुख्य विचार दिए गए हैं (उनमें से लगभग सभी का पहले ही टिप्पणियों में उल्लेख किया जा चुका है):

1. केवल अनुमति दें | "भेदभाव वाली यूनियनों" का
   <any pointer type> | nil
   जहां कोई भी सूचक प्रकार होगा: पॉइंटर्स, फ़ंक्शंस, चैनल, स्लाइस और मैप्स (गो पॉइंटर प्रकार)
2. एक नंगे सूचक प्रकार के लिए nil असाइन करने से मना करें। यदि आप शून्य असाइन करना चाहते हैं, तो प्रकार <pointer type> | nil । उदाहरण के लिए:

var n *int       = nil // Does not compile, wrong type
var n *int | nil = nil // Ok!

var set map[string] bool       = nil // Does not compile
var set map[string] bool | nil = nil // Ok!

var myFunc func(int) err       = nil // Nope!
var myFunc func(int) err | nil = nil // All right.

वे मुख्य विचार हैं। निम्नलिखित मुख्य विचारों से व्युत्पन्न विचार हैं:

1. आप एक नंगे सूचक प्रकार के एक चर की घोषणा नहीं कर सकते हैं और इसे अप्रारंभीकृत छोड़ सकते हैं। यदि आप ऐसा करना चाहते हैं, तो आपको | nil विभेदित प्रकार जोड़ना होगा

var maybeAString *string       // Wrong: invalid initial value
var maybeAString *string | nil // Good

1. आप एक "शून्य" सूचक प्रकार के लिए एक नंगे सूचक प्रकार असाइन कर सकते हैं, लेकिन दूसरी तरफ नहीं:

var value int = 42
var barePointer *int = &value          // Valid
var nilablePointer *int | nil = &value // Valid

nilablePointer = barePointer // Valid
barePointer = nilablePointer // Invalid: Incompatible types

1. "शून्य" सूचक प्रकार से मूल्य प्राप्त करने का एकमात्र तरीका प्रकार स्विच के माध्यम से होता है, जैसा कि अन्य ने इंगित किया है। उदाहरण के लिए, उपरोक्त उदाहरण का अनुसरण करते हुए, यदि हम वास्तव में nilablePointer से barePointer का मान निर्दिष्ट करना चाहते हैं, तो हमें यह करने की आवश्यकता होगी:

switch val := nilablePointer.(type) {
  case *int:
    barePointer = val // Yeah! Types are compatible now. It is imposible that "val = nil"
  case nil:
    // Do what you need to do when nilablePointer is nil
}

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

• ए) कोई शून्य सूचक त्रुटियां नहीं । ठीक है, कभी भी 4 शब्दों का इतना मतलब नहीं था। इसलिए मुझे इसे दूसरे दृष्टिकोण से कहने की आवश्यकता महसूस होती है: नो गो प्रोग्राम में _EVER_ को फिर से nil pointer dereference त्रुटि होगी! मैं
• बी) आप "प्रदर्शन बनाम इरादा" व्यापार किए बिना पॉइंटर्स को फ़ंक्शन पैरामीटर में पास कर सकते हैं।
  इसके साथ मेरा मतलब यह है कि कुछ समय होते हैं जब मैं किसी फ़ंक्शन को एक स्ट्रक्चर पास करना चाहता हूं, न कि इसके लिए पॉइंटर, क्योंकि मैं नहीं चाहता कि वह फ़ंक्शन शून्यता के बारे में चिंतित हो और इसे पैरामीटर की जांच करने के लिए मजबूर करे . हालांकि, मैं आम तौर पर प्रतिलिपि ओवरहेड से बचने के लिए एक पॉइंटर पास कर देता हूं।
• ग) कोई और शून्य मानचित्र नहीं! हां! हम "सुरक्षित शून्य-स्लाइस" और "असुरक्षित शून्य-मानचित्र" के बारे में असंगति के साथ समाप्त करेंगे (यदि आप उन्हें लिखने का प्रयास करेंगे तो घबराहट होगी)। एक नक्शा या तो प्रारंभ किया जाएगा या map | nil प्रकार का होगा, इस स्थिति में आपको एक प्रकार के स्विच का उपयोग करने की आवश्यकता होगी

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

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

एक समस्या यह है कि प्रस्ताव का यह सरल संस्करण भी पिछड़ा असंगत है, लेकिन इसे आसानी से gofix द्वारा ठीक किया जा सकता है: बस सभी सूचक प्रकार की घोषणाओं को <pointer type> | nil बदलें।

तुम क्या सोचते हो? मुझे आशा है कि यह कुछ प्रकाश डाल सकता है और भाषा में शून्य-सुरक्षा को शामिल करने में तेजी ला सकता है। ऐसा लगता है कि इस तरह ("भेदभावपूर्ण यूनियनों के माध्यम से") इसे प्राप्त करने का सरल और अधिक ऑर्थोगोनल तरीका है।

@alvaroloes

आप एक नंगे सूचक प्रकार के एक चर की घोषणा नहीं कर सकते हैं और इसे अप्रारंभीकृत छोड़ दिया है।

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

दूसरे शब्दों में: आपका प्रस्ताव वास्तव में इतना आसान नहीं है, क्योंकि यह गो भाषा में एक सुंदर मौलिक डिजाइन निर्णय से काफी महत्वपूर्ण रूप से विचलित होता है।

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

उपरोक्त प्रस्ताव स्विफ्ट और अन्य की तरह वैकल्पिक/गैर-वैकल्पिक प्रकार की तरह दिखता है। यह अच्छा है और सभी लेकिन:

1. इससे वहां हर कार्यक्रम काफी टूट जाएगा और फिक्स गोफिक्स के लिए छोटा नहीं होगा। आप प्रस्ताव के अनुसार हर चीज को <pointer type> | nil प्रतिस्थापित नहीं कर सकते, इसके लिए मूल्य को अनपैक करने के लिए टाइप स्विच की आवश्यकता होगी।
2. इसके लिए वास्तव में प्रयोग करने योग्य और सहने योग्य होने के लिए गो को इन वैकल्पिक विकल्पों के आसपास बहुत अधिक वाक्यात्मक चीनी की आवश्यकता होगी। उदाहरण के लिए, स्विफ्ट को लें। विशेष रूप से वैकल्पिक के साथ काम करने के लिए भाषा में कई विशेषताएं हैं - गार्ड, वैकल्पिक बाध्यकारी, वैकल्पिक चेनिंग, शून्य कोलेसिंग इत्यादि। मुझे नहीं लगता कि गो उस दिशा में जायेगा लेकिन उनके बिना वैकल्पिक के साथ काम करना एक घर का काम होगा।

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

ऊपर देखो। इसका मतलब है कि कुछ चीजें जो सस्ती दिखती हैं, उनके साथ बहुत ही गैर-तुच्छ लागतें जुड़ी होती हैं।

इस संबंध में गो को बदलना फायदेमंद रहेगा

इसके फायदे हैं, लेकिन यह फायदेमंद होने के समान नहीं है। इसके नुकसान भी हैं। जिसका वजन भारी होता है वह वरीयता और ट्रेडऑफ पर निर्भर करता है। गो डिजाइनरों ने इसे चुना।

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

आह! मुझे पता था कि कुछ स्पष्ट था जो मुझे याद आ रहा था। दोह! "सरल" शब्द के जटिल अर्थ हैं। ठीक है, मेरी पिछली टिप्पणी से "सरल" शब्द को हटाने के लिए स्वतंत्र महसूस करें।

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

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

अगर मुझे सही से याद है, तो किसी भी प्रकार के शून्य मान में इसकी मेमोरी स्पेस को 0 से भरना होता है।
जैसा कि आप पहले से ही जानते हैं, यह गैर-सूचक प्रकारों के लिए ठीक है, लेकिन यह सूचक प्रकारों के लिए बग का एक स्रोत है:

type S struct {
    n int
}
var s S 
s.n  // Fine

var s *S
s.n // runtime error

var f func(int)
f() // runtime error

तो क्या हुआ अगर हम:

• प्रत्येक सूचक प्रकार के लिए उपयोगी शून्य मान परिभाषित करें
• इसे केवल पहली बार उपयोग किए जाने पर प्रारंभ करें (आलसी प्रारंभ)।

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

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

| सूचक प्रकार | शून्य मान | गतिशील शून्य मान | टिप्पणी |
| --- | --- | --- | --- |
| *टी | nil | नया (टी) |
| []टी | nil | []टी{} |
| नक्शा [टी] यू | nil | नक्शा[टी]यू{} |
| func | nil | नोप | तो किसी फ़ंक्शन का गतिशील शून्य मान कुछ नहीं करता है और शून्य मान देता है। यदि वापसी मान सूची समाप्त हो जाती है error , तो एक डिफ़ॉल्ट त्रुटि यह कहते हुए लौटा दी जाती है कि फ़ंक्शन "कोई ऑपरेशन नहीं" है |
| chan T | nil | मेक (चान टी) |
| interface | nil | - | एक डिफ़ॉल्ट कार्यान्वयन जहां ऊपर वर्णित noop फ़ंक्शन के साथ सभी विधियों को प्रारंभ किया जाता है |
| भेदभावपूर्ण संघ | nil | पहले प्रकार का गतिशील शून्य मान | |

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

type S struct {
    n int
}
var s *S
if s == nil { // true. Nothing different happens here
...
}
s.n = 1       // At this moment the go runtime would check if it is nil, and if it is, 
              // do "s = new(S)". We could say the code would be replaced by:
/*
if s == nil {
    s = new(S)
}
s.n = 1
*/

// -------------
var pointers []*S = make([]*S, 100) // Everything as usual
for _,p := range pointers {
    p.n = 1 // This is translated to:
    /*
        if p == nil {
            p = new(S)
        }
        p.n = 1
    */
}

// ------------
type I interface {
    Add(string) (int, error)
}

var i I
n, err := i.Add("yup!") // This method returns 0, and the default error "Noop"
if err != nil { // This condition is true and the error is returned
    return err
}

मैं शायद कार्यान्वयन विवरण और संभावित कठिनाइयों को याद कर रहा हूं, लेकिन मैं पहले विचार पर ध्यान केंद्रित करना चाहता था।

मुख्य दोष यह है कि हर बार जब आप किसी सूचक प्रकार के मान तक पहुँचते हैं तो हम एक अतिरिक्त शून्य-चेक ​​जोड़ते हैं। लेकिन मैं कहूंगा:

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

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

तुम क्या सोचते हो? क्षमा करें यदि इस पर पहले ही चर्चा हो चुकी है। साथ ही, मुझे पता है कि यह टिप्पणी-प्रस्ताव भेदभावपूर्ण यूनियनों की तुलना में nil से अधिक संबंधित है। मैं इसे शून्य से संबंधित मुद्दे पर ले जा सकता हूं, लेकिन जैसा कि मैंने कहा, मैंने इसे यहां पोस्ट किया क्योंकि यह भेदभावपूर्ण यूनियनों की मुख्य समस्या को ठीक करने का प्रयास करता है: उपयोगी शून्य मान।

वापस मामले पर: तो ऐसा लगता है कि इसे वापस रखने का मुख्य कारण शून्य मान है।

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

तो क्या हुआ अगर हम:

• प्रत्येक सूचक प्रकार के लिए उपयोगी शून्य मान परिभाषित करें
• इसे केवल पहली बार उपयोग किए जाने पर प्रारंभ करें (आलसी प्रारंभ)।

यदि आप एक पॉइंटर प्रकार पास करते हैं तो यह विफल हो जाता है। जैसे

func F(p *T) {
    *p = 42 // same as if p == nil { p = new(T) } *p = 42
}

func G() {
    var p *T
    F(p)
    fmt.Println(p == nil) // Has to be true, as F can't modify p. But now F is silently misbehaving
}

यह चर्चा सब कुछ है लेकिन नई है। ऐसे कारण हैं कि संदर्भ प्रकार वे जिस तरह से व्यवहार करते हैं और ऐसा नहीं है कि गो डेवलपर्स ने इसके बारे में नहीं सोचा है :)

यही इस मामले कि जड़ है। यह सिर्फ एक चीज नहीं है जो गो करता है - हर प्रकार का शून्य मान होता है, पूर्ण विराम। अन्यथा आपको जवाब देना होगा, उदाहरण के लिए मेक ([] टी, 100) क्या करता है?

यह (और new(T) ) को अस्वीकृत करना होगा यदि T मान शून्य नहीं है। आपको make([]T, 0, 100) और फिर स्लाइस को पॉप्युलेट करने के लिए append करना होगा। बड़ा आकार बदलना ( v[:0][:100] ) भी एक त्रुटि होगी। [10]T मूल रूप से एक असंभव प्रकार होगा (जब तक कि किसी सरणी सूचक में एक स्लाइस को मुखर करने की क्षमता भाषा में नहीं जोड़ी जाती)। और पीछे की संगतता बनाए रखने के लिए आपको मौजूदा शून्य प्रकारों को गैर-शून्य के रूप में चिह्नित करने का एक तरीका चाहिए।

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

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

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

यदि आप एक पॉइंटर प्रकार पास करते हैं तो यह विफल हो जाता है। जैसे (...)

मुझे यह ठीक से समझ में नहीं आ रहा है। यह विफलता क्यों है? आप फ़ंक्शन पैरामीटर में केवल एक मान पास कर रहे हैं, जो कि nil मान वाला पॉइंटर होता है। फिर आप उस मान को फ़ंक्शन के अंदर संशोधित कर रहे हैं। यह अपेक्षा की जाती है कि आप उन प्रभावों को फ़ंक्शन के बाहर नहीं देखेंगे। मुझे कुछ उदाहरणों पर टिप्पणी करने दें:

// Augmenting your example with more comments:
func FCurrentGo(p *T) {
    // Here "p" is just a value, which happens to be a pointer type. Doing...
    *p = 42
    // ...without checking first for "nil" is the recipe for hiding a bug that will crash the entire program, 
    // which is exactly what is happening in current Go code bases

    // The correct code would be:
    if p == nil {
        // panic or return error
    }
    *p = 42
}

func FWithDynamicZero(p *T) {
    // Here, again, p is just a value of a pointer type. Doing...
    *p = 42
    // would allocate a new T and assign 42. It is true that this doesn't have any effect on the "outside
    // world", which could be considered "incorrect" because you expected the function to do that.
    // If you really want to be sure "p" is pointing to something valid in the "outside world", then
    // check that:
    if p == nil {
        // panic or return error
    }
    *p = 42
}

func main() {
    var p *T
    FCurrentGo(p) // This will crash the program
        FWithDynamicZero(p) // This won't have any effect on "p". This is expected because "p" is not pointing
                            // to anything. No crash here.
    fmt.Println(p == nil) // It is true, as expected
}

गैर-सूचक रिसीवर विधियों के साथ एक समान स्थिति हो रही है, और यह नए आने वालों के लिए भ्रमित करने वाला है (लेकिन एक बार जब आप इसे समझ लेते हैं, तो समझ में आता है):

type Point struct {
    x, y int
}

func (p Point) SetXY(x, y int) {
    p.x = x
    p.y = y
}

func main() {
    p := Point{x: 1, y: 2}
    p.SetXY(24, 42)

    pointerToP := &Point{x: 1, y: 2}
    pointerToP.SetXY(24, 42)

    fmt.Println(p, pointerToP) // Will print "{1 2} &{1 2}", which could confuse at first
}

इसलिए हमें इनमें से किसी एक को चुनना होगा:

• ए) दुर्घटना के साथ विफलता
• बी) एक सूचक द्वारा इंगित मूल्य के एक मूक गैर-संशोधन के साथ विफलता जब उस सूचक को किसी फ़ंक्शन में पास किया जाता है।

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

नोट: मैं "मेरे" विचार का आँख बंद करके बचाव करने की कोशिश नहीं कर रहा हूँ, मैं वास्तव में गो (जो पहले से ही वास्तव में अच्छा है) को बेहतर बनाने की कोशिश कर रहा हूँ। अगर कुछ अन्य बिंदु हैं जो विचार को इसके लायक नहीं बनाते हैं, तो मुझे इसे दूर करने और दूसरी दिशाओं में सोचने की परवाह नहीं है

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

ठीक है, मैं यह समझता हूँ। हमें बस दूसरे लोगों का नजरिया भी देखना है (मैं यह नहीं कह रहा हूं कि आप ऐसा नहीं कर रहे हैं, मैं सिर्फ एक बात कह रहा हूं )

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

यह विफलता क्यों है?

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

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

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

गैर-सूचक रिसीवर विधियों के साथ भी ऐसी ही स्थिति हो रही है

मैं यह सादृश्य नहीं खरीदता। आईएमओ इस पर विचार करना पूरी तरह से उचित है

func Foo(p *int) { *p = 42 }

func main() {
    var v int
    Foo(&v)
    if v != 42 { panic("") }
}

सही कोड होना। मुझे नहीं लगता कि इस पर विचार करना उचित है

func Foo(v int) { v = 42 }

func main( ){
    var v int
    Foo(v)
    if v != 42 { panic("") }
}

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

दोनों मामलों के लिए फिक्स एक ही है: कुछ भी करने से पहले शून्य की जांच करें।

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

// The correct code would be:
if p == nil {
    // panic or return error
}
*p = 42

लेकिन मैं उस कोड को सही नहीं मानता। nil -चेक कुछ भी नहीं करता है, क्योंकि nil संदर्भित करने से पहले से ही घबराहट होती है।

लेकिन, मेरे लिए, ए) बहुत अधिक हानिकारक है (पूरा एप्लिकेशन क्रैश हो जाता है!)।

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

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

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

मैंने लिखा _"... ऐसा लगता है कि मुख्य कारण जो इसे रोक रहा है..."_ आपके वाक्य पर आधारित है_"यह मामला की जड़ है"_ शून्य मान का जिक्र है। इसलिए मैंने यह मान लिया था कि शून्य मान इसे वापस रखने वाली मुख्य बात थी। तो यह मेरी बुरी धारणा थी।

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

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

मैं यह कहने का मुख्य कारण यह है कि आपका वाक्य _"हर प्रकार का शून्य मान है, पूर्ण विराम "_। मैं आमतौर पर "पूर्ण विराम लिखना" पसंद नहीं करता। मुझे गलत मत समझो! मैं पूरी तरह से स्वीकार करता हूं कि आप ऐसा सोचते हैं, यह सिर्फ मेरे सोचने का तरीका है: मुझे कोई हठधर्मिता पसंद नहीं है क्योंकि वे उन रास्तों को छिपा सकते हैं जो बेहतर समाधान की ओर ले जा सकते हैं।

अंत में, इसके बारे में:

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

मैं इससे पूरी तरह सहमत हूं। जोर से असफल होना हमेशा चुपचाप असफल होने से बेहतर होता है। हालाँकि, गो में एक पकड़ है:

• यदि आपके पास हजारों गोरोइन के साथ एक ऐप है, तो उनमें से एक में एक अनियंत्रित आतंक पूरे कार्यक्रम को क्रैश कर देता है। यह अन्य भाषाओं की तुलना में अलग है, जहां केवल वह धागा जो दहशत में है दुर्घटनाग्रस्त हो जाता है

इसे एक तरफ रख दें (हालांकि यह काफी खतरनाक है), तो, विफलताओं की एक पूरी श्रेणी ( nil -संबंधित विफलताओं) से बचने के लिए विचार है।

तो आइए इस पर पुनरावृति करते रहें और समाधान खोजने का प्रयास करें।

आपके समय और ऊर्जा के लिए धन्यवाद!

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

वाक्य - विन्यास:

type Type enum {
         Tuple (int,int),
         One int,
         None,
};

आकार के ऊपर के उदाहरण में आकार ((int, int)) होगा।
पैटर्न मिलान नए बनाए गए मैच ऑपरेटर के साथ या मौजूदा स्विच ऑपरेटर के भीतर किया जा सकता है, जैसे:

var a Type
switch (a) {
         case Tuple{(b,c)}:
                    //do something
         case One{b}:
                    //do something else
         case None:
                    //...
}

निर्माण वाक्यविन्यास:
var a Type = Type{One=12}
ध्यान दें, कि एनम इंस्टेंस कंस्ट्रक्शन में केवल एक वैरिएंट निर्दिष्ट किया जा सकता है।

शून्य मान (समस्या):
हम वर्णमाला क्रम में नामों को क्रमबद्ध कर सकते हैं, एनम का शून्य मान क्रमबद्ध सदस्य सूची में पहले सदस्य के प्रकार का शून्य मान होगा।

शून्य मूल्य समस्या का PS समाधान ज्यादातर समझौते द्वारा परिभाषित किया गया है।

मुझे लगता है कि योग के शून्य मान को पहले उपयोगकर्ता परिभाषित योग फ़ील्ड के शून्य मान के रूप में रखना कम भ्रमित करने वाला होगा, शायद

मुझे लगता है कि योग के शून्य मान को पहले उपयोगकर्ता परिभाषित योग फ़ील्ड के शून्य मान के रूप में रखना कम भ्रमित करने वाला होगा, शायद

लेकिन शून्य मूल्य बनाना क्षेत्र घोषणा आदेश पर निर्भर करता है, मुझे लगता है कि यह बदतर है।

किसी ने डिजाइन डॉक लिखा है?

मेरे पास एक है:
19412-भेदभाव_संघ_और_पैटर्न_मिलान.एमडी.ज़िप

मैंने इसे बदल दिया:

मुझे लगता है कि योग के शून्य मान को पहले उपयोगकर्ता परिभाषित योग फ़ील्ड के शून्य मान के रूप में रखना कम भ्रमित करने वाला होगा, शायद

अब मेरे प्रस्ताव में जीरो वैल्यू (समस्या) पर समझौता urandoms की स्थिति में चला गया।

UPD: डिज़ाइन दस्तावेज़ बदल गया, मामूली सुधार।

मेरे पास दो हालिया उपयोग के मामले हैं, जहां मुझे योग प्रकारों में निर्मित करने की आवश्यकता है:

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

दोनों मामलों में कुछ इस तरह लागू किया गया (दूसरे कार्य के उदाहरण पर):

type Task interface {
    task()
}

type SearchAdd struct {
    Ctx   context.Context
    ID    string
    Attrs Attributes
}

func (SearchAdd) task() {}

type SearchUpdate struct {
    Ctx         context.Context
    ID          string
    UpdateAttrs UpdateAttributes
}

func (SearchUpdate) task() {}

type SearchDelete struct {
    Ctx context.Context
    ID  string
}

func (SearchDelete) task() {}

और तब

task := <- taskChannel

switch v := task.(type) {
case tasks.SearchAdd:
    resp, err := search.Add(task.Ctx, &search2.RequestAdd{…}
    if err != nil {
        log.Error().Err(err).Msg("blah-blah-blah")
    } else {
        if resp.GetCode() != search2.StatusCodeSuccess  {
            …
        } 
    }
case tasks.SearchUpdate:
    …
case tasks.SearchDelete:
    …
}

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

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

मैं वास्तव में कुछ ऐसा होने पर विश्वास करता हूं

type Task oneof {
    // SearchAdd holds a data for a new record in the search index
    SearchAdd {
        Ctx   context.Context
        ID    string
        Attrs Attributes   
    }

    // SearchUpdate update a record
    SearchUpdate struct {
        Ctx         context.Context
        ID          string
        UpdateAttrs UpdateAttributes
    }

    // SearchDelete delete a record
    SearchDelete struct {
        Ctx context.Context
        ID  string
    }
}

+

switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

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

आउच, वाक्य रचना प्रस्ताव के बिंदु से चूक गए। इसे ठीक करो।

दो संस्करण, एक सामान्य योग प्रकार के लिए और गणना के लिए योग प्रकार:

सामान्य योग प्रकार

type Sum oneof {
    T₁ TypeDecl₁
    T₂ TypeDecl₂
    …
    Tₙ TypeDeclₙ
}

जहां T₁ … Tₙ Sum ( oneof उन्हें इसके दायरे से बाहर उजागर करता है) के साथ समान स्तर पर टाइप परिभाषाएं हैं और Sum घोषित करता है कुछ इंटरफ़ेस जो केवल T₁ … Tₙ संतुष्ट करता है।

प्रसंस्करण हमारे पास (type) स्विच के समान है, सिवाय इसके कि यह oneof ऑब्जेक्ट्स पर निहित रूप से किया जाता है और सभी प्रकार सूचीबद्ध होने पर एक कंपाइलर जांच होनी चाहिए।

वास्तविक प्रकार सुरक्षित गणना

type Enum oneof {
    Value = iota
}

कॉन्स के iota के समान ही, केवल स्पष्ट रूप से सूचीबद्ध मानों को छोड़कर Enums हैं और बाकी सब कुछ नहीं है।

switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

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

मुझे नहीं लगता कि task चर के अर्थ में हेरफेर करना अच्छा विचार है, हालांकि स्वीकार्य है।

```go
switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

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

मुझे नहीं लगता कि कार्य चर के अर्थ में हेरफेर करना अच्छा विचार है, हालांकि स्वीकार्य है।
```

फिर अपने आगंतुकों के साथ शुभकामनाएँ।

@sirkon आगंतुकों के बारे में

switch task {
case Task.SearchAdd:
    // task is Task.SearchAdd in this scope
case Task.SearchUpdate:
case Task.SearchDelete:
}

इसके अलावा Task लिए नो-वैल्यू क्या होगा? उदाहरण के लिए:

var task Task

क्या यह nil ? यदि हां, तो क्या switch में अतिरिक्त case nil ?
या इसे पहले प्रकार के लिए प्रारंभ किया जाएगा? यह अजीब होगा, क्योंकि तब प्रकार की घोषणा का क्रम उस तरह से मायने रखता है जैसे यह पहले नहीं था, हालांकि यह संख्यात्मक enums के लिए शायद ठीक होगा।

मुझे लगता है कि यह switch task.(type) बराबर है लेकिन स्विच के लिए सभी मामलों की आवश्यकता होगी, है ना? जैसा कि .. यदि आप एक मामले को याद करते हैं, तो संकलन त्रुटि। और default की अनुमति नहीं है। क्या वह सही है?

आगंतुकों के बारे में आपका क्या मतलब है?

मेरा मतलब था कि इस तरह की कार्यक्षमता के लिए वे गो में एकमात्र प्रकार का सुरक्षित विकल्प हैं। मामलों के एक निश्चित सेट (पूर्वनिर्धारित विकल्पों की सीमित संख्या) के लिए उस पर बहुत बुरा।

इसके अलावा टास्क के लिए नो-वैल्यू क्या होगा? उदाहरण के लिए:

var task Task

मुझे डर है कि यह गो में इस तरह से एक नील योग्य प्रकार होना चाहिए

या इसे पहले प्रकार के लिए प्रारंभ किया जाएगा?

विशेष रूप से एक उद्देश्य के लिए बहुत अजीब होगा।

मुझे लगता है कि यह कार्य स्विच करने के बराबर है। (प्रकार) लेकिन स्विच के लिए सभी मामलों की आवश्यकता होगी, है ना? जैसा कि .. यदि आप एक मामले को याद करते हैं, तो संकलन त्रुटि।

हा सही है।

और कोई डिफ़ॉल्ट अनुमति नहीं है। क्या वह सही है?

नहीं, डिफ़ॉल्ट की अनुमति है। हालांकि हतोत्साहित।

पीएस मुझे लगता है कि गो @ianlancetaylor और अन्य गो लोगों के पास योग प्रकार हैं। ऐसा लगता है कि शून्यता उन्हें काफी एनपीडी-प्रवण बनाती है, क्योंकि गो का शून्य मूल्यों पर कोई नियंत्रण नहीं है।

अगर यह शून्य है, तो मुझे लगता है कि यह ठीक है। मैं पसंद करूंगा कि case nil स्विच स्टेटमेंट के लिए एक आवश्यकता थी। एक if task != nil पहले करना भी ठीक है, मुझे बस इतना पसंद नहीं है:|

क्या इसकी भी इजाजत होगी?

type Foo oneof {
  A = 3
  B = "3"
  C = 3.0
  D = struct { E bool }{ true }
}

क्या इसकी भी इजाजत होगी?

type Foo oneof {
  A = 3
  B = "3"
  C = 3.0
  D = struct { E bool }{ true }
}

खैर, तब कोई स्थिरांक नहीं, केवल

type Foo oneof {
    A <type reference>
}

या

type Foo oneof {
    A = iota
    B
    C
}

या

type Foo oneof {
    A = 1
    B = 2
    C = 3
}

आईओटा और मूल्यों का कोई संयोजन नहीं। या मूल्यों पर नियंत्रण के साथ संयोजन, उन्हें दोहराया नहीं जाना चाहिए।

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

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

वैसे भी। बस सोचा कि यह दिलचस्प है।

@Merovius नवीनतम जेनेरिक डिज़ाइन के बारे में एक उत्कृष्ट बिंदु बनाता है जो योग प्रकारों के कुछ उपयोग मामलों से निपटने में सक्षम है। उदाहरण के लिए, यह फ़ंक्शन जो पहले थ्रेड में उपयोग किया गया था:

func addOne(x int|float64) int|float64 {
    switch x := x.(type) {
    case int:
        return x + 1
    case float64:
         return x + 1
    }
}

बन जाएगा:

contract intOrFloat64(T) {
    T int, float64
}

func addOne(type T intOrFloat64) (x T) T {
    return x + 1
}

जहां तक ​​योग के प्रकारों का संबंध है, यदि जेनरिक अंततः उतरते हैं, तो मैं अब इस बारे में और भी अधिक संदिग्ध होगा कि क्या उन्हें पेश करने के लाभ गो जैसी सरल भाषा के लिए लागतों से अधिक होंगे।

हालांकि, अगर कुछ किया जाना था, तो सबसे सरल और कम से कम विघटनकारी समाधान आईएमओ @ianlancetaylor का 'प्रतिबंधित इंटरफेस' का विचार होगा जिसे ठीक उसी तरह लागू किया जाएगा जैसे 'अप्रतिबंधित' इंटरफेस आज हैं लेकिन केवल संतुष्ट हो सकते हैं निर्दिष्ट प्रकारों द्वारा। वास्तव में, यदि आपने सामान्य डिज़ाइन की पुस्तक से एक पत्ता निकाला है, और प्रकार की बाधा को इंटरफ़ेस ब्लॉक की पहली पंक्ति बना दिया है:

type intOrFloat64 interface{ type int, float64 }    

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

मुझे प्रतिबंधित इंटरफ़ेस प्रकार के एक चर के लिए मान निर्दिष्ट करने में कोई समस्या नहीं दिखती है। यदि RHS पर मान का प्रकार (या एक टाइप न किए गए अक्षर का डिफ़ॉल्ट प्रकार) निर्दिष्ट प्रकारों में से किसी एक के लिए सटीक मिलान नहीं था तो यह बस संकलित नहीं होगा। तो हमारे पास होगा:

var v1 intOrFloat64 = 1        // compiles, dynamic type int
var v2 intOrFloat64 = 1.0      // compiles, dynamic type float64
var v3 intOrFloat64 = 1 + 2i   // doesn't compile, complex128 is not a specified type

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

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

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

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

@alanfo , @Merovius क्यू के लिए धन्यवाद; यह दिलचस्प है कि यह चर्चा इस दिशा में बदल रही है:

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

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

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

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

@ ग्रिसेमर

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

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

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

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

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

मुझे लगता है कि यह वास्तव में कोई फर्क नहीं पड़ता अगर इंटरफ़ेस प्रकार की बाधाओं में 'गैर-अंतर्निहित' प्रकार शामिल हो सकते हैं जहां तक ​​​​जेनिक्स का संबंध था, हालांकि उन्हें सटीक प्रकारों तक सीमित करने के लिए किसी तरह की आवश्यकता होगी (और व्युत्पन्न प्रकार भी नहीं) इसलिए वे योग प्रकारों के लिए उपयुक्त होंगे। यदि हम वर्तमान खोजशब्दों के साथ बने रहना चाहते हैं तो शायद हम बाद वाले के लिए const type (या केवल const ) का उपयोग कर सकते हैं।

@griesemer कुछ कारण हैं कि पैरामीटरयुक्त इंटरफ़ेस प्रकार अनुबंधों के लिए प्रत्यक्ष प्रतिस्थापन नहीं हैं।

1. प्रकार पैरामीटर अन्य पैरामीटरयुक्त प्रकारों के समान हैं।
   एक प्रकार में

   type C2(type T C1) interface { ... }
   

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

2. इंटरफ़ेस के मुख्य भाग में रिसीवर प्रकार का नाम देने का कोई तरीका नहीं है।
   इंटरफेस को आपको कुछ ऐसा लिखने देना होगा:

   type C3(type U C1) interface(T) {
       Add(T) T
   }
   

   जहां T रिसीवर प्रकार को दर्शाता है।

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

अंतर्निहित प्रकार की बाधाओं और प्रकार की पहचान बाधाओं के बीच अंतर करने के लिए, एक तरीका है जो काम कर सकता है। कल्पना कीजिए कि हम कस्टम बाधाओं को परिभाषित कर सकते हैं, जैसे

contract (T) indenticalTo(U) {
    *T *U
}

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

चूंकि एक शाब्दिक सूचक प्रकार का अंतर्निहित प्रकार स्वयं ही है, इस बाधा का तात्पर्य है कि T समान है U । क्योंकि इसे एक बाधा के रूप में घोषित किया गया है, आप (identicalTo(int)), (identicalTo(uint)), ... को एक बाधा वियोजन के रूप में लिख सकते हैं।

जबकि अनुबंध कुछ प्रकार के योग प्रकारों को व्यक्त करने के लिए उपयोगी हो सकते हैं, मुझे नहीं लगता कि आप उनके साथ सामान्य योग प्रकार व्यक्त कर सकते हैं। मैंने मसौदे से जो देखा है, उसमें से ठोस प्रकारों को सूचीबद्ध करना होगा, ताकि आप ऐसा कुछ नहीं लिख सकें:

contract Foo(T, U) {
    T U, int64
}

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

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

यदि हम विभिन्न प्रकार के मापदंडों पर विचार करते हैं तो स्थिति का विश्लेषण करना शायद सबसे आसान है:

कोई पैरामीटर नहीं

कोई परिवर्तन नहीं होता है :)

एक पैरामीटर

यहां कोई वास्तविक समस्या नहीं है। एक पैरामीटरयुक्त इंटरफ़ेस (एक गैर-जेनेरिक के विपरीत) की आवश्यकता केवल तभी होगी जब इंटरफ़ेस को तुरंत चालू करने के लिए या तो स्वयं को संदर्भित प्रकार पैरामीटर और/या कुछ अन्य स्वतंत्र निश्चित प्रकार (ओं) की आवश्यकता हो।

दो या अधिक पैरामीटर

जैसा कि पहले उल्लेख किया गया है कि प्रत्येक प्रकार के पैरामीटर को व्यक्तिगत रूप से विवश करने की आवश्यकता होगी यदि उसे किसी बाधा की आवश्यकता हो।

एक पैरामीटरयुक्त इंटरफ़ेस की आवश्यकता केवल तभी होगी जब:

1. प्रकार पैरामीटर स्वयं को संदर्भित करता है।

2. इंटरफ़ेस किसी अन्य प्रकार के पैरामीटर या पैरामीटर को संदर्भित करता है जिसे टाइप पैरामीटर अनुभाग में _ पहले ही घोषित किया जा चुका है (संभवतः हम यहां पीछे नहीं हटना चाहेंगे)।

3. इंटरफ़ेस को तुरंत चालू करने के लिए कुछ अन्य स्वतंत्र निश्चित प्रकारों की आवश्यकता थी।

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

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

इसलिए ऐसा नहीं लगता है कि यहां कोई भी समस्या नहीं है, भले ही अनुबंधों का विचार अच्छा हो।

संभवतः, comparable अब अनुबंध के बजाय केवल एक अंतर्निर्मित इंटरफ़ेस बन सकता है।

इंटरफेस, निश्चित रूप से, एक दूसरे में एम्बेडेड हो सकते हैं जैसा कि वे पहले से ही कर सकते हैं।

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

अब @stevenblenkinsop की टिप्पणियों की ओर मुड़ते हुए, मुझे आश्चर्य है कि क्या यह जीवन को आसान बना देगा यदि पैरामीटरयुक्त इंटरफेस ने अपने स्वयं के प्रकार के मापदंडों को किसी भी तरह से बाधित नहीं होने दिया? मुझे यकीन नहीं है कि यह वास्तव में एक उपयोगी सुविधा है, जब तक कि कोई समझदार उपयोग के मामले के बारे में नहीं सोच सकता।

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

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

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

interface Foo(T) {
    const type T, int64  // 'const' indicates types are exact i.e. no derived types
}

हम भाषा में भेदभाव वाली यूनियनों को जोड़ने के बजाय उनकी अनुपस्थिति के बारे में एक और चाल का आविष्कार क्यों नहीं कर सकते हैं?

@griesemer आप जागरूक हो सकते हैं या नहीं भी हो सकते हैं, लेकिन मैं शुरुआत से बाधाओं को निर्दिष्ट करने के लिए इंटरफेस का उपयोग करने के पक्ष में रहा हूं :) मैं ऑपरेटरों को संबोधित करने का सुझाव देता हूं)। और मुझे अनुबंधों का सबसे हालिया पुनरावृत्ति पिछले एक की तुलना में बहुत अधिक पसंद है। लेकिन सामान्य तौर पर, मैं पूरी तरह से सहमत हूं कि (संभवतः विस्तारित) इंटरफेस बाधाओं के रूप में व्यवहार्य और विचार करने योग्य हैं।

@urandom

मुझे नहीं लगता कि आप उनके साथ सामान्य योग प्रकार व्यक्त कर सकते हैं

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

@alanfo

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

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

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

@stevenblenkinsop

इंटरफ़ेस के मुख्य भाग में रिसीवर प्रकार का नाम देने का कोई तरीका नहीं है।

जिस तरह से आप संबोधित करेंगे वह उपयोग-साइट पर टाइप-तर्क के साथ है। अर्थात

type Adder(type T) interface {
    Add(t T) T
}

func Sum(type T Adder(T)) (vs []T) T {
    var t T
    for _, v := range vs {
        t = t.Add(v)
    }
    return t
}

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

आपका 1. और 3. मैं वास्तव में नहीं समझता, मुझे स्वीकार करना होगा। मुझे कुछ ठोस उदाहरणों से लाभ होगा।

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

```go
switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

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

फिर अपने आगंतुकों के साथ शुभकामनाएँ।

आपको क्यों लगता है कि पैटर्न मिलान गो में नहीं किया जा सकता है? यदि आपके पास पैटन मिलान के उदाहरणों की कमी है, उदाहरण के लिए, जंग देखें।

@Merovius पुन: "मेरे लिए, एक ग्राफ एक इकाई है"

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

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

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

interface{} योजनाओं के साथ वर्तमान में सभी जगह होने वाली त्रुटियों में कमी का सुझाव देने के लिए, लेकिन | ऑपरेटर की निरंतर टाइपिंग को हटाने के लिए, मैं निम्नलिखित का सुझाव दूंगा:

type foobar union {
    int
    float64
}

इस प्रकार की सुरक्षा के साथ कई interface{} को बदलने का केवल उपयोग-मामला पुस्तकालय के लिए एक बड़ा लाभ होगा। क्रिप्टो लाइब्रेरी की आधी चीजों को देखकर ही इसका इस्तेमाल किया जा सकता है।

जैसे मुद्दे: आह आपने ecdsa.PrivateKey बजाय *ecdsa.PrivateKey - यहां एक सामान्य त्रुटि है जो केवल ecdsa.PrivateKey समर्थित है। साधारण तथ्य यह है कि ये स्पष्ट संघ प्रकार होने चाहिए, जिससे सुरक्षा में काफी वृद्धि होगी।

हालांकि यह सुझाव int|float64 की तुलना में अधिक _space_ लेता है, लेकिन यह उपयोगकर्ता को इस बारे में सोचने के लिए मजबूर करता है। कोड-बेस को बहुत साफ-सुथरा रखना।

interface{} योजनाओं के साथ वर्तमान में सभी जगह होने वाली त्रुटियों में कमी का सुझाव देने के लिए, लेकिन | ऑपरेटर की निरंतर टाइपिंग को हटाने के लिए, मैं निम्नलिखित का सुझाव दूंगा:

type foobar union {
    int
    float64
}

इस प्रकार की सुरक्षा के साथ कई interface{} को बदलने का केवल उपयोग-मामला पुस्तकालय के लिए एक बड़ा लाभ होगा। क्रिप्टो लाइब्रेरी की आधी चीजों को देखकर ही इसका इस्तेमाल किया जा सकता है।

जैसे मुद्दे: आह आपने ecdsa.PrivateKey बजाय *ecdsa.PrivateKey - यहां एक सामान्य त्रुटि है जो केवल ecdsa.PrivateKey समर्थित है। साधारण तथ्य यह है कि ये स्पष्ट संघ प्रकार होने चाहिए, जिससे सुरक्षा में काफी वृद्धि होगी।

हालांकि यह सुझाव int|float64 की तुलना में अधिक _space_ लेता है, लेकिन यह उपयोगकर्ता को इस बारे में सोचने के लिए मजबूर करता है। कोड-बेस को बहुत साफ-सुथरा रखना।

यह देखें (टिप्पणी) , यह मेरा प्रस्ताव है।

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

सुविधाओं के लिए मेरा प्रस्ताव, विशेष रूप से पैटर्न मिलान, आपकी संगतता और पुराने कोड आधारों के लिए सुविधा से लाभ उठाने की क्षमता के लिए।

लेकिन यह ओवरकिल जैसा दिखता है, है ना?

साथ ही, योग प्रकार को nil के डिफ़ॉल्ट मान के रूप में बनाया जा सकता है। बेशक इसे हर स्विच में nil केस की आवश्यकता होगी।
पैटर्न मिलान इस प्रकार किया जा सकता है:
-- घोषणा

type U enum{
    A(int64),
    B(string),
}

-- मेल मिलाना

...
var a U
...
switch a {
    case A{b}:
         //process b here
    case B{b}:
         //...
    case nil:
         //...
}
...

यदि किसी को पैटर्न मिलान पसंद नहीं है - ऊपर सिरकॉन का प्रस्ताव देखें।

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

क्या संकलन समय पर गैर-आरंभिक मूल्य को अस्वीकार करना आसान नहीं होगा? उन मामलों के लिए जहां हमें प्रारंभिक मूल्य की आवश्यकता होती है, हम इसे योग प्रकार में जोड़ सकते हैं: यानी

type U enum {
  None
  A(string)
  B(uint64)
}
...
var a U.None
...
switch a {
  case U.None: ...
  case U.A(str): ...
  case U.B(i): ...
}

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

क्या संकलन समय पर गैर-आरंभिक मूल्य को अस्वीकार करना आसान नहीं होगा? उन मामलों के लिए जहां हमें प्रारंभिक मूल्य की आवश्यकता होती है, हम इसे योग प्रकार में जोड़ सकते हैं: यानी

मौजूदा कोड को तोड़ता है।

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

क्या संकलन समय पर गैर-आरंभिक मूल्य को अस्वीकार करना आसान नहीं होगा? उन मामलों के लिए जहां हमें प्रारंभिक मूल्य की आवश्यकता होती है, हम इसे योग प्रकार में जोड़ सकते हैं: यानी

मौजूदा कोड को तोड़ता है।

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

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

मैं पहले विचार पर आपसे सहमत था, लेकिन कुछ प्रतिबिंब के बाद, संघ के लिए नया आरक्षित नाम पहले कुछ कोडबेस (संघ, एनम, आदि) में इस्तेमाल किया जा सकता था।

मुझे लगता है कि शून्य की जांच करने का दायित्व उपयोग करने के लिए काफी दर्दनाक होगा।

यह पिछड़े संगतता के लिए एक ब्रेकिंग परिवर्तन की तरह दिखता है जिसे केवल Go2.0 . द्वारा हल किया जा सकता है

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

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

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

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

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

अब, html/template.contentType पर विचार करें। सादा प्रकार इसका डिफ़ॉल्ट मान है, और वास्तव में इसे स्ट्रिंग फ़ंक्शन द्वारा माना जाता है, क्योंकि यह फ़ॉलबैक है। एक काल्पनिक योग भविष्य में, आपको न केवल उस व्यवहार की आवश्यकता होगी, बल्कि इसके लिए शून्य मान का उपयोग करना भी संभव नहीं होगा, क्योंकि इस प्रकार के उपयोगकर्ता के लिए शून्य का कोई मतलब नहीं होगा। यहां हमेशा नामित मान वापस करना अनिवार्य होगा, और आपके पास उस मान का स्पष्ट डिफ़ॉल्ट होना चाहिए।

यह मैं फिर से एक और उदाहरण के साथ हूं जहां बीजगणित/भिन्न/योग/जो भी डेटा प्रकार अच्छी तरह से काम करते हैं।

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

मेरे पास संस्थाओं का एक सेट लिखने के लिए एक नया कार्य है जिसे डाला जा सकता है, जोड़ा जा सकता है या हटाया जा सकता है (इनमें से केवल एक ऑप्स)।

अगर हमारे पास कुछ ऐसा हो सकता है

type EntityOp oneof {
    Insert   Reference
    NewState string
    Delete   struct{}
}

विधि उचित हो सकती है

type DB interface {
    …
    Capture(ctx context.Context, processID string, ops map[string]EntityOp) (bool, error)
}

योग समय के लिए एक शानदार उपयोग एएसटी में नोड्स का प्रतिनिधित्व करना है। एक और nil को option से बदलना है जिसे कंपाइल-टाइम पर चेक किया जाता है।

@DemiMarie लेकिन आज के गो में, यह राशि शून्य भी हो सकती है, जैसा कि मैंने ऊपर प्रस्तावित किया है, हम बस प्रत्येक एनम का संस्करण होने के लिए शून्य बना सकते हैं, प्रत्येक स्विच में मामला शून्य होगा लेकिन यह दायित्व इतना बुरा नहीं है, खासकर यदि हम सभी मौजूदा गो कोड को तोड़े बिना यह सुविधा चाहते हैं (वर्तमान में हमारे पास सब कुछ शून्य है)

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

var name: "Peter" | "Consuela"; // string type with compile-time constraint

यह स्ट्रिंग एनम की तरह है, जो मेरी राय में पारंपरिक संख्यात्मक एनम से बेहतर है।

@मेरोवियस
एक ठोस उदाहरण मनमाने ढंग से JSON के साथ काम कर रहा है।
जंग में इसे के रूप में दर्शाया जा सकता है
एनम वैल्यू {
शून्य,
बूल (बूल),
संख्या (संख्या),
स्ट्रिंग (स्ट्रिंग),
ऐरे(Vec),
वस्तु(मानचित्र),
}

दो फायदे के रूप में एक संघ प्रकार:

1. कोड का स्व-दस्तावेजीकरण
2. संघ प्रकार के गलत उपयोग की जाँच करने के लिए संकलक या go vet अनुमति देना
   (उदाहरण के लिए एक स्विच जहां सभी प्रकार की जांच नहीं की जाती है)

सिंटैक्स के लिए, निम्नलिखित को Go1 के साथ संगत होना चाहिए, जैसे कि अन्य प्रकार के साथ:

type Token = int | float64 | string

एक संघ प्रकार को आंतरिक रूप से एक इंटरफ़ेस के रूप में लागू किया जा सकता है; यह महत्वपूर्ण है कि संघ प्रकार का उपयोग करने से कोड अधिक पठनीय हो जाता है और त्रुटियों को पकड़ता है जैसे

var tok Token

switch t := tok.(type) {
case int:
    // do something
}

कंपाइलर को एक त्रुटि उठानी चाहिए, क्योंकि स्विच में सभी Token प्रकारों का उपयोग नहीं किया जाता है।

इसके साथ समस्या यह है कि (मेरी जानकारी में) पॉइंटर प्रकार (या ऐसे प्रकार जिनमें पॉइंटर्स होते हैं, जैसे string ) और गैर-पॉइंटर प्रकार एक साथ स्टोर करने का कोई तरीका नहीं है। विभिन्न लेआउट वाले प्रकार भी काम नहीं करेंगे। मुझे सही करने के लिए स्वतंत्र महसूस करें लेकिन समस्या यह है कि सटीक जीसी चर के साथ अच्छी तरह से काम नहीं करता है जो एक ही समय में पॉइंटर्स और सरल चर हो सकते हैं।

हम निहित मुक्केबाजी की राह पर जा सकते हैं - जैसे interface{} वर्तमान में करता है। लेकिन मुझे नहीं लगता कि यह पर्याप्त लाभ प्रदान करता है - यह अभी भी एक गौरवशाली इंटरफ़ेस प्रकार जैसा दिखता है। हो सकता है कि इसके बजाय किसी प्रकार का vet चेक विकसित किया जा सके?

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

हो सकता है कि इसके बजाय किसी प्रकार की पशु चिकित्सक जांच विकसित की जा सके?

https://github.com/BurntSushi/go-sumtype

लेआउट निर्धारित करने के लिए कचरा संग्रहकर्ता को संघ से टैग बिट्स को पढ़ने की आवश्यकता होगी।

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

go-sumtype दिलचस्प है, धन्यवाद। लेकिन क्या होता है यदि एक ही पैकेज दो संघ प्रकारों को परिभाषित करता है?

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

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

लेकिन क्या होता है यदि एक ही पैकेज दो संघ प्रकारों को परिभाषित करता है?

ज्यादा कुछ नहीं? तर्क प्रति-प्रकार है और कार्यान्वयनकर्ताओं को पहचानने के लिए एक डमी विधि का उपयोग करता है। डमी विधियों के लिए बस अलग-अलग नामों का प्रयोग करें।

@skybrian IIRC वर्तमान बिटमैप जो टाइप लेआउट निर्दिष्ट करता है, वर्तमान में एक ही स्थान पर संग्रहीत है। प्रति ऑब्जेक्ट ऐसी चीज़ जोड़ने से बहुत सारी छलांग लगेगी, और हर वैकल्पिक ऑब्जेक्ट को GC रूट बना देगा।

इसके साथ समस्या यह है कि (मेरी जानकारी के लिए) पॉइंटर प्रकार (या प्रकार जिसमें पॉइंटर्स होते हैं, जैसे स्ट्रिंग) और गैर-पॉइंटर प्रकारों को एक साथ स्टोर करने का कोई तरीका नहीं है

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

लेकिन मुझे नहीं लगता कि यह पर्याप्त लाभ प्रदान करता है - यह अभी भी एक गौरवशाली इंटरफ़ेस प्रकार जैसा दिखता है।

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

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

क्या मैं कर सकता हूँ

type FooType int | float64

func AddOne(foo FooType) FooType {
    return foo + 1
}

// if this can be done, what happens here?
type FooType nil | int
func AddOne(foo FooType) FooType {
    return foo + 1
}

यदि यह नहीं किया जा सकता है, तो मुझे इसमें बहुत अंतर दिखाई नहीं देता

type FooType interface{}

func AddOne(foo FooType) (FooType, error) {
    switch v := foo.(type) {
        case int:
              return v + 1, nil
        case float64:
              return v + 1.0, nil
    }

    return nil, fmt.Errorf("invalid type %T", foo)
}

// versus
type FooType int | float64

func AddOne(foo FooType) FooType {
    switch v := foo.(type) {
        case int:
              return v + 1
        case float64:
              return v + 1.0
    }

    // assumes the compiler knows that there is no other type is 
    // valid and thus this should always returns a value
    // Would the compiler error out on incomplete switch types?
}

@xibz

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

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

const a = "1" // string "1"
const b = a + 5 // string "15" and not number 6

यदि यह नहीं किया जा सकता है, तो मुझे इसमें बहुत अंतर दिखाई नहीं देता

मुझे लगता है कि आप कुछ फायदे खुद बताते हैं, है ना?
मैं

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

// Would the compiler error out on incomplete switch types?

कार्यात्मक प्रोग्रामिंग भाषाएं क्या करती हैं, इसके आधार पर, मुझे लगता है कि यह संभव और विन्यास योग्य होना चाहिए

@xibz भी प्रदर्शन के बाद से संकलन समय बनाम रनटाइम पर किया जा सकता है, लेकिन फिर जेनेरिक है, उम्मीद है, मेरे मरने से एक दिन पहले।

@xibz

जिज्ञासा से बाहर, क्या मैं सीधे योग प्रकार का उपयोग कर सकता हूं या क्या मुझे इसके साथ कुछ भी करने के लिए इसे किसी ज्ञात प्रकार में डालने की स्पष्ट रूप से आवश्यकता है?

आप उस पर विधियों को कॉल कर सकते हैं यदि प्रकार के सभी सदस्य उस विधि को साझा करते हैं।

एक उदाहरण के रूप में अपना int | float64 लेते हुए, इसका परिणाम क्या होगा:

var x int|float64 = int(2)
var y int|float64 = float64(0.5)
fmt.Println(x * y)

क्या यह int से float64 एक अंतर्निहित रूपांतरण करेगा? या float64 से int । या यह घबराएगा?

तो आप लगभग सही हैं - ज्यादातर मामलों में इसका उपयोग करने से पहले आपको टाइप-चेक करना होगा। मेरा मानना ​​है कि यह एक फायदा है, हालांकि नुकसान नहीं है।

रनटाइम लाभ महत्वपूर्ण हो सकता है, बीटीडब्ल्यू। अपने उदाहरण प्रकार के साथ जारी रखने के लिए, [](int|float64) प्रकार के एक स्लाइस में किसी भी पॉइंटर्स को शामिल करने की आवश्यकता नहीं होगी क्योंकि कुछ बाइट्स में प्रकार के सभी उदाहरणों का प्रतिनिधित्व करना संभव है (शायद संरेखण प्रतिबंधों के कारण 16 बाइट्स), जो हो सकता है कुछ मामलों में महत्वपूर्ण प्रदर्शन में सुधार होता है।

@रोगपेप्पे

ज्यादातर मामलों में इसका उपयोग करने से पहले आपको टाइप-चेक करना होगा। मेरा मानना ​​है कि यह एक फायदा है, हालांकि नुकसान नहीं है।

मैं इस बात से सहमत हूं कि यह नुकसान नहीं है। मैं सिर्फ यह देखने की कोशिश कर रहा हूं कि इंटरफेस के विपरीत यह हमें क्या लाभ देता है।

प्रकार के एक टुकड़े में किसी भी पॉइंटर्स को शामिल करने की आवश्यकता नहीं होगी क्योंकि कुछ बाइट्स (संभवतः संरेखण प्रतिबंधों के कारण 16 बाइट्स) में प्रकार के सभी उदाहरणों का प्रतिनिधित्व करना संभव है, जिससे कुछ मामलों में महत्वपूर्ण प्रदर्शन सुधार हो सकते हैं।

हम्म, मुझे पूरा यकीन नहीं है कि मैं इसका महत्वपूर्ण हिस्सा खरीदूंगा। मुझे यकीन है कि बहुत ही दुर्लभ मामलों में, यह स्मृति आकार को आधा कर देगा। इसके साथ ही, मुझे नहीं लगता कि सहेजी गई स्मृति भाषा परिवर्तन के लिए पर्याप्त महत्वपूर्ण नहीं है।

@stouf

हमेशा पैटर्न मिलान करने के लिए (कार्यात्मक प्रोग्रामिंग भाषाओं में योग प्रकारों के साथ काम करते समय "कास्टिंग" कहा जाता है) वास्तव में योग प्रकारों का उपयोग करने के सबसे बड़े लाभों में से एक है

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

उस सब के साथ, यदि एक योग प्रकार का उपयोग क्लीनर और अधिक पठनीय कोड प्रदान कर सकता है, तो मैं इसके लिए 100% होगा। हालाँकि, इसके लुक से ऐसा लगता है कि यह लगभग इंटरफ़ेस कोड के समान दिखाई देगा।

निजी विधि और संबंधित कार्यान्वयन के साथ इंटरफेस के माध्यम से योग प्रकार अनुकरण बनाने के लिए एक छोटी सी उपयोगिता बनाई, यह कुछ के लिए सहायक हो सकती है: https://github.com/sirkon/go-oneof

जेनरिक के लिए हाल ही में डिज़ाइन किए गए ड्राफ्ट के साथ, शायद योग के प्रकारों को उनसे जोड़ा जा सकता है।

मसौदे में अनुबंधों के बजाय इंटरफेस का उपयोग करने का विचार आया, और इंटरफेस को प्रकार की सूचियों का समर्थन करना होगा:

type Foo interface { 
     int64, int32, int, uint, uint32, uint64
}

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

और हो सकता है, टाइप स्विच के भीतर इन विशेष इंटरफेस का उपयोग करने के लिए यह आवश्यक होगा कि ऐसा स्विच संपूर्ण होगा।

यह आदर्श लघु वाक्यविन्यास नहीं है (उदाहरण: Foo | int32 | []Bar ), लेकिन यह कुछ है।

जेनरिक के लिए हाल ही में डिज़ाइन किए गए ड्राफ्ट के साथ, शायद योग के प्रकारों को उनसे जोड़ा जा सकता है।

मसौदे में अनुबंधों के बजाय इंटरफेस का उपयोग करने का विचार आया, और इंटरफेस को प्रकार की सूचियों का समर्थन करना होगा:

type Foo interface { 
     int64, int32, int, uint, uint32, uint64
}

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

और हो सकता है, टाइप स्विच के भीतर इन विशेष इंटरफेस का उपयोग करने के लिए यह आवश्यक होगा कि ऐसा स्विच संपूर्ण होगा।

यह आदर्श लघु वाक्यविन्यास नहीं है (उदाहरण: Foo | int32 | []Bar ), लेकिन यह कुछ है।

मेरे प्रस्ताव के समान: https://github.com/golang/go/issues/19412#issuecomment -520306000

type foobar union {
  int
  float
}

@mathieudevos वाह, मुझे वास्तव में यह काफी पसंद है।

मेरे लिए, नवीनतम जेनरिक प्रस्ताव के साथ सबसे बड़ी विषमता ( केवल शेष विषमता, वास्तव में) इंटरफेस में प्रकार की सूची है। वे बिल्कुल फिट नहीं

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

// Ordinary interface
type Stringer interface {
    String() string
}

// Type union
type Foobar union {
    int
    float
}

// Equivalent to an interface with a type list
type FoobarStringer interface {
    Stringer
    Foobar
}

// Unions can intersect
type SuperFoo union {
    Foobar
    int
}

// Doesn't compile since these unions can't intersect
type Strange interface {
    Foobar
    union {
        int
        string
    }
}

संपादित करें - वास्तव में, बस इस सीएल को देखा: https://github.com/golang/go/commit/af48c2e84b52f99d30e4787b1b8d527b5cd2ab64

इस परिवर्तन का प्राथमिक लाभ यह है कि यह सामान्य के लिए द्वार खोलता है
(गैर-बाधा) प्रकार की सूचियों के साथ इंटरफेस का उपयोग

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

मैंने वर्तमान जेनरिक डिज़ाइन ड्राफ्ट में योग प्रकार के एक संस्करण के प्रकट होने के तरीके पर चर्चा करने के लिए #41716 खोला है।

मैं सिर्फ बीजगणितीय डेटा प्रकारों के बारे में @henryas का एक पुराना प्रस्ताव साझा करना चाहता था। प्रदान किए गए उपयोग के मामलों के साथ यह बहुत अच्छा लिखा गया है।
https://github.com/golang/go/issues/21154
दुर्भाग्य से, @mvdan द्वारा उसी दिन काम की सराहना किए बिना इसे बंद कर दिया गया है। मुझे पूरा यकीन है कि उस व्यक्ति ने वास्तव में ऐसा ही महसूस किया था और इस प्रकार gh खाते पर आगे कोई गतिविधि नहीं है। मुझे उस आदमी के लिए खेद है।

मुझे वास्तव में #21154 पसंद है। ऐसा लगता है कि यह एक अलग बात है (और इसलिए @mvdan की) टिप्पणी इसे

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

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

@ProximaB मुझे समझ में नहीं आता कि आप क्यों कहते हैं "gh खाते पर कोई और गतिविधियां नहीं हैं"। तब से उन्होंने कई अन्य मुद्दों को भी बनाया और टिप्पणी की है, उनमें से कई गो प्रोजेक्ट पर हैं। मुझे इस बात का कोई सबूत नहीं दिखता कि उनकी गतिविधि उस मुद्दे से बिल्कुल भी प्रभावित हुई है।

इसके अलावा, मैं डेनियल के इस मुद्दे को इस एक के डुप्ली के रूप में बंद करने के साथ दृढ़ता से सहमत हूं। मुझे समझ में नहीं आता कि @andig क्यों कहते हैं कि वे कुछ अलग प्रस्तावित करते हैं। जहाँ तक मैं #21154 के पाठ को समझ सकता हूँ, यह ठीक उसी बात का प्रस्ताव करता

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

इसके अलावा, मैं डेनियल के इस मुद्दे को इस एक के डुप्ली के रूप में बंद करने के साथ दृढ़ता से सहमत हूं। मुझे समझ में नहीं आता कि @andig क्यों कहते हैं कि वे कुछ अलग प्रस्तावित करते हैं। जहाँ तक मैं #21154 के पाठ को समझ सकता हूँ, यह ठीक उसी बात का प्रस्ताव करता है जिसकी हम यहाँ चर्चा कर रहे हैं

इस मुद्दे को दोबारा पढ़कर मैं सहमत हूं। ऐसा लगता है कि मैं इस मुद्दे से जेनेरिक अनुबंधों के साथ भ्रमित हूं। मैं योग प्रकारों का पुरजोर समर्थन करता हूं। मेरा मतलब कठोर नहीं बोलना था, अगर ऐसा कुछ सामने आया हो तो कृपया मेरी माफ़ी मांगें।

मैं एक इंसान और इस मुद्दे को बागवानी समय पर मुश्किल हो सकता है, तो हर तरह से बताते हैं, जब मैं एक गलती करते हैं हूँ :) लेकिन इस मामले में मुझे लगता है कि किसी भी विशिष्ट योग प्रकार प्रस्ताव की तरह ही इस धागे से कांटा चाहिए लगता कि https: / /github.com/golang/go/issues/19412#issuecomment -701625548

मैं एक इंसान और इस मुद्दे को बागवानी समय पर मुश्किल हो सकता है, तो हर तरह से बताते हैं, जब मैं एक गलती करते हैं :) लेकिन इस मामले में मुझे लगता है कि किसी भी विशिष्ट योग प्रकार प्रस्ताव की तरह ही इस धागे से कांटा चाहिए लगता है कि कर रहा हूँ # 19,412 ( टिप्पणी)

@mvdan इंसान नहीं है। मुझ पर विश्वास करो। मैं उसका पड़ोसी हूं। मजाक था।

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

मूल उद्देश्य उनके डोमेन प्रासंगिकता द्वारा प्रकारों के समूहन की अनुमति देना है, जहां वे जरूरी सामान्य व्यवहार साझा नहीं करते हैं, और संकलक इसे लागू करते हैं। मेरी राय में, यह सिर्फ एक स्थिर सत्यापन समस्या है, जो संकलन के दौरान की जाती है। संकलक को कोड उत्पन्न करने की कोई आवश्यकता नहीं है जो प्रकारों के बीच जटिल संबंध बनाए रखता है। जेनरेट कोड इन डोमेन प्रकारों को सामान्य रूप से मान सकता है जैसे कि वे नियमित इंटरफ़ेस {} प्रकार हैं। अंतर यह है कि संकलक अब संकलन पर अतिरिक्त स्थिर प्रकार की जाँच करता है। यही मूल रूप से मेरे प्रस्ताव का सार है #21154

@henryas आपको
मैं सोच रहा था कि अगर गोलंग ने बतख टाइपिंग का उपयोग नहीं किया होता तो इससे प्रकारों के बीच संबंध और अधिक सख्त हो जाते और जैसा कि आपने अपने प्रस्ताव में वर्णित किया है, उनके डोमेन प्रासंगिकता द्वारा समूहीकरण वस्तु को अनुमति दी जाती है।

@henryas आपको
मैं सोच रहा था कि अगर गोलंग ने बतख टाइपिंग का उपयोग नहीं किया होता तो इससे प्रकारों के बीच संबंध और अधिक सख्त हो जाते और जैसा कि आपने अपने प्रस्ताव में वर्णित किया है, उनके डोमेन प्रासंगिकता द्वारा समूहीकरण वस्तु को अनुमति दी जाती है।

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

@ हेनरी मैं सहमत हूं। यह एक काल्पनिक प्रश्न था। गो क्रिएटर्स निश्चित रूप से सभी उतार-चढ़ावों पर गहराई से विचार करते हैं।
दूसरी ओर इंटरफ़ेस अनुपालन की पुष्टि करने जैसी कोडिंग गाइड कभी दिखाई नहीं देगी।
https://github.com/uber-go/guide/blob/master/style.md#verify -interface-compliance

क्या आप कृपया इस विषय से हटकर चर्चा कहीं और कर सकते हैं? इस मुद्दे पर बहुत सारे लोगों ने सदस्यता ली है।
ओपन इंटरफेस संतुष्टि अपनी स्थापना के बाद से गो का हिस्सा रही है और यह बदलने वाली नहीं है।