@derekparker #19412 में एक Go2 प्रस्ताव बनाने के लिए चर्चा चल रही है

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

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

पर्याप्त रूप से, लेकिन इनमें से कोई भी प्रस्ताव संगतता समझौते को नहीं तोड़ रहा है। एक राय व्यक्त की गई थी कि Go1 में जोड़ने के लिए योग प्रकार "बहुत बड़े" थे। अगर ऐसा है, तो यह प्रस्ताव एक मूल्यवान मध्य मैदान है जो Go2 में पूर्ण योग प्रकार के लिए एक कदम पत्थर हो सकता है।

उन दोनों को एक नए कीवर्ड की आवश्यकता होती है जो एक पहचानकर्ता के रूप में उपयोग करके मान्य Go1 कोड को तोड़ देगा

मुझे लगता है कि इसके आसपास काम किया जा सकता है

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

यहाँ वर्तमान गो में गणना लिखने का मुहावरेदार तरीका है:

type SearchRequest int

const (
    Universal SearchRequest = iota
    Web
    Images
    Local
    News
    Products
    Video
)

इसका यह फायदा है कि झंडे बनाना आसान है जो OR:ed हो सकता है (ऑपरेटर का उपयोग करके | ):

type SearchRequest int

const (
    Universal SearchRequest = 1 << iota
    Web
    Images
    Local
    News
    Products
    Video
)

मैं यह नहीं देख सकता कि enum कीवर्ड को पेश करने से यह बहुत छोटा हो जाएगा।

@ md2perpe जो कि एनम नहीं है।

1. उनकी गणना, पुनरावृति नहीं की जा सकती।
2. उनके पास कोई उपयोगी स्ट्रिंग प्रतिनिधित्व नहीं है।
3. उनकी कोई पहचान नहीं है:

