विधि रिटर्न प्रकार

Question

पर टाइप अनुमान क्यों विधि में विधि का उपयोग किए जाने वाले स्पष्ट return कथन के दौरान स्काला विधि के रिटर्न प्रकार का अनुमान लगाने में विफल रहता है?

उदाहरण के लिए, निम्न कोड संकलित क्यों करता है?

object Main { 
    def who = 5 
    def main(args: Array[String]) = println(who) 
} 

लेकिन निम्नलिखित नहीं है।

object Main { 
    def who = return 5 
    def main(args: Array[String]) = println(who) 
} 

Answer 1

किसी विधि का रिटर्न प्रकार या तो उस ब्लॉक में अंतिम कथन का प्रकार है जो इसे परिभाषित करता है, या उस ब्लॉक की अनुपस्थिति में अभिव्यक्ति के प्रकार को परिभाषित करता है।

जब आप किसी विधि के अंदर return का उपयोग करते हैं, तो आप एक और कथन प्रस्तुत करते हैं जिससे विधि वापस आ सकती है। इसका मतलब है कि स्काला उस बिंदु पर return के प्रकार को निर्धारित नहीं कर सकता है। इसके बजाए, इसे विधि के अंत तक आगे बढ़ना चाहिए, फिर अपने निकास के लिए सभी निकास बिंदुओं को गठबंधन करना चाहिए, और फिर इन निकास बिंदुओं में से प्रत्येक पर वापस जाएं और उनके प्रकार असाइन करें।

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

तो अंत में, कंपाइलर जटिलता और लाभ के बीच संतुलन में, बाद वाले को पूर्व के लायक नहीं माना जाता था।

Answer 2

मुझे यकीन नहीं है कि क्यों। शायद return कथन के उपयोग को हतोत्साहित करने के लिए। :)

Answer 3

को देखते हुए इस (2.8.Beta1):

object Main { 
    def who = return 5 
    def main(args: Array[String]) = println(who) 
} 
<console>:5: error: method who has return statement; needs result type 
     def who = return 5 

... यह अनजाने में नहीं लगता है।

Answer 4

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

def foo(xs: List[Int]) = xs map { i => return i; i } 

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

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

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

कहानी का नैतिक: अपने रिटर्न को तितर-बितर न करना सीखें! स्कैला न सिर्फ किसी भी भाषा में यह अच्छी सलाह है।