2012-11-22 15 views
16

बिना संकलन नहीं है यहां कार्यक्रम जाओ में किसी संख्या का फ़ैक्टोरियल मिल रहा है: जब इनपुट 5 पर बुलाया 120. हालांकि हैजाओ कोड किसी न पहुंचने योग्य वापसी कथन

func factorial(x uint) uint { 
    if x == 0 { 
     return 1 
    } 

    return x * (factorial(x - 1)) 
} 

इस कार्य के लिए उत्पादन, अगर मैं else कथन जोड़ता हूं तो मुझे एक त्रुटि मिलती है।

func factorial(x uint) uint { 
    if x == 0 { 
     return 1 
    } else { 
     return x * (factorial(x - 1)) 
    } 
} 

त्रुटि: function ends without a return statement

मैं अंत में एक return कहा:

func factorial(x uint) uint { 
    if x == 0 { 
     return 1 
    } else { 
     return x * (factorial(x - 1)) 
    } 
    fmt.Println("this never executes") 
    return 1 
} 

और मैं क्यों दूसरे मामले एक कारण होगा 120

की उम्मीद उत्पादन वापस मिल त्रुटि? तीसरे मामले में क्यों समारोह कभी भी पिछले return 1 तक नहीं पहुंचता है, यह सही आउटपुट की गणना करता है?

+1

यह 'id cond {return} का उपयोग करने के लिए जाने में मूर्खतापूर्ण है; वापसी '(स्पष्ट रूप से एक पंक्ति पर नहीं)। जब आपके पास लूप के लिए अंतहीन होता है जहां लूप के बाद कुछ भी निष्पादित नहीं होता है, तो सामान्य मुहावरे 'आतंक ("पहुंच योग्य नहीं)' जोड़ना है। –

+0

अंतिम बयान एक 'आतंक ("कभी नहीं पहुंचा") बनाओ ' – thwd

उत्तर

22

यह कंपाइलर की एक प्रसिद्ध समस्या है।

भी एक मुद्दा लॉग इन किया है: http://code.google.com/p/go/issues/detail?id=65

जाओ भाषा के लेखकों में से एक के शब्दों में:

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

-rob

एक और टिप्पणी in golang-nuts से, हम अनुमान लगा सकते हैं यह करने के लिए जल्दी ही "तय" नहीं किया जा रहा है:

यह एक बग नहीं है, यह एक विचार डिजाइन निर्णय है।

-rob

नोट जावा की तरह अन्य भाषाओं इस else की इजाजत दी नियम है।


मार्च 2013 संपादित करें - यह सिर्फ got changed in Go1.1:

जाओ 1.1 से पहले, एक समारोह है कि एक मान दिया एक स्पष्ट "वापसी" की जरूरत या समारोह के अंत में दहशत फोन ; यह प्रोग्रामर को फ़ंक्शन के अर्थ के बारे में स्पष्ट करने के लिए आसान तरीका था। लेकिन ऐसे कई मामले हैं जहां अंतिम "वापसी" स्पष्ट रूप से अनावश्यक है, जैसे कि केवल एक अनंत "फॉर" लूप वाला फ़ंक्शन।

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

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

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

और मैंने जो मुद्दा बताया है वह अब स्थिति "फिक्स्ड" के साथ बंद है।

संबंधित मुद्दे