```जाओ
पैकेज मुख्य

आयात (
"एफएमटी"
)

func मुख्य () {
SearchRequest int . टाइप करें
स्थिरांक (
यूनिवर्सल सर्च रिक्वेस्ट = आयोटा
वेब
)

const (
    Another SearchRequest = iota
    Foo
)

fmt.Println("Should be false: ", (Web == Foo))
    // Prints: "Should be false:  true"

}
````

मैं @derekperkins से पूरी तरह सहमत हूं कि गो को प्रथम श्रेणी के नागरिक के रूप में कुछ एनम की जरूरत है। यह कैसा दिखेगा, मुझे यकीन नहीं है, लेकिन मुझे संदेह है कि यह गो 1 ग्लास हाउस को तोड़े बिना किया जा सकता है।

@ md2perpe iota enums तक पहुंचने का एक बहुत ही सीमित तरीका है, जो सीमित परिस्थितियों के लिए बहुत अच्छा काम करता है।

1. आपको int चाहिए
2. आपको केवल अपने पैकेज के भीतर सुसंगत रहने की जरूरत है, बाहरी स्थिति का प्रतिनिधित्व करने की नहीं

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

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

@ianlancetaylor

उदाहरण के लिए, क्या लोग मान्य एनम मानों के सेट पर पुनरावृति करने में सक्षम होने की उम्मीद करेंगे, और यदि ऐसा है तो वे ऐसा कैसे करेंगे?

मुझे लगता है कि यह एक ठोस उपयोग का मामला है, जैसा कि @bep द्वारा उल्लेख किया गया है। मुझे लगता है कि पुनरावृत्ति एक मानक गो लूप की तरह दिखाई देगी, और मुझे लगता है कि वे परिभाषित किए गए क्रम में लूप करेंगे।

for i, val := range SearchRequest {
...
}

यदि गो को आईओटा से अधिक कुछ जोड़ना था, तो उस समय बीजगणितीय डेटा प्रकारों के लिए क्यों नहीं जाना चाहिए?

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

@bep उतना सुविधाजनक नहीं है, लेकिन आप ये सभी गुण प्राप्त कर सकते हैं:

package main

var SearchRequests []SearchRequest
type SearchRequest struct{ name string }
func (req SearchRequest) String() string { return req.name }

func Request(name string) SearchRequest {
    req := SearchRequest{name}
    SearchRequests = append(SearchRequests, req)
    return req
}

var (
    Universal = Request("Universal")
    Web       = Request("Web")

    Another = Request("Another")
    Foo     = Request("Foo")
)

func main() {
    fmt.Println("Should be false: ", (Web == Foo))
    fmt.Println("Should be true: ", (Web == Web))
    for i, req := range SearchRequests {
        fmt.Println(i, req)
    }
}

मुझे नहीं लगता कि संकलन-समय की जाँच की गई एनम एक अच्छा विचार है। मेरा मानना ​​है कि गो प्रिटी के पास अभी यह है। मेरा तर्क है

• कंपाइल-टाइम चेक किए गए एनम न तो पीछे की ओर हैं और न ही आगे की ओर जोड़ या हटाने के मामले में संगत हैं। #18130 क्रमिक कोड मरम्मत को सक्षम करने की दिशा में आगे बढ़ने के लिए महत्वपूर्ण प्रयास करता है; enums उस प्रयास को नष्ट कर देगा; कोई भी पैकेज जो कभी भी एनम के एक सेट को बदलना चाहता है, स्वचालित रूप से और जबरन उनके सभी आयातकों को तोड़ देगा।
• मूल टिप्पणी के दावों के विपरीत, प्रोटोबफ (उस विशिष्ट कारण के लिए) वास्तव में एनम फ़ील्ड की वैधता की जांच नहीं करता है। प्रोटो 2 निर्दिष्ट करता है कि एक एनम के लिए एक अज्ञात मान को एक अज्ञात क्षेत्र की तरह माना जाना चाहिए और प्रोटो 3 भी निर्दिष्ट करता है, कि उत्पन्न कोड में एन्कोडेड मान के साथ उनका प्रतिनिधित्व करने का एक तरीका होना चाहिए (ठीक उसी तरह जैसे गो वर्तमान में नकली-एनम के साथ करता है)
• अंत में, यह वास्तव में बहुत कुछ नहीं जोड़ता है। आप स्ट्रिंगर टूल का उपयोग करके कड़ापन प्राप्त कर सकते हैं। आप एक प्रहरी MaxValidFoo const जोड़कर पुनरावृत्ति प्राप्त कर सकते हैं (लेकिन ऊपर चेतावनी देखें। आपको आवश्यकता भी नहीं होनी चाहिए)। आपके पास पहले स्थान पर दो कॉन्स्ट-डिक्लेस नहीं होने चाहिए। बस अपने CI में एक टूल को एकीकृत करें जो उसके लिए जाँच करता है।
• मुझे विश्वास नहीं है कि इनट्स के अलावा अन्य प्रकार वास्तव में आवश्यक हैं। स्ट्रिंगर टूल को पहले से ही स्ट्रिंग्स में और से कनवर्ट करना कवर करना चाहिए; अंत में, जेनरेट किया गया कोड किसी भी तरह से एक कंपाइलर उत्पन्न करने के बराबर होगा (जब तक कि आप गंभीरता से सुझाव नहीं देते कि "स्ट्रिंग-एनम्स" पर कोई तुलना बाइट्स को फिर से चालू करेगी ...)

कुल मिलाकर, मेरे लिए बस एक बहुत बड़ा -1। इतना ही नहीं यह कुछ भी नहीं जोड़ता है; यह सक्रिय रूप से दर्द होता है।

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

चूंकि एनम योग प्रकारों का एक विशेष मामला है और सामान्य ज्ञान यह है कि हमें योग प्रकारों का अनुकरण करने के लिए इंटरफेस का उपयोग करना चाहिए, उत्तर स्पष्ट रूप से है https://play.golang.org/p/1BvOakvbj2

(यदि यह स्पष्ट नहीं है: हाँ, यह एक मजाक है - क्लासिक प्रोग्रामर फैशन में, मैं एक-एक करके बंद हूं)।

पूरी गंभीरता से, इस धागे में चर्चा की गई सुविधाओं के लिए, कुछ अतिरिक्त टूलिंग उपयोगी होगी।

स्ट्रिंगर टूल की तरह, एक "रेंजर" टूल मेरे द्वारा ऊपर लिंक किए गए कोड में Iter func के बराबर उत्पन्न कर सकता है।

तार पर भेजने में आसान बनाने के लिए कुछ {बाइनरी, टेक्स्ट} {मार्शलर, अनमर्शलर} कार्यान्वयन उत्पन्न कर सकता है।

मुझे यकीन है कि इस तरह की बहुत सी छोटी चीजें हैं जो इस अवसर पर काफी उपयोगी होंगी।

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

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

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

@bep मुझे आपके तीनों बिंदुओं से असहमत होना है। गो मुहावरेदार एनम दृढ़ता से सी एनम्स से मिलते जुलते हैं, जिनमें वैध मूल्यों का कोई पुनरावृत्ति नहीं है, स्ट्रिंग्स में कोई स्वचालित रूपांतरण नहीं है, और जरूरी नहीं कि अलग पहचान हो।

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

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

अंत में, विशिष्ट पहचान मुझे यकीन भी नहीं है कि यह एक उपयोगी विशेषता है। Enums योग प्रकार नहीं हैं, कहते हैं, हास्केल। उन्हें नंबर नाम दिया गया है। उदाहरण के लिए, ध्वज मान के रूप में एनम का उपयोग करना आम है। उदाहरण के लिए, आपके पास ReadWriteMode = ReadMode | WriteMode हो सकता है और यह एक उपयोगी चीज है। अन्य मान भी होना काफी संभव है, उदाहरण के लिए आपके पास DefaultMode = ReadMode हो सकता है। ऐसा नहीं है कि कोई भी तरीका किसी को किसी भी स्थिति में const DefaultMode = ReadMode लिखने से रोक सकता है; एक अलग घोषणा में इसे होने की आवश्यकता के लिए इसका क्या उद्देश्य है?

@bep मुझे आपके तीनों बिंदुओं से असहमत होना है। गो मुहावरेदार एनम दृढ़ता से सी एनम्स से मिलते जुलते हैं, जिनमें वैध मूल्यों का कोई पुनरावृत्ति नहीं है, स्ट्रिंग्स में कोई स्वचालित रूपांतरण नहीं है, और जरूरी नहीं कि अलग पहचान हो।

@alercah , कृपया इस idomatic Go को किसी भी चर्चा में "जीतने वाले तर्क" के रूप में न खींचें; गो में बिल्ट-इन एनम नहीं हैं, इसलिए कुछ गैर-मौजूदा मुहावरों के बारे में बात करना, थोड़ा समझ में आता है।

गो को एक बेहतर सी/सी++ या कम वर्बोज़ जावा बनने के लिए बनाया गया था, इसलिए इसे बाद वाले से तुलना करना अधिक समझ में आता है। और जावा में एक अंतर्निहित Enum type है ("जावा प्रोग्रामिंग भाषा एनम प्रकार अन्य भाषाओं में उनके समकक्षों की तुलना में बहुत अधिक शक्तिशाली हैं।"): https://docs.oracle.com/javase/tutorial/java /javaOO/enum.html

और, जबकि आप "अधिक शक्तिशाली भाग" से असहमत हो सकते हैं, जावा Enum प्रकार में मेरे द्वारा उल्लिखित सभी तीन विशेषताएं हैं।

मैं इस तर्क की सराहना कर सकता हूं कि गो दुबला, सरल आदि है, और इसे इस तरह से बनाए रखने के लिए कुछ समझौता किया जाना चाहिए, और मैंने इस धागे में कुछ हैकी वर्कअराउंड देखे हैं जो उस तरह के काम करते हैं, लेकिन iota का एक सेट

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

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

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

मुहावरेदार गो के बारे में बात महत्वपूर्ण है, और मुझे भाषा X से भाषा Y में सभी सुविधाओं की प्रतिलिपि बनाने के लिए मजबूत कारण नहीं दिखते, सिर्फ इसलिए कि कोई परिचित है।

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

//go:generate enumerator Foo,Bar
एक बार लिखा, हर जगह उपलब्ध। ध्यान दें कि उदाहरण सार है।

@bep मुझे लगता है कि आपने मूल टिप्पणी को गलत तरीके से पढ़ा है। "गो इडियोमैटिक एनम्स" को फू इंट + कॉन्स्ट-डेक्ल + आईओटा प्रकार का उपयोग करने के वर्तमान निर्माण को संदर्भित करना था, मेरा मानना ​​​​है कि "जो कुछ भी आप प्रस्तावित कर रहे हैं वह मुहावरेदार नहीं है"।

@rsc Go2 लेबल के संबंध में, यह प्रस्ताव प्रस्तुत करने के मेरे तर्क के विपरीत है। # 19412 एक पूर्ण योग प्रकार का प्रस्ताव है, जो मेरे साधारण एनम प्रस्ताव की तुलना में अधिक शक्तिशाली सुपरसेट है, और मैं इसे Go2 में देखूंगा। मेरे दृष्टिकोण से, अगले 5 वर्षों में Go2 के होने की संभावना बहुत कम है, और मैं कुछ कम समय सीमा में कुछ घटित होते हुए देखना चाहूंगा।

यदि एक नए आरक्षित खोजशब्द का मेरा प्रस्ताव enum BC के लिए असंभव है, तो इसे लागू करने के और भी तरीके हैं, चाहे वह एक पूर्ण भाषा एकीकरण हो या go vet में निर्मित टूलिंग। जैसा कि मैंने मूल रूप से कहा था, मैं वाक्य रचना पर विशेष नहीं हूं, लेकिन मेरा दृढ़ विश्वास है कि यह नए उपयोगकर्ताओं के लिए एक महत्वपूर्ण संज्ञानात्मक बोझ जोड़े बिना आज गो के लिए एक मूल्यवान अतिरिक्त होगा।

गो 2 से पहले एक नया कीवर्ड संभव नहीं है। यह गो 1 संगतता गारंटी का स्पष्ट उल्लंघन होगा।

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

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

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

दूसरी तरफ, अगर मैं उसी एपीआई के लिए सर्वर साइड लिख रहा हूं, तो एनम पर एक स्विच स्टेटमेंट लिखने में सक्षम होना अच्छा होगा, जो एक कंपाइलर एरर (या कम से कम कुछ go vet ) को फेंक देगा। default: मौजूद है)।

मुझे लगता है कि यह (एनम्स) एक ऐसा क्षेत्र है जहां स्विफ्ट वास्तव में सही है ।

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

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

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

Enums हर स्थिति के लिए सही नहीं हैं, लेकिन वे कुछ के लिए बहुत अच्छे हैं! अधिकांश स्थितियों में उचित संस्करण और त्रुटि प्रबंधन नए मूल्यों को संभालने में सक्षम होना चाहिए।

बाहरी प्रक्रियाओं से निपटने के लिए उह-ओह राज्य होना निश्चित रूप से जरूरी है।

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

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

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

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

और मैं यह नहीं देखता कि इसे सिर्फ एक पशु चिकित्सक द्वारा क्यों हल नहीं किया जा सकता है; आपको संपूर्ण मामलों की पूरी तरह से उपयुक्त स्थैतिक जाँच देना और मुझे क्रमिक मरम्मत की संभावना देना।

मैं एक सर्वर एपीआई के लिए क्लाइंट को लागू करने के साथ खेल रहा हूं। कुछ तर्क और वापसी मूल्य एपीआई में एनम हैं। कुल 45 एनम प्रकार हैं।

गो में एन्यूमरेटेड स्थिरांक का उपयोग करना मेरे मामले में संभव नहीं है क्योंकि विभिन्न एनम प्रकारों के कुछ मान समान नाम साझा करते हैं। नीचे दिए गए उदाहरण में, Destroy दो बार प्रकट होता है इसलिए संकलक त्रुटि Destroy redeclared in this block जारी करेगा।

type TaskAllowedOperations int
const (
    _ TaskAllowedOperations = iota
    Cancel
    Destroy
)

type OnNormalExit int
const (
    _ OnNormalExit = iota
    Destroy
    Restart
)

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

@kongslund मुझे पता है कि यह एक पूर्ण कार्यान्वयन नहीं है, लेकिन मैंने अभी एक कोड जनरेटर बनाया है जो आपके लिए रुचिकर हो सकता है। इसके लिए केवल यह आवश्यक है कि आप टाइप डिक्लेरेशन के ऊपर एक टिप्पणी में अपना एनम घोषित करें और बाकी आपके लिए उत्पन्न करें।

// ENUM(_, Cancel, Destroy)
type TaskAllowedOperations int

// ENUM(_, Destroy, Restart)
type OnNormalExit int

उत्पन्न करेगा

const(
  _ TaskAllowedOperations = iota
  TaskAllowedOperationsCancel
  TaskAllowedOperationsDestroy
)

const(
  _ OnNormalExit = iota
  OnNormalExitDestroy
  OnNormalExitRestart
)

बेहतर हिस्सा यह है कि यह String() विधियों को उत्पन्न करेगा जो उनमें उपसर्ग को बाहर कर देगा, जिससे आप "Destroy" को TaskAllowedOperations या OnNormalExit $ के रूप में पार्स कर सकते हैं।

https://github.com/abice/go-enum

अब जब प्लग रास्ते से बाहर हो गया है ...

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

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

• परिचयात्मक उदाहरण (एनम्स इन गो टुडे) भ्रामक है: वह कोड उत्पन्न होता है और लगभग कोई भी इस तरह से गो कोड को हाथ से नहीं लिखेगा। वास्तव में, सुझाव (भाषा समर्थन के साथ यह कैसा दिख सकता है) गो में हम वास्तव में पहले से क्या कर रहे हैं, के बहुत करीब है।

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

• भाषा सुविधाओं की उपयोगिता के बारे में @ianlancetaylor की बात को हल्के में नहीं लिया जाना चाहिए। उपयोगी सुविधाओं का एक गजियन है; सवाल यह है कि कौन से वास्तव में सम्मोहक हैं और उनकी लागत के लायक हैं (भाषा की अतिरिक्त जटिलता और इस प्रकार पठनीयता, और कार्यान्वयन)।

• एक मामूली बिंदु के रूप में, गो में कोटा-परिभाषित स्थिरांक निश्चित रूप से इनट्स तक ही सीमित नहीं हैं। जब तक वे स्थिरांक हैं तब तक वे (संभवतः नामित) मूल प्रकारों (फ्लोट्स, बूलियन्स, स्ट्रिंग्स: https://play.golang.org/p/lhd3jqqg5z) तक सीमित हैं।

• @merovius (स्थिर!) संकलन-समय जांच की सीमाओं के बारे में अच्छे अंक बनाता है। मुझे बहुत संदेह है कि जिन गणनाओं को बढ़ाया नहीं जा सकता है, वे उन स्थितियों में उपयुक्त हैं जहां विस्तार वांछनीय या अपेक्षित है (कोई भी लंबे समय तक रहने वाली एपीआई सतह समय के साथ विकसित होती है)।

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

1) प्रस्तावित के रूप में एनमों के लिए वास्तविक अपेक्षाएँ क्या हैं? @bep में गणनशीलता, पुनरावृत्ति, स्ट्रिंग अभ्यावेदन, पहचान का उल्लेख है। क्या यहां और है? कम है?

2) सूची को 1 में मानते हुए), क्या एनमों को बढ़ाया जा सकता है? यदि हां, तो कैसे? (उसी पैकेज में? दूसरा पैकेज?) अगर उन्हें बढ़ाया नहीं जा सकता, तो क्यों नहीं? व्यवहार में यह समस्या क्यों नहीं है?

3) नेमस्पेस: स्विफ्ट में, एक एनम प्रकार एक नया नेमस्पेस पेश करता है। महत्वपूर्ण मशीनरी (वाक्यविन्यास चीनी, प्रकार कटौती) है कि नामस्थान नाम को हर जगह दोहराया नहीं जाना चाहिए। उदाहरण के लिए, एक एनम महीने के एनम मूल्यों के लिए, सही संदर्भ में, कोई भी लिख सकता है। महीना के बजाय जनवरी। जनवरी (या इससे भी बदतर, MyPackage.Month.Janary)। क्या एक एनम नेमस्पेस की जरूरत है? यदि हां, तो एक एनम नेमस्पेस कैसे बढ़ाया जाता है? इस कार्य को व्यवहार में लाने के लिए किस प्रकार की वाक्यात्मक शर्करा की आवश्यकता है?

4) क्या एनम मान स्थिरांक हैं? अपरिवर्तनीय मूल्य?

5) एनम वैल्यू पर किस तरह के ऑपरेशन संभव हैं (जैसे, पुनरावृत्ति के अलावा): क्या मैं एक को आगे, एक को पीछे की ओर ले जा सकता हूं? क्या इसके लिए अतिरिक्त अंतर्निहित कार्यों या ऑपरेटरों की आवश्यकता है? (सभी पुनरावृत्तियां क्रम में नहीं हो सकती हैं)। क्या होता है यदि कोई अंतिम एनम मूल्य से आगे बढ़ता है? क्या यह रनटाइम त्रुटि है?

(मैंने https://github.com/golang/go/issues/19814#issuecomment-322771922 में अगले पैराग्राफ के अपने वाक्यांश को सही कर दिया है। नीचे दिए गए शब्दों के लापरवाह चयन के लिए खेद है।)

वास्तव में इन सवालों के जवाब देने की कोशिश किए बिना यह प्रस्ताव निरर्थक है ("मैं चाहता हूं कि एनम जो मैं चाहता हूं वह करें" एक प्रस्ताव नहीं है)।

वास्तव में इन सवालों के जवाब देने की कोशिश किए बिना यह प्रस्ताव निरर्थक है

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

• गो को इस प्रस्ताव की जरूरत थी क्योंकि इसने एक बहुत जरूरी चर्चा => मूल्य और अर्थ शुरू किया था
• यदि यह प्रस्ताव #21473 => मूल्य और अर्थ की ओर भी ले जाता है

परिचयात्मक उदाहरण (एनम्स इन गो टुडे) भ्रामक है: वह कोड उत्पन्न होता है और लगभग कोई भी इस तरह से गो कोड को हाथ से नहीं लिखेगा। वास्तव में, सुझाव (भाषा समर्थन के साथ यह कैसा दिख सकता है) गो में हम वास्तव में पहले से क्या कर रहे हैं, के बहुत करीब है।

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

// ACLRole is the level of access to grant.
type ACLRole string

const (
    RoleOwner  ACLRole = "OWNER"
    RoleReader ACLRole = "READER"
    RoleWriter ACLRole = "WRITER"
)

वे एक ही रचना का प्रयोग अनेक स्थानों पर करते हैं।
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/bigquery/table.go#L78 -L116
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/storage/acl.go#L27 -L49

बाद में इस बारे में कुछ चर्चा हुई कि यदि आप iota का उपयोग करके ठीक हैं तो आप चीजों को और अधिक संक्षिप्त कैसे बना सकते हैं, जो अपने आप में उपयोगी हो सकता है, लेकिन सीमित उपयोग के मामले के लिए। अधिक जानकारी के लिए मेरी पिछली टिप्पणी देखें। https://github.com/golang/go/issues/19814#issuecomment -290948187

@bep फेयर पॉइंट; शब्दों के अपने लापरवाह चुनाव के लिए मैं क्षमा चाहता हूँ। मुझे फिर से प्रयास करने दें, उम्मीद है कि इस बार मेरे पिछले पैराग्राफ को और अधिक सम्मानपूर्वक और स्पष्ट रूप से वाक्यांशित करें:

सार्थक प्रगति करने में सक्षम होने के लिए, मेरा मानना ​​​​है कि इस प्रस्ताव के समर्थकों को इस बारे में थोड़ा और सटीक होने की कोशिश करनी चाहिए कि वे क्या मानते हैं कि एनम की महत्वपूर्ण विशेषताएं हैं (उदाहरण के लिए https://github में कुछ सवालों के जवाब देकर। com/golang/go/issues/19814#issuecomment-322752526)। चर्चा से अब तक वांछित विशेषताओं को केवल काफी अस्पष्ट वर्णित किया गया है।

शायद पहले कदम के रूप में, केस स्टडीज के लिए वास्तव में उपयोगी होगा जो दिखाता है कि मौजूदा गो कैसे गिरता है (काफी) छोटा है और कैसे एनम्स किसी समस्या को बेहतर/तेज/स्पष्ट रूप से हल करेगा, आदि। गोफरकॉन पर @rsc की उत्कृष्ट बातचीत भी देखें Go2 भाषा परिवर्तन के संबंध में।

@derekperkins मैं उन (टाइप की गई) निरंतर परिभाषाओं को बुलाऊंगा, न कि एनम। मैं अनुमान लगा रहा हूं कि हमारी असहमति एक "एनम" की एक अलग समझ के कारण है, इसलिए ऊपर मेरे प्रश्न हैं।

(मेरा पिछला https://github.com/golang/go/issues/19814#issuecomment-322774830 निश्चित रूप से @derekperkins को जाना चाहिए था, @ derekparker को नहीं। स्वतः पूर्ण ने मुझे हरा दिया।)

@derekperkins टिप्पणी से देखते हुए, और आंशिक रूप से मेरे अपने प्रश्नों का उत्तर देते हुए, मैं इकट्ठा करता हूं कि एक गो "एनम" में कम से कम निम्नलिखित गुण होने चाहिए:

• एक (नए) प्रकार के तहत मूल्यों के एक समूह को समूहित करने की क्षमता
• न्यूनतम वाक्य-विन्यास ओवरहेड या बॉयलरप्लेट के साथ उस प्रकार के नाम (और संबंधित मान, यदि कोई हो) घोषित करना आसान बनाएं
• आरोही घोषणा क्रम में इन मूल्यों के माध्यम से पुनरावृति करने की क्षमता

क्या यह सही लगता है? यदि हां, तो इस सूची में और क्या जोड़ने की आवश्यकता है?

आपके सभी प्रश्न अच्छे हैं।

प्रस्तावित के रूप में एनम के लिए वास्तविक अपेक्षाएं क्या हैं? @bep में गणनशीलता, पुनरावृत्ति, स्ट्रिंग अभ्यावेदन, पहचान का उल्लेख है। क्या यहां और है? कम है?

सूची को 1 में मानते हुए), क्या एनमों को बढ़ाया जा सकता है? यदि हां, तो कैसे? (उसी पैकेज में? दूसरा पैकेज?) अगर उन्हें बढ़ाया नहीं जा सकता, तो क्यों नहीं? व्यवहार में यह समस्या क्यों नहीं है?

मुझे नहीं लगता कि दो कारणों से एनमों को बढ़ाया जा सकता है:

1. Enums को स्वीकार्य मूल्यों की पूरी श्रृंखला का प्रतिनिधित्व करना चाहिए, इसलिए उन्हें विस्तारित करने का कोई मतलब नहीं है।
2. जैसे सामान्य गो प्रकारों को बाहरी पैकेजों में विस्तारित नहीं किया जा सकता है, यह समान यांत्रिकी और डेवलपर अपेक्षाओं को बनाए रखता है

नेमस्पेस: स्विफ्ट में, एक एनम प्रकार एक नया नामस्थान पेश करता है। महत्वपूर्ण मशीनरी (वाक्यविन्यास चीनी, प्रकार कटौती) है कि नामस्थान नाम को हर जगह दोहराया नहीं जाना चाहिए। उदाहरण के लिए, एक एनम महीने के एनम मूल्यों के लिए, सही संदर्भ में, कोई भी लिख सकता है। महीना के बजाय जनवरी। जनवरी (या इससे भी बदतर, MyPackage.Month.Janary)। क्या एक एनम नेमस्पेस की जरूरत है? यदि हां, तो एक एनम नेमस्पेस कैसे बढ़ाया जाता है? इस कार्य को व्यवहार में लाने के लिए किस प्रकार की वाक्यात्मक शर्करा की आवश्यकता है?

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

क्या एनम मान स्थिरांक हैं? अपरिवर्तनीय मूल्य?

मुझे लगता है कि स्थिरांक।

एनम मूल्यों पर किस तरह के संचालन संभव हैं (कहते हैं, पुनरावृत्ति के अलावा): क्या मैं एक को आगे, एक को पीछे की ओर ले जा सकता हूं? क्या इसके लिए अतिरिक्त अंतर्निहित कार्यों या ऑपरेटरों की आवश्यकता है? (सभी पुनरावृत्तियां क्रम में नहीं हो सकती हैं)। क्या होता है यदि कोई अंतिम एनम मूल्य से आगे बढ़ता है? क्या यह रनटाइम त्रुटि है?

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

एक एनम को अमान्य मान निर्दिष्ट करने के कारण एक नई रनटाइम त्रुटि (घबराहट?) होगी, चाहे वह प्रत्यक्ष असाइनमेंट या टाइप कास्टिंग के माध्यम से हो।

यदि मैं इसे सही ढंग से संक्षेप में प्रस्तुत करता हूं तो आपके द्वारा प्रस्तावित मूल्यों को टाइप किए गए स्थिरांक की तरह हैं (और स्थिरांक की तरह उनके पास उपयोगकर्ता द्वारा परिभाषित स्थिर मान हो सकते हैं) लेकिन:

• वे एक ही घोषणा में एनम मानों से जुड़े एनम प्रकार को भी परिभाषित करते हैं (अन्यथा वे केवल स्थिरांक हैं)
• इसकी घोषणा के बाहर किसी मौजूदा एनम प्रकार का एनम मान डालना/बनाना असंभव है
• उन पर पुनरावृति संभव है

क्या यह सही लग रहा है? (यह क्लासिक दृष्टिकोण भाषाओं से मेल खाएगा, जो लगभग 45 साल पहले पास्कल द्वारा अग्रणी, एनम की ओर ले गए थे)।

हां, ठीक यही मैं प्रस्तावित कर रहा हूं।

स्विच-स्टेटमेंट के बारे में क्या? एआईयूआई जो प्रस्ताव के मुख्य चालकों में से एक है।

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

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

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

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

@derekperkins कुछ और प्रश्न:

• एनम प्रकार के एक चर के लिए शून्य मान क्या है जिसे स्पष्ट रूप से प्रारंभ नहीं किया गया है? मुझे लगता है कि यह सामान्य रूप से शून्य नहीं हो सकता है (जो स्मृति आवंटन/प्रारंभिकरण को जटिल बनाता है)।

• क्या हम एनम मूल्यों के साथ सीमित अंकगणित कर सकते हैं? उदाहरण के लिए, पास्कल में (जिसमें मैंने एक बार प्रोग्राम किया था, जिस तरह से वापस कब), चरणों में पुनरावृति करना आश्चर्यजनक रूप से आवश्यक था> 1. और कभी-कभी कोई एनम मान की गणना करना चाहता था।

• पुनरावृति के संबंध में, गो जनरेट किए गए पुनरावृति (और कड़े) समर्थन पर्याप्त क्यों नहीं है?

एनम प्रकार के एक चर के लिए शून्य मान क्या है जिसे स्पष्ट रूप से प्रारंभ नहीं किया गया है? मुझे लगता है कि यह सामान्य रूप से शून्य नहीं हो सकता है (जो स्मृति आवंटन/प्रारंभिकरण को जटिल बनाता है)।

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

क्या हम एनम मूल्यों के साथ सीमित अंकगणित कर सकते हैं? उदाहरण के लिए, पास्कल में (जिसमें मैंने एक बार प्रोग्राम किया था, जिस तरह से वापस कब), चरणों में पुनरावृति करना आश्चर्यजनक रूप से आवश्यक था> 1. और कभी-कभी कोई एनम मान की गणना करना चाहता था।

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

पुनरावृति के संबंध में, गो जनरेट किए गए पुनरावृति (और कड़े) समर्थन पर्याप्त क्यों नहीं है?

व्यक्तिगत रूप से पुनरावृत्ति मेरा मुख्य उपयोग मामला नहीं है, हालांकि मुझे लगता है कि यह प्रस्ताव के लिए मूल्य जोड़ता है। यदि वह ड्राइविंग कारक होता, तो शायद go generate पर्याप्त होता। यह मूल्य सुरक्षा की गारंटी में मदद नहीं करता है। Stringer() तर्क मानता है कि कच्चा मूल्य iota या int या "वास्तविक" मान का प्रतिनिधित्व करने वाला कोई अन्य प्रकार होने वाला है। आपको (Un)MarshalJSON , (Un)MarshalBinary , Scanner/Valuer और किसी भी अन्य क्रमांकन विधियों को भी उत्पन्न करना होगा जिनका उपयोग आप यह सुनिश्चित करने के लिए कर सकते हैं कि Stringer मूल्य का उपयोग बनाम संचार के लिए किया गया था। गो आंतरिक रूप से जो कुछ भी उपयोग करता है।

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

@मेरोवियस से https://github.com/golang/go/issues/19814#issuecomment -290969864

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

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

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

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

@derekperkins अधिकांश अन्य API परिवर्तनों को क्रमिक मरम्मत के लिए व्यवस्थित किया जा सकता है। मैं वास्तव में Russ Cox विवरण पढ़ने की सलाह देता हूं, यह बहुत सी चीजों को बहुत स्पष्ट करता है।

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

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

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

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

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

बंद (कंपाइलर-चेक के लिए थकावट) के साथ यह संभव नहीं है।

@Merovius यदि थकावट की जाँच go vet या इसी तरह के टूलिंग द्वारा की गई थी जैसा कि @jediorange द्वारा सुझाया गया था बनाम कंपाइलर द्वारा लागू किया गया था, तो क्या यह आपकी चिंताओं को कम करेगा?

@derekperkins उनकी हानिकारकता के बारे में, हाँ। उनकी उपयोगिता की कमी के बारे में नहीं। संस्करण-तिरछा के समान मुद्दे अधिकांश उपयोग के मामलों के लिए भी होते हैं जिन्हें वे आमतौर पर (syscalls, नेटवर्क प्रोटोकॉल, फ़ाइल स्वरूप, साझा ऑब्जेक्ट…) के लिए माना जाता है। एक कारण है कि प्रोटो 3 को खुले एनम की आवश्यकता होती है और प्रोटो 2 के लिए नहीं - यह कई आउटेज और डेटा भ्रष्टाचार की घटनाओं से सीखा गया सबक है। भले ही Google पहले से ही वर्जन स्क्यू से बचने के लिए काफी सावधान है। मेरे दृष्टिकोण से, डिफ़ॉल्ट मामलों के साथ खुले एनम सिर्फ सही समाधान हैं। और अवैध मूल्यों के खिलाफ कथित सुरक्षा के अलावा, वे वास्तव में मेज पर बहुत कुछ नहीं लाते हैं, जो मैं बता सकता हूं।

यह सब कहा जा रहा है, मैं निर्णायक नहीं हूं।

@derekperkins https://github.com/golang/go/issues/19814#issuecomment -322818206 में आप इसकी पुष्टि कर रहे हैं (आपके दृष्टिकोण से):

• एक एनम घोषणा नामित एनम मूल्यों (स्थिरांक) के साथ एक एनम प्रकार की घोषणा करती है
• उन पर पुनरावृति संभव है
• इसकी घोषणा के बाहर एनम में कोई मूल्य नहीं जोड़ा जा सकता है
  और बाद में: एनम पर एक स्विच संपूर्ण होना चाहिए (या शायद नहीं हो सकता है) संपूर्ण (कम महत्वपूर्ण लगता है)

https://github.com/golang/go/issues/19814#issuecomment -322895247 में आप कह रहे हैं कि:

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

और https://github.com/golang/go/issues/19814#issuecomment -322903714 में आप कह रहे हैं कि "उन्हें संपादित करने की क्षमता इस प्रस्ताव का एक महत्वपूर्ण हिस्सा है"।

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

https://github.com/golang/go/issues/19814#issuecomment -322903714 में आप कह रहे हैं कि एनम को 0-आधारित सरणी के रूप में लागू किया जा सकता है। इससे पता चलता है कि एक एनम घोषणा एनम नामों की एक क्रमबद्ध सूची के साथ एक नए प्रकार का परिचय देती है जो कि एनम मानों की एक सरणी में 0-आधारित स्थिर सूचकांक हैं (जिसके लिए स्थान स्वचालित रूप से आरक्षित है)। क्या यही मतलब है तुम्हारा? यदि हां, तो इसके साथ जाने के लिए केवल एक निश्चित आकार सरणी और स्थिरांक सूचकांकों की एक सूची घोषित करने के लिए पर्याप्त क्यों नहीं होगा? सरणी सीमा जांच स्वचालित रूप से सुनिश्चित करेगी कि आप एनम रेंज को "विस्तारित" नहीं कर सकते हैं, और पुनरावृत्ति पहले से ही संभव होगी।

मैं क्या खो रहा हूँ?

मैं उलझन में हूं: तो पुनरावृत्ति प्राथमिक प्रेरक नहीं है, ठीक है।

मेरे अपने कारण हैं कि मैं एनम क्यों चाहता हूं, साथ ही यह भी ध्यान में रखने की कोशिश कर रहा हूं कि इस धागे में @bep और अन्य सहित, प्रस्ताव के आवश्यक भागों के रूप में व्यक्त किया गया है।

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

जब मैं उन्हें संपादित करने के लिए कहता हूं, तो यह @Merovius की बात है कि वे खुले दुश्मन हैं। निर्माण समय पर स्थिर, लेकिन हमेशा के लिए बंद नहीं।

# 19814 (टिप्पणी) में आप कह रहे हैं कि एनम को 0-आधारित सरणी के रूप में लागू किया जा सकता है।

यह सिर्फ मैं अपने वेतन से परे अनुमान लगा रहा हूं कि मैं कैसे कल्पना करता हूं कि इसे आपके https://github.com/golang/go/issues/19814#issuecomment -322884746 और @ianlancetaylor के https के आधार पर पर्दे के पीछे लागू किया जा सकता है: //github.com/golang/go/issues/19814#issuecomment -322899668

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

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

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

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

किसी और के लिए जिसने रुचि व्यक्त की है, कृपया बेझिझक इसमें शामिल हों।

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

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

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

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

क्या इसका कोई मतलब है?

@griesemer यह पूरी तरह से समझ में आता है और मैं उस बार को पारित करने के लिए समझता हूं जिसे @rsc ने गोफरकॉन में बात की थी। आप स्पष्ट रूप से मेरी तुलना में कहीं अधिक गहरी समझ रखते हैं। #21473 में, आपने उल्लेख किया था कि वर्र्स के लिए आईओटा लागू नहीं किया गया था क्योंकि उस समय कोई सम्मोहक उपयोग मामला नहीं था। क्या यही कारण है कि enum को शुरू से ही शामिल नहीं किया गया था? मुझे आपकी राय जानने में बहुत दिलचस्पी होगी कि क्या यह गो के लिए मूल्य जोड़ देगा या नहीं, और यदि ऐसा होता है, तो आप प्रक्रिया कहां से शुरू करेंगे?

@derekperkins https://github.com/golang/go/issues/19814#issuecomment -323144075 में आपके प्रश्न के संबंध में: उस समय (गो के डिज़ाइन में) हम केवल अपेक्षाकृत सरल (पास्कल या सी-स्टाइल कहें) एनम्स पर विचार कर रहे थे। मुझे सभी विवरण याद नहीं हैं लेकिन निश्चित रूप से एक भावना थी कि एनम के लिए आवश्यक अतिरिक्त मशीनरी के लिए पर्याप्त लाभ नहीं था। हमने महसूस किया कि वे अनिवार्य रूप से निरंतर घोषणाओं का महिमामंडन करते थे।

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

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

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

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

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

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

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

मुझे लगता है कि विहित तरीका गो आज एनम करता है (जैसा कि https://github.com/golang/go/issues/19814#issuecomment-290909885 में देखा गया है) सही के काफी करीब है।
कुछ कमियां हैं:

1. उन्हें पुनरावृत्त नहीं किया जा सकता है
2. उनका कोई स्ट्रिंग प्रतिनिधित्व नहीं है
3. ग्राहक फर्जी एनम मान पेश कर सकते हैं

मैं # 1 के बिना ठीक हूँ।
गो: जनरेट + स्ट्रिंगर का उपयोग # 2 के लिए किया जा सकता है। यदि वह आपके उपयोग के मामले को संभाल नहीं पाता है, तो अपने "एनम" के मूल प्रकार को एक int के बजाय एक स्ट्रिंग बनाएं, और स्ट्रिंग निरंतर मानों का उपयोग करें।

3 आज के गो के साथ संभालना कठिन है। मेरे पास एक मूर्खतापूर्ण प्रस्ताव है जो इसे अच्छी तरह से संभाल सकता है।

एक प्रकार की परिभाषा में explicit कीवर्ड जोड़ें। यह कीवर्ड उस पैकेज में कॉन्स्टेबल ब्लॉक में रूपांतरणों को छोड़कर इस प्रकार के रूपांतरणों को रोकता है जिसमें उस प्रकार को परिभाषित किया गया है। (या restricted ? या शायद enum का अर्थ explicit type है?)

मैंने ऊपर उल्लिखित उदाहरण का पुन: उपयोग किया,

//go:generate stringer -type=SearchRequest
explicit type SearchRequest int

const (
    Universal SearchRequest = iota
    Web
    Images
    Local
    News
    Products
    Video
)

const ब्लॉक के अंदर int से SearchRequest तक के रूपांतरण हैं। लेकिन केवल पैकेज लेखक एक नया SearchRequest मान पेश कर सकता है, और गलती से एक को पेश करने की संभावना नहीं होगी (उदाहरण के लिए SearchRequest की अपेक्षा करने वाले फ़ंक्शन में int पास करके)।

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

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

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

मैं कुछ परिस्थितियों में स्पष्ट प्रकार के रूपांतरणों को मना करने के लिए गो के लिए एक तरीके पर विचार करने को तैयार हूं

@ianlancetaylor वैकल्पिक रूप से प्रकार के रूपांतरणों को अस्वीकार करना, चाहे स्पष्ट या निहित हो, उन मुद्दों को हल करेगा जिनके कारण मुझे यह प्रस्ताव पहली जगह में बनाना पड़ा। केवल मूल पैकेज ही किसी भी प्रकार को बनाने और इस प्रकार संतुष्ट करने में सक्षम होगा। यह कुछ मायनों में enum समाधान से भी बेहतर है क्योंकि यह न केवल const घोषणाओं का समर्थन करता है, बल्कि किसी भी प्रकार का।

@ Randall77 , @ianlancetaylor उस प्रकार के शून्य मान के साथ explicit सुझाव कैसे काम करेगा?

@derekperkins प्रकार-रूपांतरणों को पूरी तरह से अस्वीकार करने से encoding/* पैकेज जैसे जेनेरिक एन्कोडर/डिकोडर्स में इन प्रकारों का उपयोग करना असंभव हो जाएगा।

@Merovius मुझे लगता है कि @ianlancetaylor केवल निहित रूपांतरणों के लिए प्रतिबंध का सुझाव देता है (उदाहरण के लिए, एक प्रतिबंधित प्रकार के लिए एक अपरिवर्तित स्थिरांक का असाइनमेंट)। स्पष्ट रूपांतरण अभी भी संभव होगा।

@griesemer मुझे पता है :) लेकिन मैं @derekperkins को अलग तरह से सुझाव देने के लिए समझ गया।

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

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

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

@griesemer @Merovius मैं फिर से @ianlancetaylor के उद्धरण को दोबारा पोस्ट करूंगा, क्योंकि यह उनका सुझाव था, मेरा नहीं।

मैं कुछ परिस्थितियों में स्पष्ट प्रकार के रूपांतरणों को मना करने के लिए गो के लिए एक तरीके पर विचार करने को तैयार हूं

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

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

1. Enums केवल आधार प्रकारों (स्ट्रिंग, uint, int, rune, आदि) में निहित हैं। यदि कोई आधार प्रकार आवश्यक नहीं है, तो यह डिफ़ॉल्ट रूप से uint हो सकता है?
2. Enum के सभी मान्य मानों को प्रकार की घोषणा के साथ घोषित किया जाना चाहिए - स्थिरांक। अमान्य (प्रकार की घोषणा में घोषित नहीं) मानों को एनम प्रकार में परिवर्तित नहीं किया जा सकता है।
3. डिबगिंग के लिए स्वचालित स्ट्रिंग प्रतिनिधित्व (अच्छा है)।
4. Enum पर स्विच स्टेटमेंट में थकावट के लिए संकलन-समय की जाँच। वैकल्पिक रूप से ( go vet ? के माध्यम से) एक default मामले की अनुशंसा करें, भले ही भविष्य के परिवर्तनों के लिए पहले से ही संपूर्ण (एक त्रुटि की संभावना) हो।
5. शून्य मान अनिवार्य रूप से अमान्य होना चाहिए (एनम घोषणा में कुछ नहीं)। मैं व्यक्तिगत रूप से इसे nil होना चाहूंगा, जैसे एक टुकड़ा करता है।

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

जहां तक ​​पुनरावृति का सवाल है, मुझे नहीं लगता कि मैं कभी इसका इस्तेमाल करूंगा, लेकिन मुझे इसमें कोई नुकसान नहीं दिख रहा है।

इसे कैसे घोषित किया जा सकता है इसका एक उदाहरण के रूप में:

type MetadataBlockType enum[uint] {
    StreamInfo:    0
    Padding:       1
    Application:   2
    SeekTable:     3
    VorbisComment: 4
    CueSheet:      5
    Picture:       6
}

इसके अलावा, प्रकार का अनुमान लगाने और "डॉट सिंटैक्स" का उपयोग करने की स्विफ्ट शैली _nice_ होगी, लेकिन निश्चित रूप से आवश्यक नहीं है।

EnumA int . टाइप करें
स्थिरांक (
अज्ञात EnumA = iota
एएए
)

EnumB int . टाइप करें
स्थिरांक (
अज्ञात EnumB = iota
बीबीबी
)

कोड के 2 टुकड़े एक ही गो फ़ाइल में मौजूद नहीं हो सकते हैं, न ही एक ही पैकेज, और न ही एक दूसरे पैकेज से आयात किया जाता है।

कृपया Enum को लागू करने के C# तरीके को लागू करें:
टाइप डेज एनम {शनि, सूर्य, सोम, मंगल, बुध, गुरु, शुक्र}
टाइप डेज एनम [इंट] { शनि: 1 , सूर्य, मंगल, बुध, गुरु, शुक्र}
टाइप डेज़ एनम [स्ट्रिंग] {शनि: "शनिवार", सूर्य: "रविवार" आदि}

@KamyarM यह कैसे बेहतर है

type Days int
const (
  Sat Days = 1+iota
  Sun
  ...
)

तथा

type Days string
const (
  Sat Days = "Saturday"
  Sun      = "Sunday"
  ...
)

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

यह बेहतर है क्योंकि इसमें नामकरण विवाद का मुद्दा नहीं है। संकलक प्रकार की जाँच का भी समर्थन करें। आपके द्वारा उल्लिखित दृष्टिकोण ने इसे कुछ भी नहीं से बेहतर तरीके से व्यवस्थित किया है, लेकिन संकलक आपको उस पर प्रतिबंधित नहीं करता है जिसे आप इसे असाइन कर सकते हैं। आप एक पूर्णांक निर्दिष्ट कर सकते हैं जो उस प्रकार की किसी वस्तु के लिए कोई दिन नहीं है:
वर एक दिन
ए = 10
कंपाइलर वास्तव में इसके बारे में कुछ नहीं करता है। तो इस तरह के एनम का ज्यादा मतलब नहीं है। इसके अलावा GoLand जैसे IDE में बेहतर तरीके से व्यवस्थित है

मैं कुछ ऐसा देखना चाहूंगा

type WeekDay enum string {
  Monday "mon"
  Tuesday "tue"
  // etc...
}

या स्वचालित iota उपयोग के साथ:

// this assumes that iota automatically assigned to the first declared enum key
// and values have unsigned integer type
// value is positional, so if you decide to rename your key 
// you don't have to change everything in db
// also it is easy to grow your lists
type WeekDay enum {
  Monday
  Tuesday
}

यह उपयोग में सरलता और सुगमता प्रदान करेगा:

func makeItWorkOn(day WeekDay) {
  // your implementation
}

इसके अलावा, एनम में मूल्य को मान्य करने के लिए बिल्टिन विधि होनी चाहिए ताकि हम उपयोगकर्ता इनपुट से कुछ मान्य कर सकें:

if day in WeekDay {
  makeItWorkOn(day)
}

और साधारण चीजें जैसे:

if day == WeekDay.Monday {
 // whatever
}

ईमानदार होने के लिए, मेरा पसंदीदा सिंटैक्स इस तरह होगा (KISS):

// type automatically inferred from values or `iota`
enum WeekDay {
  Monday "mon"
  Tuesday "tue"
}

@zoonman अंतिम उदाहरण गो के निम्नलिखित सिद्धांत का पालन नहीं करता है: एक फ़ंक्शन घोषणा func से शुरू होती है, एक प्रकार की घोषणा type से शुरू होती है, एक परिवर्तनीय घोषणा var से शुरू होती है ,...

@ md2perpe मैं गो "टाइप" सिद्धांतों का पालन करने की कोशिश नहीं कर रहा हूं, मैं हर रोज कोड लिख रहा हूं और केवल एक ही सिद्धांत का पालन करता हूं - चीजों को सरल रखें।
जितना अधिक कोड आपको लिखना होगा _सिद्धांतों का पालन करना_ तब अधिक समय बर्बाद होता है।
टीबीएच मैं नौसिखिया हूं लेकिन ऐसी बहुत सी चीजें हैं जिनकी मैं आलोचना कर सकता हूं।
उदाहरण के लिए:

struct User {
  Id uint
  Email string
}

लिखने और समझने में आसान है

type User struct {
  Id uint
  Email string
}

मैं आपको उदाहरण दे सकता हूं जहां प्रकार का उपयोग किया जाना चाहिए:

// this is terrible because it blows your mind off
// especially if you Go newbie
// this should not be allowed by compiler/linter:
w := map[string]interface{}{"type": 0, "connected": true}

// it has to be splitted into type definition
type WeirdJSON map[string]interface{}

// and used like
w := WeirdJSON{"type": 0, "connected": true}

मैं Asm, C, C++, Pascal, Perl, PHP, Ruby, Python, JavaScript, TypeScript, अब Go में कोड लिखता था। मैंने वह सब देखा। यह अनुभव मुझे बताता है कि कोड संक्षिप्त, पढ़ने और समझने में आसान होना चाहिए ।

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

const (
        SMTPE0 int8 = ((-24 - (1 + (iota - 1) * 3) % 6 * (iota - 1) / ((iota - 1) | 0x01)) - 10 * ((iota - 1) % 2) - 5 * (iota / 3 - iota / 4) ) * iota / (iota | 0x01)
    SMTPE24 
    SMTPE25
    SMTPE29
    SMTPE30
)
const (
   _SMTPE0 int8 = 0 
   _SMTPE24 int8 = -24
   _SMTPE25 int8 = -25
   _SMTPE29 int8 = -29
   _SMTPE30 int8 = -30
)

बेशक मुझे रक्षात्मक प्रोग्रामिंग के साथ कुछ रनटाइम चेक की आवश्यकता हो सकती है ...

func IsSMTPE(status int8) bool {
    j := 4
    for i:= 0; i >= -30; i -= j % 6{
        if i == int(status){ 
            return true
        }
        j+=3
    }

    return status == 0
}

खेल का मैदान रेफरी

Enums कुछ मामलों में प्रोग्रामर को और अधिक सरल बनाते हैं। Enums सिर्फ एक उपकरण है तो आप इसे ठीक से उपयोग कर सकते हैं यह समय की बचत कर सकता है और उत्पादकता बढ़ा सकता है। मुझे लगता है कि इसे गो 2 में लागू करने में कोई समस्या नहीं है जैसे सी ++, सी # या अन्य लैंग्स में। यह उदाहरण सिर्फ एक मजाक है, लेकिन यह समस्या को स्पष्ट रूप से दिखाता है।

@ स्ट्रीटर 12 मैं नहीं देखता कि आपका उदाहरण "समस्या को स्पष्ट रूप से कैसे दिखाता है"। एनम इस कोड को कैसे बेहतर या सुरक्षित बनाएंगे?

एनम के समान तर्क के कार्यान्वयन के साथ सी # वर्ग है।

 public enum SMTPE : sbyte
   {
        SMTPE0 = 0,
        SMTPE24 = -24,
        SMTPE25 = -25,
        SMTPE29 = -29,
        SMTPE30 = -30
   }

   public class TestClass
   {
        public readonly SMTPE smtpe;

        public TestClass(SMTPE smtpe)
        {
            this.smtpe = smtpe;
        }
   } 

संकलन समय के साथ मैं कर सकता हूँ:

1. कोई रनटाइम चेक नहीं है।
2. टीम द्वारा त्रुटि की संभावना को महत्वपूर्ण रूप से कम करें (आप संकलन समय में गलत मान पास नहीं कर सकते)।
3. यह आईओटा अवधारणा के विपरीत नहीं है।
4. तर्क को समझने में आपके पास स्थिरांक के लिए एक नाम है (यह महत्वपूर्ण है कि आप स्थिरांक कुछ निम्न स्तर प्रोटोकॉल मानों का प्रतिनिधित्व करते हैं)।
5. मूल्यों का सरल प्रतिनिधित्व करने के लिए आप ToString() विधि अनुरूप बना सकते हैं। (CONNECTION_ERROR.NO_INTERNET 0x12 से बेहतर है)। मैं स्ट्रिंगर के बारे में जानता हूं, लेकिन एनम के साथ कोई स्पष्ट कोड पीढ़ी नहीं है।
6. कुछ भाषाओं में आप मूल्यों, श्रेणी और आदि की सरणी प्राप्त कर सकते हैं।
7. कोड पढ़ते समय इसे समझना आसान है (सिर में गणना की आवश्यकता नहीं है)।

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

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

कुछ एक्सटेंशन बनाने के लिए केवल सरल आवश्यकता का उत्तर दें, एनम का उपयोग न करें।
एफई को एनम के बजाय राज्य मशीन का उपयोग राज्य पैटर्न बनाने की आवश्यकता है।

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

और आप कई मामलों में मानवीय कारकों को भूल गए हैं, बड़ी परियोजनाओं में महत्वपूर्ण त्रुटियों को कम करते हैं।

@ स्ट्रीटर 12 दुर्भाग्य से, वास्तविकता यह है कि अक्सर एनमों को विस्तारित करने की आवश्यकता होती है।

@griesemer एक एनम/योग प्रकार का विस्तार एक अलग और कभी-कभी-असंगत प्रकार बनाता है।

यह अभी भी गो में सच है, भले ही एनम/राशि के लिए स्पष्ट प्रकार नहीं हैं। यदि आपके पास पैकेज में "एनम प्रकार" है जो {1, 2, 3} में मूल्यों की अपेक्षा करता है और आप इसे अपने "विस्तारित एनम प्रकार" से 4 पास करते हैं, तो आपने अभी भी निहित "प्रकार" के अनुबंध का उल्लंघन किया है।

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

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

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

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

बहुत अच्छा बताया

@jimmyfrasche ऐसा नहीं है कि मैं व्यक्तिगत रूप से ट्रेडऑफ़ का वर्णन कैसे करूंगा। मैं कहूंगा कि यह "हमेशा मूल सत्यापन कोड लिखता है जिसे संकलक संभाल सकता है" बनाम "टाइप सिस्टम में एक पूरी नई अवधारणा जोड़ें जिसे गो का उपयोग करने वाले सभी को सीखने और समझने की आवश्यकता है।"

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

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

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

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

वैसे भी, मैं विशेष रूप से इसका जिक्र कर रहा था:

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

तथा

दुर्भाग्य से, वास्तविकता यह है कि अक्सर एनमों को विस्तारित करने की आवश्यकता होती है।

मेरे द्वारा बताए गए कारणों से वह तर्क मेरे लिए काम नहीं करता है।

@jimmyfrasche समझ गया; यह एक कठिन समस्या है। यही कारण है कि गो में हमने इसे हल करने की कोशिश नहीं की बल्कि इसके बजाय केवल निरंतर मूल्य को दोहराने की आवश्यकता के साथ स्थिरांक के अनुक्रमों को आसानी से बनाने के लिए एक तंत्र प्रदान किया।

(देरी से भेजा गया - https://github.com/golang/go/issues/19814#issuecomment-349158748 पर प्रतिक्रिया के रूप में था)

@griesemer वास्तव में और यह निश्चित रूप से गो 1 के लिए सही कॉल था, लेकिन इसमें से कुछ गो 2 के लिए पुनर्मूल्यांकन के लायक है।

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

यह दृष्टिकोण https://play.golang.org/p/7ud_3lrGfx आपको छोड़कर सब कुछ प्राप्त करता है

1. परिभाषित पैकेज के भीतर सुरक्षा
2. पूर्णता के लिए एक स्विच को लिंट करने की क्षमता

उस दृष्टिकोण का उपयोग छोटे, सरल योग प्रकारों के लिए भी किया जा सकता है, लेकिन इसका उपयोग करना अधिक अजीब है, यही कारण है कि मुझे लगता है कि https://github.com/golang/go/issues/19412#issuecomment -323208336 जैसा कुछ होगा भाषा और इसका उपयोग कोड जनरेटर द्वारा एनम प्रकार बनाने के लिए किया जा सकता है जो समस्याओं 1 और 2 से बचते हैं।

जेसन के एक स्केच के लिए https://play.golang.org/p/YFffpsvx5e देखें। इस निर्माण के साथ टोकन

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

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

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

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

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

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

@Merovius ऑपरेटिंग सिस्टम प्रक्रिया और पैकेज दोनों ही विश्वास सीमाएँ हैं, जैसा कि आपने इसे रखा है।

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

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

type FromTheNetwork enum {
  // pretend all the "valid" values are listed here
  Missing // the value was not included in the message
  Unknown // the value was not in the set of the valid values
  Error // there was an error attempting to read the value
}

और योग प्रकार के साथ आप आगे जा सकते हैं:

type FromTheNetwork pick {
  Missing struct{} // Not included in message
  Valid somepkg.TheSumBeingReceived // Include valid states with composition
  Unknown []byte // Raw bytes of unknown value received
  Error error // The error from attempting to read the value
}

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

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

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

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

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

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

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

आपका उदाहरण केवल प्रक्रिया-सीमा को कवर करता है (नेटवर्क-त्रुटियों के बारे में बात करके), पैकेज-सीमा नहीं। यदि मैं FromTheNetwork में "अमान्यइंटरनलस्टेट" (कुछ बनाने के लिए) जोड़ता हूं तो पैकेज कैसे व्यवहार करेंगे? क्या मुझे फिर से संकलित करने से पहले उनके स्विच को ठीक करना होगा? फिर यह क्रमिक मरम्मत मॉडल में एक्स्टेंसिबल नहीं है। क्या उन्हें पहले स्थान पर संकलित करने के लिए डिफ़ॉल्ट-केस की आवश्यकता होती है? तब वहाँ enums के लिए कोई मतलब नहीं प्रतीत होता है।

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

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

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

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

समय-समय पर एनम के विरोधियों ने कहा कि वे विस्तार योग्य नहीं हैं, हमें अभी भी क्रमांकन/संक्रमण के बाद जांच की आवश्यकता है, हम संगतता को तोड़ सकते हैं आदि।

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

उदाहरण 1. मैं निम्न स्तर का डेवलपर हूं और, मुझे कुछ रजिस्टरों के पते, स्थापित निम्न स्तर के प्रोटोकॉल मूल्यों आदि के लिए कॉन्स्ट की आवश्यकता है। अब गो में मुझे केवल एक ही समाधान मिला है: बिना आईओटा के कॉन्स्ट का उपयोग करना है, क्योंकि कई मामलों में यह बदसूरत होगा . मैं एक पैकेज के लिए और प्रेस के बाद कई स्थिरांक ब्लॉक प्राप्त कर सकता हूं। मुझे सभी 20 स्थिरांक मिले हैं और यदि उनके समान प्रकार और समान नाम हैं तो मैं त्रुटियां कर सकता हूं। यदि प्रोजेक्ट बड़ा है तो आपको यह त्रुटि मिल जाएगी। रक्षात्मक प्रोग्रामिंग के साथ इसे रोकने के लिए, टीडीडी हमें डुप्लीकेट चेक कोड (डुप्लिकेट कोड = डुप्लीकेट त्रुटियों/किसी भी मामले में परीक्षण) को बंद करना चाहिए। स्थानान्तरण के उपयोग से हमें समान समस्याएं नहीं होती हैं और इस मामले में मूल्य कभी नहीं बदलेगा (ऐसी स्थिति खोजने का प्रयास करें जब उत्पादन में रजिस्टरों के पते बदल दिए जाएंगे :))। हम अभी भी कभी-कभी जांचते हैं कि फ़ाइल/नेट आदि से हमें जो मूल्य मिलता है वह सीमा में है, लेकिन इसे केंद्रीकृत करने में कोई समस्या नहीं है (सी # Enum.TryParse देखें)उदाहरण के लिए)। Enums के साथ मैं इस मामले में विकास समय और प्रदर्शन बचाता हूं।

उदाहरण 2. मैं राज्य/त्रुटि तर्क के साथ कुछ छोटे मॉड्यूल विकसित कर रहा हूं। अगर मैं एनम को निजी बनाता हूं, तो किसी को भी इस एनम के बारे में पता नहीं है, और आप इसे बिना किसी समस्या के 1 से सभी लाभों के साथ बदल/विस्तारित कर सकते हैं। यदि आप कुछ निजी तर्क पर अपना कोड आधारित करते हैं, तो आपके विकास पर कुछ पूरी तरह से गलत हो गया है।

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

मेरी राय में कास्ट और कंपाइल टाइम एनम के बीच मुख्य अंतर यह है कि एनम के दो मुख्य अनुबंध हैं।

1. नामकरण अनुबंध।
2. मूल्य अनुबंध।
   इस अनुच्छेद के पक्ष और विपक्ष में सभी तर्कों पर पहले विचार किया गया था।
   यदि आप अनुबंध प्रोग्रामिंग का उपयोग करते हैं तो आप आसानी से इसके लाभों को समझ नहीं सकते हैं।

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

आखिरकार जो कहा गया है, मैं यह नोट करना चाहता हूं कि Iota के नुकसान भी हैं।

1. इसमें हमेशा int प्रकार होता है,
2. आपको सिर में मूल्यों की गणना करने की आवश्यकता है। आप कई बार खो सकते हैं मूल्यों की गणना करने का प्रयास करें, और जांचें कि यह ठीक है।
   Enums/const के साथ मैं सिर्फ F12 दबा सकता हूं और सभी मान देख सकता हूं।
3. Iota अभिव्यक्ति कोड अभिव्यक्ति है, आपको इसका परीक्षण करने की भी आवश्यकता है।
   कुछ परियोजनाओं में मैंने इन कारणों से आईओटा का उपयोग करने से पूरी तरह इनकार कर दिया।

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

मेरी कुंदता के लिए क्षमा करें, लेकिन इस टिप्पणी के बाद मुझे नहीं लगता कि आपके पास यहां खड़े होने के लिए बहुत कुछ है।

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

हम यथोचित रूप से असहमत हो सकते हैं, लेकिन हम सभी को कम से कम अच्छे विश्वास में बहस करनी चाहिए।

उदाहरण 1

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

और किसी भी तरह से, मुझे नहीं लगता कि एक लिंटर इसे पकड़ने में सक्षम क्यों नहीं होगा।

मुझे सभी 20 स्थिरांक मिले हैं और यदि उनके समान प्रकार और समान नाम हैं तो मैं त्रुटियां कर सकता हूं। यदि प्रोजेक्ट बड़ा है तो आपको यह त्रुटि मिल जाएगी।

यदि आप नाम गलत टाइप कर रहे हैं, तो बंद एनम होने से आपकी मदद नहीं होगी। केवल अगर आप प्रतीकात्मक नामों का उपयोग नहीं करते हैं और इसके बजाय int/string-literals का उपयोग करते हैं।

उदाहरण 2

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

और किसी भी तरह से, मुझे नहीं लगता कि एक लिंटर इसे पकड़ने में सक्षम क्यों नहीं होगा।

उदाहरण 3

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

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

इसमें हमेशा int प्रकार होता है,

iota हो सकता है (जरूरी नहीं, लेकिन जो भी हो), लेकिन const ब्लॉक नहीं हैं, उनके पास विभिन्न प्रकार के निरंतर प्रकार हो सकते हैं - वास्तव में, सबसे अधिक प्रस्तावित एनम कार्यान्वयन का एक सुपरसेट।

आपको सिर में मूल्यों की गणना करने की आवश्यकता है।

फिर से, आप इसे एनम के पक्ष में तर्क के रूप में उपयोग नहीं कर सकते हैं; आप स्थिरांक लिख सकते हैं जैसे आप एक एनम-घोषणा में कर सकते हैं।

Iota अभिव्यक्ति कोड अभिव्यक्ति है, आपको इसका परीक्षण करने की भी आवश्यकता है।

हर अभिव्यक्ति का परीक्षण नहीं करना पड़ता है। यदि यह तुरंत स्पष्ट है, तो परीक्षण अधिक है। यदि ऐसा नहीं है, तो स्थिरांक लिखिए, आप वैसे भी एक परीक्षण में ऐसा करेंगे।

iota गो में एनम करने का वर्तमान में अनुशंसित तरीका नहीं है - const घोषणाएं हैं। iota लगातार या फॉर्मूलाइक कॉन्स्ट डिक्लेरेशन लिखते समय टाइपिंग को बचाने के अधिक सामान्य तरीके के रूप में कार्य करता है।

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

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

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

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

यदि आप नाम गलत टाइप कर रहे हैं, तो बंद एनम होने से आपकी मदद नहीं होगी। केवल अगर आप प्रतीकात्मक नामों का उपयोग नहीं करते हैं और इसके बजाय int/string-literals का उपयोग करते हैं।

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

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

लेकिन स्थिरांक/एनम का उपयोग/उपयोग नहीं करना समस्या के मूल को दूर नहीं करता है, आपको अभी भी बैक कॉपेबिलिटी के बारे में सोचने की ज़रूरत है। मैं यह कहना चाहता हूं कि समस्या एनम/कास्ट में नहीं बल्कि हमारे उपयोग के मामलों में है।

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

इस मामले में आपको अभी भी नाम संवहन और संकलन समय जांच के लाभ हैं,

हर अभिव्यक्ति का परीक्षण नहीं करना पड़ता है। यदि यह तुरंत स्पष्ट है, तो परीक्षण अधिक है। यदि ऐसा नहीं है, तो स्थिरांक लिखिए, आप वैसे भी एक परीक्षण में ऐसा करेंगे।

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

फिर से, आप इसे एनम के पक्ष में तर्क के रूप में उपयोग नहीं कर सकते हैं; आप स्थिरांक लिख सकते हैं जैसे आप एक एनम-घोषणा में कर सकते हैं।

यह enums के लिए तर्क नहीं है।

@मेरोवियस

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

न ही वे सुरक्षित रूप से एक्स्टेंसिबल हैं।

यदि आपके पास है

package p
type Enum int
const (
  A Enum = iota
  B
  C
)
func Make() Enum {...}
func Take(Enum) {...}

तथा

package q
import "p"
const D enum = p.C + 1

q के भीतर q D उपयोग करना सुरक्षित है (जब तक कि p Enum(3) लिए अपना लेबल नहीं जोड़ता) लेकिन केवल तब तक जब तक आप कभी नहीं इसे वापस p पर पास करें: आप p.Make का परिणाम ले सकते हैं और इसकी स्थिति को D में परिवर्तित कर सकते हैं लेकिन यदि आप p.Take पर कॉल करते हैं तो आपको यह सुनिश्चित करना होगा कि यह q.D पारित नहीं किया जा रहा है और यह सुनिश्चित करना है कि यह केवल A , B , C में से एक प्राप्त करता है या आपके पास एक बग है। आप ऐसा करके इसके आसपास काम कर सकते हैं

package q
import "p"
type Enum int
const (
    A = p.A
    B = p.B
    C = p.C
    D = C + 1
)
// needs to return an error if passed D or an unknown state of Enum
func To(Enum) (p.Enum, error) {...}
// needs to return an error if p.Enum has a value not known to the author
// at the time this package was written.
func From(p.Enum) (Enum, error) {...}

भाषा में बंद प्रकार के साथ या उसके बिना आपके पास एक बंद प्रकार होने के सभी मुद्दे हैं लेकिन संकलक के बिना आपके लिए देख रहा है।

आपका उदाहरण केवल प्रक्रिया-सीमा को कवर करता है (नेटवर्क-त्रुटियों के बारे में बात करके), पैकेज-सीमा नहीं। यदि मैं FromTheNetwork में एक "अमान्य इंटरनलस्टेट" (कुछ बनाने के लिए) जोड़ता हूं, तो पैकेज कैसे व्यवहार करेंगे? क्या मुझे फिर से संकलित करने से पहले उनके स्विच को ठीक करना होगा? फिर यह क्रमिक मरम्मत मॉडल में एक्स्टेंसिबल नहीं है। क्या उन्हें पहले स्थान पर संकलित करने के लिए डिफ़ॉल्ट-केस की आवश्यकता होती है? तब वहाँ enums के लिए कोई मतलब नहीं प्रतीत होता है।

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

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

package p
type Enum pick {
  A, B, C struct{}
}

Enum के साथ "विस्तारित" किया जा सकता है

package q
import "p"
type Enum pick {
  P p.Enum
  D struct{}
}

और इस बार p D जोड़ना पूरी तरह से सुरक्षित है। केवल नकारात्मक पक्ष यह है कि आपको p.Enum q.Enum अंदर से प्राप्त करने के लिए डबल-स्विच करना होगा, लेकिन यह स्पष्ट और स्पष्ट है और, जैसा कि मैंने उल्लेख किया है, आपका संपादक कंकाल को थूक सकता है स्वचालित रूप से स्विच आउट।

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

इसके साथ दो मुश्किलें हैं।

यदि आपके पास कॉन्स्ट/आईओटा के माध्यम से अपने डोमेन के सबसेट को दिए गए लेबल के साथ परिभाषित अभिन्न प्रकार है:

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

const (
  //Name is the ID of a record field
  Name Record = iota
  //EmpID is the ID of an employee ID field
  EmpID

  //Intermediate values are reserved for future versions

  //Custom is the base of custom fields. Any custom field must have a unique ID greater than Custom.
  Custom Record = 42
)

यह नहीं कह रहा है कि 0, 1, और 42 रिकॉर्ड प्रकार के डोमेन हैं। अनुबंध बहुत अधिक सूक्ष्म है और मॉडल के लिए आश्रित प्रकारों की आवश्यकता होगी। (यह निश्चित रूप से बहुत दूर जा रहा होगा!)

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

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

मान लीजिए कि शाब्दिक प्रकार range m n एक अभिन्न प्रकार बनाता है जो कम से कम m और अधिकतम n (सभी v के लिए, m ≤ v ≤ n) है। इसके साथ हम एनम के डोमेन को सीमित कर सकते हैं, जैसे

package p
type Enum range 0 2
const (
  A Enum = iota
  B
  C
)

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

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

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

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

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

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

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

type enums enum { foo, bar, baz }

@rudolfschmidt , मैं आपसे सहमत हूं, ऐसा भी लग सकता है:

type DaysOfTheWeek enum {
  Monday
  Tuesday
}

लेकिन इसका एक छोटा सा नुकसान है - हमें उन मामलों में enum पर नियंत्रण करने में सक्षम होना चाहिए जब हमें डेटा को मान्य करना होगा, उन्हें JSON में बदलना होगा या FS के साथ इंटरैक्ट करना होगा।
यदि हम आँख बंद करके मान लेते हैं कि एनम अहस्ताक्षरित पूर्णांकों का एक समूह है तो हम एक कोटा के साथ समाप्त हो सकते हैं।
यदि हम कुछ नया करना चाहते हैं तो हमें उपयोग की सुविधा के बारे में सोचना होगा।
उदाहरण के लिए, मैं कितनी आसानी से मान्य कर सकता हूं कि आने वाले JSON के अंदर मान एनम का वैध तत्व है?
क्या होगा अगर मैं आपको बताऊं कि सॉफ्टवेयर बदल रहा है?

मान लें कि हमारे पास क्रिप्टोकरेंसी की सूची है:

type CryptoCurrency enum {
  BTC
  ETH
  XMR
}

हम कई तृतीय पक्ष प्रणालियों के साथ डेटा का आदान-प्रदान करते हैं। मान लीजिए कि आपके पास उनमें से हजारों हैं।
आपके पास लंबा इतिहास है, भंडारण में डेटा की संख्या। समय बीतता है, मान लीजिए, बिटकॉइन अंततः मर जाता है। कोई इसका इस्तेमाल नहीं कर रहा है।
तो आप इसे संरचना से छोड़ने का निर्णय लेते हैं:

type CryptoCurrency enum {
  ETH
  XMR
}

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

type CryptoCurrency enum {
  ETH = 1, // reminds const?
  XMR = 2
}
// this is real life case 
v := 3
if v is CryptoCurrency {
 // right?
} else {
 // nope, provide default value
 v = CryptoCurrency.ETH
}

हमें एनम की प्रयोज्यता और मामलों का उपयोग करने के बारे में सोचना होगा।

हम 2 नए कीवर्ड सीख सकते हैं यदि यह हमें बॉयलरप्लेट कोड की हजारों लाइनों को बचा सकता है।

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

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

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

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

एक उपकरण के रूप में यह कार्यक्षमता प्रदान करना मेरे लिए बहुत आसान लगता है। इसका एक हिस्सा पहले से ही स्ट्रिंगर-टूल में मौजूद है। यदि कोई उपकरण है जिसे आप enumer Foo कहते हैं, जो Foo के लिए Foo fmt.Stringer विधियाँ उत्पन्न करेगा और (कहते हैं) एक Known() bool विधि जो जाँचती है कि क्या संग्रहीत मूल्य ज्ञात मूल्यों की सीमा में है, तो क्या इससे आपकी समस्याएं कम हो जाएंगी?

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

. सामान्य रूप से एनम के लिए इसका उपयोग करना एक साधारण प्रकार की प्रणाली के लिए बैसाखी जैसा लगता है।

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

और यह देखते हुए कि गो कैसे सभी प्रकार की सुरक्षा के बारे में है, जो भाषा के दर्शन के खिलाफ महसूस करता है।

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

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

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

मैंने चर्चा से कुछ विचारों को जोड़ा है, आप इसके बारे में क्या सोचते हैं?

कुछ बुनियादी जानकारी:

1. आप हर दूसरे प्रकार की तरह एक एनम का विस्तार कर सकते हैं।
2. वे एक स्थिरांक की तरह संग्रहीत होते हैं, लेकिन उपसर्ग के रूप में प्रकार के नाम के साथ। कारण: वर्तमान आईओटा-एनम का उपयोग करते समय, आप संभवतः प्रत्येक स्थिरांक के उपसर्ग के रूप में एनम का नाम लिखेंगे। इस फीचर से आप बस इससे बच सकते हैं।
3. वे अपरिवर्तनीय हैं और हर दूसरे स्थिरांक की तरह व्यवहार किया जाता है।
4. आप enums पर पुनरावृति कर सकते हैं। जब आप ऐसा करते हैं, तो वे एक नक्शे की तरह व्यवहार करते हैं। कुंजी एनम नाम है, मान एनम मान है।
5. आप एक एनम में विधियाँ जोड़ सकते हैं, जैसे आप हर दूसरे प्रकार के लिए करते हैं।
6. प्रत्येक एनम मान को स्वत: जेनरेट की गई विधियों के लिए है:
7. Name() एनम वैरिएबल का नाम लौटाएगा
8. Index() एनम इंडेक्स लौटाएगा, जो स्वचालित रूप से बढ़ रहा है। यह शुरू होता है जहां एक सरणी शुरू होती है।

कोड:
```जाओ
पैकेज मुख्य

