अधिक एक प्रकार बाधा

Question

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

class MyCustomClass<T : Equatable, IndexableBase> { 
    var a: Array<T> 
    init() { 
    a = Array<T>() 
    } 
} 

यह कहता है कि प्रारंभकर्ता विफल रहता है क्योंकि मुझे 1 तर्क के बजाय 2 का उपयोग करना होगा। मुझे समझ में नहीं आता है।

Answer 1

आप इस समाधान का

class MyCustomClass<T: Equatable where T: IndexableBase > { 
    var a: Array<T> 
    init() { 
     a = Array<T>() 
    } 
} 

Answer 2

स्विफ्ट उपयोग कर सकते हैं 3

(मैं अपने उदाहरण में Collection साथ IndexableBase बदल दिया है, यदि आप बाद पसंद किए जाने वाले)

---

स्विफ्ट 3 के अनुसार, प्रोटोकॉल संरचना इंफिक्स ओपे का उपयोग करती है rator & पिछले protocol<...> निर्माण से अधिक, स्वीकार किए जाते हैं और कार्यान्वित विकास प्रस्ताव में वर्णित हैं:

• SE-0095: Replace protocol<P1,P2> syntax with P1 & P2 syntax

इसलिए, प्रोटोकॉल रचना का उपयोग कर आप संयुक्त प्रकार बाधा पैरामीटर में T प्लेसहोल्डर में जगह हो सकती है सूची:

class MyCustomClass<T: Equatable & Collection> { /* ... */ } 

---

प्रोटोकॉल संरचना के विकल्प के रूप में, आप कई प्रकार (और उप प्रकार) बाधा में शामिल होने के लिए where खंड का भी उपयोग कर सकते हैं। प्रति स्वीकार कर लिया है और कार्यान्वित विकास प्रस्ताव के रूप में:

• Se-0081: Move where clause to end of declaration

where खंड घोषणा के अंत में ले जाया गया है, ऐसी स्थिति में अपने उदाहरण में लिखा होगा:

class MyCustomClass<T: Equatable> where T: Comparable { /* ... */ } 

या , घोषणापत्र

के अंत में where खंड के साथ पूर्ण प्रोटोकॉल संरचना भी रखें

class MyCustomClass<T> where T: Equatable & Comparable { /* ... */ } 

---

हम क्या शैली पसंद करते हैं चाहिए?

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

पैरामीटर सूची में
• सभी (मुख्य प्रकार) की कमी, या
घोषणा के अंत में सभी बाधाओं
• , या
• पैरामीटर सूची और अन्य लोगों पर रखा में से कुछ के साथ बाधाओं को विभाजित घोषणा का अंत?

निम्नलिखित काल्पनिक उदाहरण है, जहाँ हम एक निर्माण एक प्रोटोकॉल है कि हम एक प्रकार बाधा (Doable) है, जो अपने आप में एक associatedtype रखती है जो हम एक प्रकार बाधा जगह हो सकती है के रूप में उपयोग करने की योजना है पर विचार करें।

protocol Doable { 
    associatedtype U 
} 

ऊपर विभिन्न तरीकों का उपयोग करना, सभी निम्नलिखित तीन विकल्प, मान्य हैं वाक्य रचना

// alternative #1 
func foo<T: Equatable & Doable>(_ bar: T) ->() where T.U: Comparable { /* ... */ } 

// alternative #2 
func foo<T: Equatable>(_ bar: T) ->() where T: Doable, T.U: Comparable { /* ... */ } 

// alternative #3 
func foo<T>(_ bar: T) ->() where T: Equatable & Doable, T.U: Comparable { /* ... */ } 

मैं the evolution thread that that brought forth SE-0081 से एप्पल देव जो Groff बोली होगी:

यह एक निर्णय कॉल है । यह मेरा लग रहा है कि कई मामलों में, एक सामान्य पैरामीटर कम से कम एक महत्वपूर्ण प्रोटोकॉल या आधार वर्ग कि, सामने बाहर बुला लायक है तो यह Collection banishing के बिना की तरह

func foo<C: Collection>(x: C) -> C.Element 

बातें अनुमति देने के लिए उचित है से विवश है घोषणा के सामने से बहुत दूर बाधा।

तो ऊपर काल्पनिक उदाहरण में, यह उचित पैरामीटर सूची में प्रकार की कमी है जो सीधे जेनेरिक प्लेसहॉल्डर T के लिए लागू करने के लिए प्रोटोकॉल रचना का उपयोग करने के लिए, और जगह इन बाधाओं हो सकता है, जबकि T.U की उप-प्रकार बाधा है घोषणा के अंत में रखा गया। अर्थात्, वैकल्पिक # 1 ऊपर।