// उदाहरण ए
टाइप कंट्री एनम [स्ट्रक्चर] {// एनम अन्य प्रकारों का विस्तार कर सकते हैं (उदाहरण बी देखें)
ऑस्ट्रिया ("एटी", "ऑस्ट्रिया", झूठा) // एक कॉन्स की तरह सुलभ होगा, लेकिन प्रकार के साथ
जर्मनी ("DE", "जर्मनी", सत्य) // उपसर्ग (जैसे देश। ऑस्ट्रिया)

//The struct will automatically begin when it doesn't match the format EnumName(...) anymore
Code, CountryName string
HasMerkel bool //Totally awesome

}

// Enums में हर दूसरे प्रकार की तरह विधियाँ हो सकती हैं
func (सी देश) परीक्षण () {}

func मुख्य () {
println (देश। ऑस्ट्रिया। देश का नाम) // ऑस्ट्रिया
प्रिंट्लन (देश.जर्मनी.कोड) // डीई

/* Prints:
Austria
0
Germany
1
 */
for name, country := range Country {
    println(name) //Austria
    println(name == country.Name()) //true ; also autogenerated 
    println(country.Index()) //Auto generated increasing index
}

}

// उदाहरण बी
कूलनेस एनम टाइप करें [int] {
बहुत अच्छा(10)
कूल(5)
नॉटकूल(0)
}```

@sinnlosername मुझे लगता है कि enums कुछ ऐसा होना चाहिए जो समझने में बहुत आसान हो। पिछली चर्चा में प्रस्तुत कुछ विचारों के संयोजन से जरूरी नहीं कि एक एनम के लिए सबसे अच्छा विचार हो।

मेरा मानना ​​है कि निम्नलिखित को समझना आसान होगा:

घोषणा

type Day enum {
    Monday
    Tuesday
    ...
    Sunday
}

स्ट्रिंग रूपांतरण ( Stringer इंटरफ़ेस का उपयोग करके):

func (d Day) String() string {
    switch d {
    case Monday:
        return "mon"
    case Tuesday:
        return "tues"
    ...
    case Sunday:
        return "sun"
    }
}

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

उदाहरण उपयोग

func IsWeekday(d Day) bool {
    return d != Saturday && d != Sunday
}

अगर मैं string Day प्रतिनिधित्व करने के लिए करता हूं, तो IsWeekday कहेगा कि कोई भी स्ट्रिंग जो "sat" या "sun" नहीं है एक कार्यदिवस है (यानी, IsWeekday("abc") क्या होगा/चाहिए?) इसके विपरीत, ऊपर दिखाए गए फ़ंक्शन का डोमेन प्रतिबंधित है, इस प्रकार फ़ंक्शन को इसके इनपुट के संबंध में अधिक समझने की अनुमति मिलती है।

@ljeabmreosn

यह शायद होना चाहिए

func IsWeekday(d Day) bool {
    return d != Day.Saturday && d != Day.Sunday
}

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

हम 14. मई 2018 में हैं और हम अभी भी एनम समर्थन के बारे में चर्चा करते हैं। मेरा मतलब, नर्क क्या है? व्यक्तिगत रूप से मैं गोलांग से निराश हूं।

मैं समझ सकता हूं कि किसी सुविधा की प्रतीक्षा करते समय यह निराशाजनक हो सकता है। लेकिन इस तरह की गैर-रचनात्मक टिप्पणियां पोस्ट करने से कोई मदद नहीं मिलती है। कृपया अपनी टिप्पणियों का सम्मान करें। https://golang.org/conduct देखें।

धन्यवाद।

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

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

• आवश्यक शब्द का अर्थ "मैं जो चाहता हूं" नहीं है।

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

और मुझे मत बताओ "लेकिन गो सरल रहना चाहता है"। "सरल" और "कोई वास्तविक विशेषताएं नहीं" के बीच एक बड़ा अंतर है। जावा बहुत सरल है लेकिन इसमें कई विशेषताएं हैं जो गायब हैं। तो या तो जावा देव जादूगर हैं या यह तर्क सिर्फ खराब है।

वास्तव में प्रत्येक आधुनिक भाषा की मूल विशेषताएँ आवश्यक हैं।

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

GoLang में कुछ अच्छी विशेषताएं हैं, लेकिन अगर परियोजना रूढ़िवादी रहती है तो यह जीवित नहीं रहेगी।

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

बीटीडब्ल्यू, अगर मैं कल्पना करता हूं कि आज गो क्या होगा यदि लोगों की मांग की 10% सुविधाओं को अपनाया जाता है, तो शायद अब तक मैं गो का उपयोग नहीं करूँगा।

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

"एनम या जेनरिक जैसी सुविधाओं का उन लोगों के लिए कोई नुकसान नहीं है जो उन्हें पसंद नहीं करते हैं, लेकिन उन लोगों के लिए उनके कई फायदे हैं जो उनका उपयोग करना चाहते हैं।"

और आपको क्यों लगता है कि यह रूढ़िवादिता गोलंग के विकास का कारण है? मुझे लगता है कि यह गोलांग की दक्षता और मानक पुस्तकालयों के महान सेट से संबंधित होने की अधिक संभावना है।

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

"एनम या जेनरिक जैसी सुविधाओं का उन लोगों के लिए कोई नुकसान नहीं है जो उन्हें पसंद नहीं करते हैं, लेकिन उन लोगों के लिए उनके कई फायदे हैं जो उनका उपयोग करना चाहते हैं।"

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

अब तक यह बढ़ रहा है। आईएमओ, अगर यह रूढ़िवादी नहीं होता तो यह अभी भी नहीं बढ़ रहा होता

मुझे नहीं लगता कि इसकी धीमी वृद्धि (यदि कोई हो) रूढ़िवाद के कारण है, बल्कि मानक पुस्तकालय, पहले से ही भाषा सुविधाओं के मौजूदा सेट, टूलिंग के कारण है। वही मुझे यहां ले आया। भाषा सुविधाओं को जोड़ने से उस संबंध में मेरे लिए कुछ भी नहीं बदलेगा।

अगर हम C# और टाइपस्क्रिप्ट या यहां तक ​​कि Rust/Swift को देखें। वे पागल जैसी नई सुविधाएँ जोड़ रहे हैं। सी # अभी भी शीर्ष भाषाओं में ऊपर और नीचे उतार-चढ़ाव कर रहा है। टाइपस्क्रिप्ट बहुत तेजी से बढ़ रहा है। जंग/स्विफ्ट के लिए वही। दूसरी ओर, 2009 और 2016 में लोकप्रियता में विस्फोट हुआ। लेकिन उसके बीच बिल्कुल नहीं बढ़ रहा था और वास्तव में हार रहा था। नए डेवलपर्स को देने के लिए गो के पास कुछ भी नहीं है अगर वे पहले से ही इसके बारे में जानते थे और किसी कारण से इसे पहले नहीं चुना था। ठीक इसलिए क्योंकि गो अपने डिजाइन में स्थिर है। अन्य भाषाओं में फीचर जोड़ने की वजह यह नहीं है कि उनके पास करने के लिए और कुछ नहीं है, बल्कि इसलिए कि वास्तविक उपयोगकर्ता आधार इसकी मांग करता है। लोगों को नई सुविधाओं की आवश्यकता है ताकि उनका कोड आधार लगातार बदलते समस्या डोमेन में प्रासंगिक बना रहे। async/प्रतीक्षा की तरह। एक वास्तविक समस्या को हल करने के लिए इसकी आवश्यकता थी। आश्चर्य नहीं कि अब आप इसे कई भाषाओं में देख सकते हैं।

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

मुझे नहीं लगता कि इसकी धीमी वृद्धि (यदि कोई हो) रूढ़िवाद के कारण है, बल्कि मानक पुस्तकालय, पहले से ही भाषा सुविधाओं के मौजूदा सेट, टूलिंग के कारण है। वही मुझे यहां ले आया।

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

भाषा सुविधाओं को जोड़ने से उस संबंध में मेरे लिए कुछ भी नहीं बदलेगा।

क्या अापको उस बारे में पूर्ण विशवास है? ऊपर देखो।

BTW, क्या आपने 2017 के सर्वेक्षण के परिणाम देखे हैं?

अगर भाषा हर [आधे] साल में कुछ/सब कुछ तोड़ती है

फिर कुछ मत तोड़ो। C# ने बहुत सारी सुविधाएँ जोड़ीं और इसने कभी भी पश्चगामी संगतता का उल्लंघन नहीं किया। उनके लिए यह विकल्प भी नहीं है। सी ++ के लिए वही मुझे लगता है। यदि गो बिना कुछ तोड़े फीचर नहीं जोड़ सकता है, तो यह गो के साथ एक समस्या है और संभवतः, इसे कैसे लागू किया जाता है।

BTW, क्या आपने 2017 के सर्वेक्षण के परिणाम देखे हैं?

मेरी टिप्पणी 2017/2018 के सर्वेक्षणों, TIOBE सूचकांक और विभिन्न भाषाओं के साथ क्या हो रहा है, इस पर मेरी सामान्य टिप्पणियों पर आधारित है।

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

फिर कुछ मत तोड़ो।

अच्छा विचार। हालांकि, कई, यदि भाषा में प्रस्तावित अधिकांश परिवर्तन नहीं हैं, तो _इस एक सहित_, परिवर्तन को तोड़ रहे हैं।

C# ने बहुत सारी सुविधाएँ जोड़ीं और इसने कभी भी पश्चगामी संगतता का उल्लंघन नहीं किया।

कृपया अपने तथ्यों की जांच करें: विजुअल सी# 2010 ब्रेकिंग चेंजेस । (पहला वेब खोज परिणाम, मैं केवल अनुमान लगा सकता हूं कि यह एकमात्र उदाहरण है या नहीं।)

मेरी टिप्पणी 2017/2018 के सर्वेक्षणों, TIOBE सूचकांक और विभिन्न भाषाओं के साथ क्या हो रहा है, इस पर मेरी सामान्य टिप्पणियों पर आधारित है।

ठीक है, फिर आप कैसे देख सकते हैं कि भाषा बढ़ती नहीं है, जबकि सर्वेक्षण के परिणाम उत्तरदाताओं की संख्या में 70% साल-दर-साल वृद्धि दिखाते हैं?

आप "ब्रेकिंग चेंजेस" को कैसे परिभाषित करते हैं? एनम या जेनरिक जोड़ने के बाद भी गो कोड की हर पंक्ति काम करेगी।

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

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

आप "ब्रेकिंग चेंजेस" को कैसे परिभाषित करते हैं? एनम या जेनरिक जोड़ने के बाद भी गो कोड की हर पंक्ति काम करेगी।

बिलकूल नही। यह कोड अब इस प्रस्ताव के साथ संकलित नहीं होगा:

package foo

var enum = 42

आवश्यक शब्द का अर्थ "मैं जो चाहता हूं" नहीं है।

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

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

निश्चित रूप से यदि आपके पास विकल्प नहीं है तो आप भी करेंगे, लेकिन यदि आपके पास जंग जैसे विकल्प हैं जो पहले से ही वह सब सामान प्रदान करते हैं और गोलंग की तुलना में निष्पादन में भी तेज़ हैं तो आपको क्यों करना चाहिए? मैं वास्तव में सोच रहा हूं कि क्या गो का भविष्य उस मानसिकता के साथ है:

आवश्यक शब्द का अर्थ "मैं जो चाहता हूं" नहीं है।

मैं ओपन सोर्स में सभी योगदानों का सम्मान करता हूं और अगर गोलंग एक हॉबी प्रोजेक्ट है तो यह ठीक है कि यह कैसा है, लेकिन गोलंग को गंभीरता से लेना चाहता है और फिलहाल यह कुछ ऊब गए डेवलपर्स के लिए एक खिलौना है और मुझे इसे बदलने की इच्छा नहीं है।

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

और दोनों, थोड़ा धीमा संकलन और "एनम" नामक चर न्यूनतम प्रभाव हैं। वास्तव में 99% लोग इसे नोटिस भी नहीं करेंगे और अन्य 1% को बस कुछ छोटे बदलाव जोड़ने होंगे जो सहनीय हों। यह तुलना करने योग्य नहीं है उदाहरण के लिए जावा का आरा जो फू ... सब कुछ ऊपर।

और दोनों, थोड़ा धीमा संकलन और "एनम" नामक चर न्यूनतम प्रभाव हैं। वास्तव में 99% लोग इसे नोटिस भी नहीं करेंगे और अन्य 1% को बस कुछ छोटे बदलाव जोड़ने होंगे जो सहनीय हों।

हर कोई खुश होगा अगर कोई इस तरह के अद्भुत प्रदर्शन के साथ एक डिजाइन और कार्यान्वयन के साथ आ सकता है। कृपया #15292 में योगदान करें।

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

क्या आपके पास जेनरिक के साथ गति अंतर के लिए कोई संख्या है?

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

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

क्या आपके पास जेनरिक के साथ गति अंतर के लिए कोई संख्या है?

नहीं, इसलिए मैंने कोई पोस्ट नहीं किया। मैंने केवल यह पोस्ट किया है कि लागत शून्य नहीं हो सकती।

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

वह मिला हुआ है। मंदी जेनरिक को लेकर थी। "एनम" पिछड़ी संगतता के बारे में था और आपकी झूठी "_ हर_ लाइन ऑफ गो कोड अभी भी एनम या जेनरिक जोड़ने के बाद काम करेगा।" दावा। (मेरा जोर देता है)

@Merovius तुम कठोर हो, मैं अब चुप हो रहा हूँ।

इसे वापस एनम प्रकारों में लाना, जो कि इस मुद्दे के बारे में है, मैं इस तर्क को पूरी तरह से समझता हूं कि गो को जेनरिक की आवश्यकता क्यों है, लेकिन मैं इस तर्क पर बहुत अधिक अस्थिर हूं कि गो को एनम प्रकारों की आवश्यकता क्यों है। वास्तव में, मैंने इसे ऊपर https://github.com/golang/go/issues/19814#issuecomment -290878151 में पूछा था और मैं अभी भी इस पर अस्थिर हूं। अगर इसका कोई अच्छा जवाब था, तो मैं चूक गया। क्या कोई इसे दोहरा सकता है या इसे इंगित कर सकता है? धन्यवाद।

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

@ianlancetaylor : सब कुछ टाइप सुरक्षा के साथ करना है। आप टाइपो या असंगत प्रकारों का उपयोग करने के कारण रनटाइम त्रुटियों के जोखिम को कम करने के लिए प्रकारों का उपयोग करते हैं। फिलहाल आप go . में लिख सकते हैं

if enumReference == 1

क्योंकि फिलहाल एनम सिर्फ नंबर या अन्य आदिम डेटाटाइप हैं।

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

आपको केवल लिखने में सक्षम होना चाहिए

if enumReference == enumType

आपको कल्पना करने के लिए बहुत अधिक कल्पना की आवश्यकता नहीं है कि किन परिदृश्यों में if enumReference == 1 अधिक छिपे हुए तरीके से हो सकता है और अतिरिक्त समस्याएं पैदा कर सकता है जो आप केवल रनटाइम में देखेंगे।

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

गो की अपनी क्षमता है, लेकिन यह अजीब है कि वर्षों से सिद्ध और समझी जाने वाली चीजों और अवधारणाओं पर यहां चर्चा की जाती है जैसे आप प्रोग्रामिंग की नई अवधारणाओं या प्रतिमानों पर चर्चा करते हैं।

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

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

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

@derekperkins @rudolfschmidt धन्यवाद। मैं स्पष्ट होना चाहता हूं कि हालांकि सी ++ में एनम प्रकार हैं, आप जिन सुविधाओं का सुझाव दे रहे हैं वे सी ++ में नहीं हैं। तो इस बारे में कुछ भी स्पष्ट नहीं है।

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

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

गो में, स्थिरांक टाइप नहीं किए गए हैं, इसलिए यदि हम पूर्णांक से एक एनम प्रकार में रूपांतरण की अनुमति देते हैं तो if enumVal == 1 को मना करना अजीब होगा। लेकिन मुझे लगता है कि हम कर सकते थे।

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

मैं अपने आप को दोहराऊंगा लेकिन मैं एनमों को रखने के पक्ष में हूं क्योंकि वे आज हैं और उनमें से शीर्ष पर सुविधाएं जोड़ रहे हैं:

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

इसके शीर्ष पर यह जो प्रदान करता है वह है:

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

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

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

@ianlancetaylor मुझे लगता है कि आपके तर्क में कुछ खामियां हैं।

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

प्रोग्रामर के लिए एब्स्ट्रैक्शन ठीक है; Go कई सार प्रदान करता है। उदाहरण के लिए, निम्न कोड संकलित नहीं करता है:

package main

import "fmt"

const NULL = 0x0

func main() {
    str := "hello"
    if &str == NULL {
        fmt.Println("str is null")
    }
}

लेकिन C में, इस शैली का एक प्रोग्राम संकलित होगा। ऐसा इसलिए है क्योंकि Go दृढ़ता से टाइप किया गया है और C नहीं है।

Enums के सूचकांकों को आंतरिक रूप से संग्रहीत किया जा सकता है, लेकिन चर के पते के समान, एक अमूर्त के रूप में उपयोगकर्ता के लिए छिपाया जा सकता है।

@zerkms हाँ, यह एक संभावना है, लेकिन d के प्रकार को देखते हुए, प्रकार का अनुमान संभव होना चाहिए; हालाँकि, एनम का योग्य उपयोग (जैसा कि आपके उदाहरण में है) पढ़ने में थोड़ा आसान है।

@ianlancetaylor जो कि आप के बारे में बात कर रहे हैं, का एक बहुत ही सी संस्करण है। मुझे यकीन है कि बहुत से लोग हैं लेकिन इसे पसंद करेंगे, लेकिन आईएमओ:

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

कार्यान्वयन उन मानों को पूर्णांक तक संकलित करने जा रहा है, लेकिन असुरक्षित या प्रतिबिंब को छोड़कर, प्रोग्रामर को सीधे उजागर करने के किसी भी वैध कारण के साथ यह मौलिक बात नहीं है। इसी कारण से आप bool(0) प्राप्त करने के लिए false नहीं कर सकते हैं।

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

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

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

(बेशक, अक्सर आप डेटा को उन राज्यों से जोड़ना चाहते हैं और उस डेटा का प्रकार अलग-अलग राज्यों में अलग-अलग होता है...)

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

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

यहां बहुत सारे प्रस्ताव हैं।

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

एक एनम प्रकार का शून्य मान क्या है?

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

(इसके अलावा, "स्ट्रिंगिफिकेशन" के संबंध में, सप्ताह के एक दिन के लिए सही स्ट्रिंग भाषा- और लोकेल-निर्भर है।)

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

उदाहरण के लिए, कुछ C# प्रकारों में ToString ओवरराइड होता है जो संस्कृति की जानकारी भी लेता है। या आप स्वयं DateTime ऑब्जेक्ट का उपयोग कर सकते हैं और इसकी ToString विधि का उपयोग कर सकते हैं जो प्रारूप और संस्कृति जानकारी दोनों को स्वीकार करता है। लेकिन ये ओवरराइड मानक नहीं हैं, object वर्ग जो सभी को विरासत में मिला है, उसके पास केवल ToString() है। गो में काफी हद तक स्ट्रिंगर इंटरफेस की तरह।

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

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

@creker ने जो कहा, उसे फिर से सख्त करें। विस्तार करने के लिए, हालांकि, मैं उम्मीद करूंगा

var e enum {
  Sunday
  Monday
  //etc.
}
fmt.Println(reflect.ValueOf(e))

रविवार को प्रिंट करने के लिए 0 नहीं। लेबल मान है, इसका प्रतिनिधित्व नहीं।

स्पष्ट होने के लिए मैं यह नहीं कह रहा हूं कि इसमें एक अंतर्निहित स्ट्रिंग विधि होनी चाहिए-बस लेबल को प्रकार के हिस्से के रूप में संग्रहीत किया जाना चाहिए और प्रतिबिंब द्वारा पहुंचा जा सकता है। (हो सकता है कि Println एक परावर्तन पर लेबल () को कॉल करता है। एक एनम से मूल्य या ऐसा कुछ? गहराई से नहीं देखा है कि fmt इसका जादू कैसे करता है।)

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

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

मेरे लिए यह मानने का कोई मतलब नहीं है कि सभी एनमों का कुल क्रम है या वे चक्रीय हैं। type failure enum { none; input; file; network } को देखते हुए, क्या यह वास्तव में लागू करने के लिए समझ में आता है कि अमान्य इनपुट फ़ाइल विफलता से कम है या फ़ाइल विफलता में वृद्धि से नेटवर्क विफलता होती है या नेटवर्क विफलता में वृद्धि से सफलता मिलती है?

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

type Weekday uint%7
const (
  Sunday Weekday = iota
  //etc.

तो शनिवार + 1 == रविवार और सप्ताह का दिन (456) == सोमवार। अमान्य कार्यदिवस बनाना असंभव है। हालांकि, यह कॉन्स/आईओटा के बाहर उपयोगी हो सकता है।

जब आप नहीं चाहते कि यह नंबर-वाई हो, जैसा कि @ianlancetaylor ने बताया कि मैं वास्तव में जो चाहता हूं वह योग प्रकार है।

एक मनमाना मॉड्यूलर अंकगणितीय प्रकार का परिचय एक दिलचस्प सुझाव है। तब enums इस रूप का हो सकता है, जो आपको एक छोटी स्ट्रिंग विधि प्राप्त करता है:

var Weekdays = [...]string{"Sunday", ..., "Saturday"}

type Weekday = uint % len(Weekdays)

मनमाने आकार के इनट्स के साथ, यह आपको int128, int256, आदि भी प्राप्त करता है।

आप कुछ बिल्ट-इन्स को भी परिभाषित कर सकते हैं:

type uint8 = uint%(1<<8)
// etc

कंपाइलर पहले की तुलना में अधिक सीमा साबित कर सकता है। और एपीआई प्रकारों के माध्यम से अधिक सटीक अभिकथन प्रदान कर सकते हैं, उदाहरण के लिए Len64 में math/bits फ़ंक्शन अब uint % 64 वापस कर सकता है।

आरआईएससी-वी पोर्ट पर काम करते समय, मुझे uint12 प्रकार चाहिए था, क्योंकि मेरे निर्देश एन्कोडिंग घटक 12 बिट हैं; वह uint % (1<<12) हो सकता था। बहुत सारे बिट-हेरफेर, विशेष रूप से प्रोटोकॉल, इससे लाभान्वित हो सकते हैं।

डाउनसाइड्स महत्वपूर्ण हैं, ज़ाहिर है। गो प्रकारों पर कोड का पक्ष लेता है, और यह टाइप-भारी है। + और - जैसे ऑपरेशन अचानक % जितने महंगे हो सकते हैं। किसी प्रकार की पैरामीट्रिक प्रकार के बिना, आपको लगभग किसी भी लाइब्रेरी फ़ंक्शन के साथ इंटरऑपरेट करने के लिए संभवतः कैननिकल uint8 , uint16 आदि में कनवर्ट करना होगा, और रूपांतरण वापस सीमाओं को छुपा सकता है विफलताएं (जब तक कि हमारे पास पैनिक-ऑन-ऑफ-रेंज रूपांतरण करने का कोई तरीका नहीं है, जो अपनी जटिलता का परिचय देता है)। और मैं देख सकता हूं कि इसका अत्यधिक उपयोग किया जा रहा है, उदाहरण के लिए HTTP स्थिति कोड के लिए uint % 1000 का उपयोग करना।

हालांकि, एक दिलचस्प विचार है। :)

अन्य छोटे उत्तर:

यह एक तरह से इंट-इनेस को लीक कर रहा है

इससे मुझे लगता है कि वे वास्तव में इंट हैं। :)

सामान्य पैटर्न को आसानी से गो जनरेट से भरा जा सकता है

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

मेरे लिए यह मानने का कोई मतलब नहीं है कि सभी एनमों का कुल क्रम है या वे चक्रीय हैं।

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

@creker ने जो कहा, उसे फिर से सख्त करें।

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

@ जोशेरियन एनम्स जो वास्तव में स्याही हैं, उन्हें शायद एक समान तंत्र की आवश्यकता होगी। अन्यथा, enum { A; B; C}(42) क्या है?

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

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

दूसरा विकल्प यह है कि इसे A, B, या C में से कोई भी न होने दें, लेकिन आज हमारे पास const/iota के साथ यही है, इसलिए कोई लाभ नहीं है।

आपके द्वारा कहे जाने वाले सभी कारण int%N इसे भाषा में नहीं बनाएंगे, ऐसा लगता है कि समान रूप से उन एनमों पर लागू होते हैं जो थोड़े ints हैं। (हालांकि मैं किसी भी तरह से नाराज नहीं होता अगर उनके जैसा कुछ शामिल किया जाता)।

अंतर्मन को दूर करने से वह दुविधा दूर हो जाती है। इसे उन मामलों के लिए कोड जनरेशन की आवश्यकता होती है जब आप उस इंट-इनेस में से कुछ को वापस जोड़ना चाहते हैं, लेकिन यह आपको ऐसा न करने का विकल्प भी देता है, जो आपको यह नियंत्रित करने देता है कि कितना इंट-इनेस पेश करना है और किस तरह का: आप नहीं जोड़ सकते हैं " next" विधि, एक चक्रीय अगली विधि, या एक अगली विधि जो एक त्रुटि देता है यदि आप किनारे से गिरते हैं। (आप Monday*Sunday - Thursday कानूनी होने जैसी सामग्री के साथ भी समाप्त नहीं होते हैं)। अतिरिक्त कठोरता इसे अधिक निंदनीय निर्माण सामग्री बनाती है। एक भेदभावपूर्ण संघ गैर-इंट-वाई किस्म को अच्छी तरह से मॉडल करता है: pick { A, B, C struct{} } , अन्य चीजों के साथ।

इस तरह की जानकारी को भाषा में रखने का प्रमुख लाभ यह है कि

1. अवैध मूल्य अवैध हैं।
2. जानकारी को प्रतिबिंबित करने और जाने/प्रकारों के लिए उपलब्ध है जो कार्यक्रमों को धारणाओं या एनोटेशन (जो वर्तमान में प्रतिबिंबित करने के लिए उपलब्ध नहीं हैं) की आवश्यकता के बिना उस पर कार्य करने की इजाजत देता है।

इस तरह की जानकारी को भाषा में रखने का प्रमुख लाभ यह है कि: अवैध मूल्य अवैध हैं।

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

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

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

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

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

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

पीएस: मैं मानता हूं कि enums योग प्रकार का एक विशेष मामला है और उस मुद्दे को इस पर प्राथमिकता लेनी चाहिए।

मुझे और अधिक सटीक होने दें: हर कोई इसे बंद होने के लिए लाभ के रूप में नहीं देखता है।

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

यदि एनम इनट्स हैं और कोई भी इंट कानूनी है (टाइप सिस्टम के दृष्टिकोण से) तो एकमात्र लाभ यह है कि प्रकार के नामित मान प्रतिबिंबित होते हैं।

यह मूल रूप से सिर्फ const/iota है लेकिन आपको स्ट्रिंगर चलाने की ज़रूरत नहीं है क्योंकि fmt पैकेज प्रतिबिंब का उपयोग करके नाम प्राप्त कर सकता है। (यदि आप चाहते हैं कि तार स्रोत में नामों से भिन्न हों तो आपको अभी भी स्ट्रिंगर चलाना होगा)।

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

उदाहरण के लिए, कुछ इस तरह दिया गया

type Foo enum {
    Val1 = 1
    Val2 = 2
}

और परावर्तन विधि जैसे

func IsValidEnum(v {}interface) bool

हम कुछ ऐसा कर सकते हैं

a := Foo.Val1
b := Foo(-1)
reflection.IsValidEnum(a) //returns true
reflection.IsValidEnum(b)  //returns false

एक वास्तविक दुनिया के उदाहरण के लिए आप सी # में एनम देख सकते हैं, जो मेरी राय में, जावा ने जो किया उसका आँख बंद करके अनुसरण करने के बजाय इस मध्य मैदान पर पूरी तरह से कब्जा कर लिया। सी # में वैधता की जांच के लिए आप Enum.IsDefined स्थिर विधि का उपयोग करते हैं।

@crecker उस और कॉन्स्ट/आईओटा के बीच एकमात्र अंतर है
प्रतिबिंब में संग्रहीत जानकारी। यह संपूर्ण के लिए बहुत अधिक लाभ नहीं है
नए प्रकार का।

थोड़ा पागल विचार:

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

मेरे लिए मुख्य विशेषता, जैसा कि आप ऊपर मेरे प्रस्ताव में पढ़ सकते हैं

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

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

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

जावा एनम के आसपास काम करने के लिए जावा के लिए प्रोटोबफ को उत्पन्न करने के लिए बस देखें।

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

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

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

@crecker उपरोक्त में निर्यात डेटा में कॉन्स्ट को स्टोर करने का मेरा सुझाव है
परिस्थितियाँ उस तरह की चीज़ों की अनुमति देंगी जो आप माँग रहे हैं
एक नए प्रकार के परिचय के बिना।

मुझे यकीन नहीं है कि यह मुहावरेदार तरीका है, और मैं भाषा के लिए भी काफी नया हूं, लेकिन निम्नलिखित काम करता है और संक्षिप्त है

type Day struct {
    value string
}

// optional, if you need string representation
func (d Day) String() string { return d.value }

var (
    Monday = Day{"Monday"}
    Tuesday = Day{"Tuesday"}
)

func main() {
    getTask(Monday)
}

func getTask(d Day) string {
    if d == Monday {
        fmt.Println("today is ", d, "!”) // today is Monday !
        return "running"
    }

    return "nothing to do"
}

लाभ :

• आपको type Day से func getTask . से अलग कुछ पास करने की अनुमति नहीं देता है
  https://play.golang.org/p/4JZOIG5PbRX

• पुन: क्रमित करने से आपका कोड नहीं टूटता ( iota इसके बजाय मुश्किल हैं)

• कोड जनरेटर की कोई आवश्यकता नहीं

• नक्शे के साथ इस्तेमाल किया जा सकता है
  https://play.golang.org/p/KlTNWrJpbDi

• पुनरावृत्त किया जा सकता है
  https://play.golang.org/p/ld3TNtenEkD

नुकसान :

• आप अभी भी एक अनाम संरचना को getTask तक संकलक शिकायत के बिना पास कर सकते हैं
  https://play.golang.org/p/NaV38og7e2h

• निरंतर संरचनाएं समर्थित नहीं हैं, केवल var
  https://play.golang.org/p/X6KSPACA4N0

क्या हमें वास्तव में एनम की आवश्यकता है?

किसी को ऐसा कुछ करने से रोकने के लिए क्या है:

NotADay := Day{"NotADay"}
getTask(NotADay)

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

@bpkroth
अपने पैकेज में Day होने और केवल चयनित फ़ील्ड और विधियों को उजागर करके, मैं $#$ package day $#$ के बाहर Day प्रकार के नए मान नहीं बना सकता
साथ ही, इस तरह मैं अज्ञात structs को getTask . पर पास नहीं कर सकता

./दिन/दिन.go

package day

type Day struct {
    value string
}

func (d Day) String() string { return d.value }

var (
    Monday  = Day{"Monday"}
    Tuesday = Day{"Tuesday"}
    Days    = []Day{Monday, Tuesday}
)

./main.go

package main

import (
    "fmt"
    "github.com/somePath/day"
)

func main() {
    january := day.Day{"january"} // implicit assignment of unexported field 'value' in day.Day literal

    var march struct {
        value string
    }
    march.value = "march"
    getTask(march) // cannot use march (type struct { value string }) as type day.Day in argument to getTask

    getTask(day.Monday)
}

func getTask(d day.Day) string {
    if d == day.Monday {
        fmt.Println("today is ", d, "!") // today is Monday !
        return "running"
    }

    return "nothing to do"
}

func iterateDays() {
    for _, d := range day.Days {
        fmt.Println(d)
    }
}

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

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

@ gh67uyyghj किसी ने आपकी टिप्पणी को विषय से परे के रूप में चिह्नित किया है! और मुझे लगता है कि कोई मेरे उत्तर के लिए भी ऐसा ही करेगा। लेकिन मुझे लगता है कि आपके प्रश्न का उत्तर हाँ है। GoLang में फीचरलेस होने का मतलब है कि कुछ भी जो GoLang के पास नहीं है, वह वास्तव में एक फीचर है जो GoLang के पास है जो अन्य प्रोग्रामिंग भाषाओं में नहीं है !!

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

• लिखो
• पढ़ना
• के बारे में कारण

आपके उदाहरण में (जो बहुत अच्छा है क्योंकि यह आज काम करता है) एनम (किसी न किसी रूप में) होने का तात्पर्य है:

• एक स्ट्रक्चर टाइप बनाएं
• एक विधि बनाएँ
• चर बनाएं (स्थिरांक भी नहीं, हालांकि पुस्तकालय का एक उपयोगकर्ता उन मूल्यों को नहीं बदल सकता है)

इसे पढ़ने, लिखने और इसके बारे में तर्क करने में अधिक समय लगता है (हालांकि _that_ अधिक समय नहीं) (यह समझें कि यह प्रतिनिधित्व करता है और इसे एनम के रूप में उपयोग किया जाना चाहिए)।

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

धन्यवाद @andradei
हाँ यह एक समाधान है, लेकिन मुझे लगता है कि भाषा का उद्देश्य इसे छोटा और सरल रखना है
हम यह भी तर्क दे सकते हैं कि हम कक्षाओं को याद करते हैं, लेकिन फिर चलिए जावा पर चलते हैं :)

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

अपने बिंदुओं पर लौटना:

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

package day

// Day Enum
type Day struct {
    value string
}

@ एल-ओरिस मैं देखता हूं। मैं गो 2 के प्रस्तावों को लेकर भी उत्साहित हूं। मेरा तर्क है कि जेनरिक भाषा की जटिलता को एनमों से अधिक बढ़ा देगा। लेकिन अपनी बातों पर टिके रहने के लिए:

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

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

दोस्तों, वास्तव में इस सुविधा को भविष्य के लिए चाहते हैं! पॉइंटर्स और " एनम्स " को _nowdays_ में परिभाषित करने का तरीका बहुत अच्छी तरह से नहीं मिलता है। उदाहरण के लिए: https://play.golang.org/p/A7rjgAMjfCx

Enum के लिए मेरा प्रस्ताव निम्नलिखित है। हमें इसे एक नए प्रकार के रूप में मानना ​​​​चाहिए। उदाहरण के लिए मैं मनमानी संरचना और निम्नलिखित कार्यान्वयन के साथ एनम प्रकार का उपयोग करना चाहता हूं:

package application

type Status struct {
Name string
isFinal bool
}

enum Status {
     Started = &Status{"Started",false}
     Stopped = &Status{"Stopped",true}
     Canceled = &Status{"Canceled",true}
}

// application.Status.Start - to use

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

इसके लिए गो को पहले गहरी अपरिवर्तनीय संरचनाओं का समर्थन करना होगा। अपरिवर्तनीय प्रकारों के बिना मैं कल्पना कर सकता हूं कि आप एक ही चीज़ के लिए एनम के साथ ऐसा कर सकते हैं:

type Status enum {
  Started
  Stopped
}

func isFinal(s Status) bool {
  exhaustive switch(s) {
    case Started: return false;
    case Stopped: return true;
  }
}

मुझे लगता है कि यह आसान दिखना चाहिए

func isFinal(s Status) bool {
  return s == Status.Stopped
}

Go2 . के लिए प्रस्ताव

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

enum Status uint8 {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}
// or 
enum Status string  {
  Started // Status.Started == "Started", like it works with JSON
  Stopped // Status.Stopped == "Stopped", etc
}
// unless you wanna define its values explicitly
enum Status {
  Started "started"  // compiler can infer underlying type
  Stopped "finished"
}
// and enums are type extensions and should be used like this
type MyStatus Status

MyStatus validatedStatus // holds a nil until initialized

// for status value validation we can use map pattern
if validatedStatus, ok := MyStatus[s]; ok {
  // this value is a valid status
  // and we can use it later as regular read-only string
  // or like this
  if validatedStatus == MyStatus.Started {
     fmt.Printf("Hey, my status is %s", validatedStatus)
  }
}

Enums प्रकार एक्सटेंशन हैं, "स्थिरांक कंटेनर"।

टाइप लवर्स के लिए

जो लोग इसे टाइप के रूप में देखना चाहते हैं उनके लिए सिंटेक्स विकल्प

type Status uint8 enum {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

लेकिन हम उन स्पष्ट शीर्ष स्तरीय घोषणाओं से भी बच सकते हैं

type Status enum {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

सत्यापन उदाहरण वही रहता है।

लेकिन मामले में

type Status1 uint8 enum {
  Started  // Status1.Started == 0
  Stopped // Status1.Stopped == 1, etc, like we have used iota
}

type Status2 uint8 enum {
  Started  // Status1.Started == 0
  Stopped // Status1.Stopped == 1, etc, like we have used iota
}

Status1.Started == Status2.Started के बारे में कैसा है?
मार्शलिंग के बारे में?

अगर मैं कोई पद बदलूं?

type Status uint8 enum {
  Started  // Status.Started == 0
  InProcess
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

मैं अपरिवर्तनीय प्रकारों के बारे में @Goodwine से सहमत हूं।

मार्शलिंग एक दिलचस्प सवाल है।
यह सब इस बात पर निर्भर करता है कि हम अंतर्निहित मूल्य के साथ कैसा व्यवहार करने जा रहे हैं। यदि हम वास्तविक मूल्यों का उपयोग करने जा रहे हैं, तो Status1.Started बराबर होगा Status2.Started ।
यदि हम प्रतीकात्मक व्याख्या के साथ जा रहे हैं तो उन्हें अलग-अलग मूल्य माना जाएगा।

कुछ डालने से मूल्यों में परिवर्तन होगा (ठीक उसी तरह जैसे यह iota के साथ जाता है)।
इससे बचने के लिए डेवलपर को घोषणाओं के साथ मान निर्दिष्ट करना होगा।

type Status uint8 enum {
  Started  0
  InProcess 2
  Stopped 1
}

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

मुझे पसंद है कि कैसे जंग को Enums लागू किया जाता है।

बिना किसी प्रकार के निर्दिष्ट के साथ डिफ़ॉल्ट

enum IpAddr {
    V4,
    V6,
}

कस्टम प्रकार

enum IpAddr {
    V4(string),
    V6(string),
}

home := IpAddr.V4("127.0.0.1");
loopback := IpAddr.V6("::1");

जटिल प्रकार

enum Message {
    Quit,
    Move { x: int32, y: int32 },
    Write(String),
    ChangeColor(int32, int32, int32),
}

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

उपरोक्त enum s से आगे जाते हैं, वे _भेदभाव वाले संघ_ हैं, जो वास्तव में अधिक शक्तिशाली हैं, विशेष रूप से _pattern मिलान_ के साथ, जो switch का मामूली विस्तार हो सकता है, कुछ इस तरह:

switch something.(type) {
case Quit:
        ...
case ChangeColor; r, g, b := something:
        ...
case Write: // Here `something` is known to be a string
        ...
// Ideally Go would warn here about the missing case for "Move"
}

मुझे एनम के किसी भी संकलन समय की जाँच की आवश्यकता नहीं है, क्योंकि यह खतरनाक हो सकता है जैसा कि उल्लेख किया गया है

किसी दिए गए प्रकार के सभी स्थिरांकों पर पुनरावृति करने के लिए मुझे कई बार जो चाहिए था:

• या तो सत्यापन के लिए (यदि हमें पूरा यकीन है कि हम केवल इसे स्वीकार करना चाहते हैं या केवल अज्ञात विकल्पों को अनदेखा करना चाहते हैं)
  
  
  
  • या संभावित स्थिरांक की सूची के लिए (ड्रॉपडाउन के बारे में सोचें)।
  
  

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

इसके लिए कड़े नाम निर्दिष्ट करना एक अच्छा अतिरिक्त होगा।

किसी को ऐसा कुछ करने से रोकने के लिए क्या है:

NotADay := Day{"NotADay"}
getTask(NotADay)

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

@ एल-ओरिस तो इसके बारे में क्या:

package main
import "yet/it/is/not/a/good/practice/in/Go/enum/example/day"

func main()
{
  // var foo day.Day
  foo := day.Day{}
  bar(foo)
}

func bar(day day.Day)
{
  // xxxxxxxxxx
}

हम जो चाहते हैं वह रनटाइम साइलेंस और अजीब बग नहीं है [वापसी "कुछ भी नहीं"] लेकिन एक संकलन-समय/कोडिंग-समय त्रुटि रिपोर्टिंग !
समझना?

1. enum वास्तव में नया प्रकार है, जो कि type State string करता है, एक नया कीवर्ड पेश करने की कोई मुहावरेदार आवश्यकता नहीं है। गो आपके स्रोत कोड में स्थान बचाने के बारे में नहीं है, यह पठनीयता, उद्देश्य की स्पष्टता के बारे में है।

2. प्रकार की सुरक्षा का अभाव, नए string - या int -आधारित प्रकारों को वास्तविक स्ट्रिंग्स/इंट्स के लिए भ्रमित करना प्रमुख बाधा है। सभी एनम क्लॉज को const के रूप में घोषित किया जाता है, जो ज्ञात मूल्यों का एक सेट बनाता है जिसे कंपाइलर चेक कर सकता है।

3. Stringer इंटरफ़ेस मानव-पठनीय पाठ के रूप में किसी भी प्रकार का प्रतिनिधित्व करने के लिए मुहावरा है। अनुकूलन के बिना, type ContextKey string यह मानता है कि यह स्ट्रिंग मान है, और iota -जेनरेटेड एनम के लिए यह पूर्णांक है, बहुत कुछ जावास्क्रिप्ट में XHR रेडीस्टेट कोड (0 - unsent, 4 - किया गया) की तरह है।

   इसके बजाय, समस्या कस्टम func (k ContextKey) String() string कार्यान्वयन की गिरावट के साथ है, जो आमतौर पर एक स्विच का उपयोग करके किया जाता है जिसमें प्रत्येक ज्ञात एनम क्लॉज स्थिर होना चाहिए।

4. स्विफ्ट जैसी भाषा में _एक संपूर्ण स्विच_ की धारणा है। const s के सेट के विरुद्ध दोनों प्रकार की जाँच के लिए यह एक अच्छा तरीका है और उस चेक को लागू करने के लिए एक मुहावरेदार तरीका बनाना है। String() फ़ंक्शन, एक सामान्य आवश्यकता होने के कारण, कार्यान्वयन के लिए एक बढ़िया मामला है।

प्रस्ताव

package main

import (
    "context"
    "strconv"
    "fmt"
    "os"
)

// State is an enum of known system states.
type DeepThoughtState int

// One of known system states.
const (
    Unknown DeepThoughtState = iota
    Init
    Working
    Paused
    ShutDown
)

// String returns a human-readable description of the State.
//
// It switches over const State values and if called on
// variable of type State it will fall through to a default
// system representation of State as a string (string of integer
// will be just digits).
func (s DeepThoughtState) String() string {
    // NEW: Switch only over const values for State
    switch s.(const) {
    case Unknown:
        return fmt.Printf("%d - the state of the system is not yet known", Unknown)
    case Init:
        return fmt.Printf("%d - the system is initializing", Init)
    } // ERR: const switch must be exhaustive; add all cases or `default` clause

    // ERR: no return at the end of the function (switch is not exhaustive)
}

// RegisterState allows changing the state
func RegisterState(ctx context.Context, state string) (interface{}, error) {
    next, err := strconv.ParseInt(state, 10, 32)
    if err != nil {
        return nil, err
    }
    nextState := DeepThoughtState(next)

    fmt.Printf("RegisterState=%s\n", nextState) // naive logging

        // NEW: Check dynamically if variable is a known constant
    if st, ok := nextState.(const); ok {
        // TODO: Persist new state
        return st, nil
    } else {
        return nil, fmt.Errorf("unknown state %d, new state must be one of known integers", nextState)
    }
}

func main() {
    _, err := RegisterState(context.Background(), "42")
    if err != nil {
        fmt.Println("error", err)
        os.Exit(1)
    }
    os.Exit(0)
    return
}

स्विफ्ट एनम्स में पीएस एसोसिएटेड वैल्यू मेरी पसंदीदा नौटंकी में से एक है। गो में उनके लिए कोई जगह नहीं है। यदि आप अपने एनम डेटा के बगल में एक मूल्य रखना चाहते हैं - दोनों को लपेटकर दृढ़ता से टाइप किए गए struct का उपयोग करें।

कुछ महीने पहले मैंने एक लिंटर के लिए एक प्रूफ-ऑफ-कॉन्सेप्ट लिखा था जो जांचता है कि गणना किए गए प्रकारों को ठीक से संभाला जाता है। https://github.com/loov/enumcheck

वर्तमान में यह चीजों को गणना के रूप में चिह्नित करने के लिए टिप्पणियों का उपयोग करता है:

type Letter byte // enumcheck

const (
    Alpha Letter = iota
    Beta
    Gamma
)

func Switch(x Letter) {
    switch x { // error: "missing cases Beta and Gamma"
    case Alpha:
        fmt.Println("alpha")
    case 4: // error: "implicit conversion of 4 to Letter"
        fmt.Println("beta")
    default: // error: "Letter shouldn't have a default case"
        fmt.Println("default")
    }
}

मैं यह पता लगाने में फंस गया कि सभी निहित रूपांतरणों को कैसे संभालना है, लेकिन यह बुनियादी मामलों के लिए शालीनता से काम करता है।

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

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

@pofl :
जबकि मैं मानता हूं कि गो एनम बहुत अजीब हैं, iota वास्तव में सिर्फ एक सामान्य अंग्रेजी शब्द है:

योटा
_संज्ञा_

1. बहुत कम मात्रा; जोट; सफेद
2. ग्रीक वर्णमाला का नौवां अक्षर (I, )।
3. स्वर ध्वनि इस पत्र द्वारा दर्शाया गया है।

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

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

गो में iota का उपयोग शिथिल रूप से एपीएल में इसके उपयोग पर आधारित है। उद्धरण https://en.wikipedia.org/wiki/Iota :

कुछ प्रोग्रामिंग भाषाओं में (जैसे, A+, APL, C++[6], Go[7]), iota (या तो लोअरकेस प्रतीक ⍳ या पहचानकर्ता iota के रूप में) का उपयोग लगातार पूर्णांकों की एक सरणी का प्रतिनिधित्व करने और उत्पन्न करने के लिए किया जाता है। उदाहरण के लिए, एपीएल में ⍳4 1 2 3 4 देता है।