"++" और "-" ऑपरेटरों को Xcode 7.3 में पदावनत किया गया है


139

मैं Xcode 7.3 नोट देख रहा हूं और मैं इस मुद्दे को देखता हूं।

++ और - ऑपरेटरों को पदावनत कर दिया गया है

क्या कोई यह समझा सकता है कि यह पदावनत क्यों है? और मैं सही Xcode के नए संस्करण में अब आप के बजाय का उपयोग करने जा कि ++इस x += 1;

उदाहरण:

for var index = 0; index < 3; index += 1 {
    print("index is \(index)")
}

चेतावनी के लिए स्क्रीनशॉट


6
मुझे लगता है कि यह सवाल मुख्य रूप से स्टैटोरवर्फ्लो के दायरे से बाहर है क्योंकि स्विफ्ट विकास के सभी स्वीकृत प्रस्ताव गिथब में मिल सकते हैं, आप इस प्रस्ताव के बारे में अधिक पढ़ सकते हैं क्यों github.com/apple/swift-evolution/blobmaster / प्रस्तावों /…
विक्टर सिगलर

7
मैं गंभीरता से सिर्फ उद्देश्य-सी पर वापस जाने पर विचार कर रहा हूं। यह स्विफ्ट के सभी परिवर्तनों के साथ रखने की कोशिश करने के लायक नहीं है।
ग्रेग ब्राउन

3
@OlegGordiichuk यह बात है कि सी-स्टाइल के लिए लूप्स को भी हटा दिया जाएगा, इस github.com/Vkt0r/swift-evolution/blob/master/proposals/… को देखें, ताकि आपको ++और --ऑपरेटरों के उपयोग की आवश्यकता न हो
विक्टर सिगलर

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

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

जवाबों:


210

स्विफ्ट के निर्माता क्रिस लट्टनर से यहां एक पूरी व्याख्या । मैं अंकों को संक्षेप में बताऊंगा:

  1. यह एक और कार्य है जो आपको स्विफ्ट सीखने के दौरान सीखना होगा
  2. से ज्यादा छोटा नहीं है x += 1
  3. स्विफ्ट सी नहीं है। केवल सी प्रोग्रामर को खुश करने के लिए उन्हें ऊपर नहीं ले जाना चाहिए
  4. इसका मुख्य उपयोग लूप के लिए सी-स्टाइल में है: for i = 0; i < n; i++ { ... }स्विफ्ट के पास बेहतर विकल्प हैं, जैसे for i in 0..<n { ... }(लूप के लिए सी-स्टाइल भी अच्छा है )
  5. पढ़ सकते हैं और बनाए रखने के लिए मुश्किल हो सकता है, उदाहरण के लिए, का मूल्य क्या है x - ++xया foo(++x, x++)?
  6. क्रिस लट्टनर को यह पसंद नहीं है।

उन लोगों के लिए (और लिंक सड़ने से बचने के लिए), लट्टनर के अपने शब्दों में कारण हैं:

  1. ये ऑपरेटर स्विफ्ट को पहली प्रोग्रामिंग भाषा के रूप में सीखने के लिए बोझ बढ़ाते हैं - या कोई अन्य मामला जहां आप पहले से ही इन ऑपरेटरों को एक अलग भाषा से नहीं जानते हैं।

  2. उनका अभिव्यंजक लाभ न्यूनतम है - x ++ x + = 1 से बहुत कम नहीं है।

  3. स्विफ्ट सी में पहले से ही विचलन करता है =, + = और अन्य असाइनमेंट जैसे ऑपरेशन शून्य (कई कारणों के लिए) देता है। ये ऑपरेटर उस मॉडल के साथ असंगत हैं।

  4. स्विफ्ट में शक्तिशाली विशेषताएं हैं जो कई सामान्य कारणों को समाप्त करती हैं जिन्हें आप ++ के लिए सी-स्टाइल में अन्य भाषाओं में लूप के लिए उपयोग करेंगे, इसलिए ये अच्छी तरह से लिखित स्विफ्ट कोड में अपेक्षाकृत उपयोग किए जाते हैं। इन विशेषताओं में फॉर-लूप, रेंज, एनुमरेट, मैप इत्यादि शामिल हैं।

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

  6. जबकि स्विफ्ट ने मूल्यांकन के क्रम को अच्छी तरह से परिभाषित किया है, इस पर निर्भर कोई भी कोड (जैसे कि फू (++ a, a ++)) भले ही परिभाषित हो, अवांछनीय होगा।

  7. ये ऑपरेटर अपेक्षाकृत कुछ प्रकारों पर लागू होते हैं: पूर्णांक और फ्लोटिंग पॉइंट स्केलर और इट्रेटर जैसी अवधारणाएँ। वे जटिल संख्याओं, मैट्रीस आदि पर लागू नहीं होते हैं।

अंत में, ये "यदि हमारे पास पहले से ही ये नहीं थे, तो हम मीट्रिक 3 को स्विफ्ट 3 में जोड़ देंगे?"


54
मैं बात करता हूं, असली जवाब नंबर 6 है। यह ठीक है, हम (पूर्व सी, जावा, ... प्रोग्रामर) काफी लचीले हैं :-)। आमतौर पर, वास्तविक दुनिया के लिए, म्यूटेशन, क्रॉसओवर और चयन पर्याप्त है। मैं, आप और संकट भी, हम उन तीन ऑपरेटरों के सभी परिणाम हैं ...
user3441734

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

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

8
यह कारण है कि सेब आपको पसंद करने के लिए मजबूर करने के लिए पसंद करता है। मुझे लगता है कि यह पूरी तरह से ठीक है और कहीं भी उपयोग किया जाता है आपको एक चर बढ़ाने या घटाने की आवश्यकता होती है। यह कुछ ऐसा नहीं है जिसे आपको सीखना है "आप इसके बिना ठीक करेंगे। और # 5 सिर्फ खराब लिखा हुआ कोड है, जिसकी पसंद मैंने कभी नहीं देखी। तो # 6 है। यह दर्शाता है कि मुझे अपना सिर खुजाने और गूगल सर्च करने के लिए पर्याप्त है, इसलिए अपना समय बर्बाद करने के लिए धन्यवाद क्रिस।
csga5000

4
@ csga5000 यह काफी कमजोर तर्क है कि यदि आप वास्तव में चाहते हैं तो आप ऑपरेटर को खुद को परिभाषित कर सकते हैं। इसका सेब से कोई लेना-देना नहीं है लोग चाहते हैं कि वे उनकी तरह सोचें। यह बस भाषा के लायक नहीं है। यदि ++सी-शैली भाषाओं में मौजूद नहीं था, तो उनके दाहिने दिमाग में कोई भी स्विफ्ट 3.0 के डिजाइन को नहीं देखेगा और सोचता है कि एक ++ऑपरेटर इसके लिए एक अच्छा अतिरिक्त होगा।
ओवरएक्टर

37

मुझे पता है कि यह टिप्पणी इस सवाल का जवाब नहीं देती है, फिर भी कोई समाधान ढूंढने वाले लोग हो सकते हैं कि इन ऑपरेटरों को कैसे काम करना है और इस तरह के समाधान को नीचे पाया जा सकता है। 😇

मैं व्यक्तिगत रूप से पसंद करता हूं ++और --ऑपरेटरों। मैं इस राय से सहमत नहीं हो सकता कि वे मुश्किल हैं या उन्हें प्रबंधित करना मुश्किल है। एक बार डेवलपर समझ जाता है कि ये ऑपरेटर क्या करते हैं (और हम बहुत सरल सामान के बारे में बात कर रहे हैं) कोड बहुत स्पष्ट होना चाहिए।

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

मैं यह भी उल्लेख करना चाहूंगा कि varName++एक मूल्य लौटाता है, इसलिए इसका उपयोग किया जा सकता है returnजबकि इसमें varName += 1नहीं हो सकता।

आप में से कोई भी जो इन ऑपरेटरों को यहां काम करना चाहता है, वह समाधान है:

prefix operator ++ {}
postfix operator ++ {}

prefix operator -- {}
postfix operator -- {}


// Increment
prefix func ++(inout x: Int) -> Int {
    x += 1
    return x
}

postfix func ++(inout x: Int) -> Int {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt) -> UInt {
    x += 1
    return x
}

postfix func ++(inout x: UInt) -> UInt {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int8) -> Int8 {
    x += 1
    return x
}

postfix func ++(inout x: Int8) -> Int8 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt8) -> UInt8 {
    x += 1
    return x
}

postfix func ++(inout x: UInt8) -> UInt8 {
    x += 1
    return (x - 1)
}
prefix func ++(inout x: Int16) -> Int16 {
    x += 1
    return x
}

postfix func ++(inout x: Int16) -> Int16 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt16) -> UInt16 {
    x += 1
    return x
}

postfix func ++(inout x: UInt16) -> UInt16 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int32) -> Int32 {
    x += 1
    return x
}

postfix func ++(inout x: Int32) -> Int32 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt32) -> UInt32 {
    x += 1
    return x
}

postfix func ++(inout x: UInt32) -> UInt32 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Int64) -> Int64 {
    x += 1
    return x
}

postfix func ++(inout x: Int64) -> Int64 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: UInt64) -> UInt64 {
    x += 1
    return x
}

postfix func ++(inout x: UInt64) -> UInt64 {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Double) -> Double {
    x += 1
    return x
}

postfix func ++(inout x: Double) -> Double {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Float) -> Float {
    x += 1
    return x
}

postfix func ++(inout x: Float) -> Float {
    x += 1
    return (x - 1)
}

prefix func ++(inout x: Float80) -> Float80 {
    x += 1
    return x
}

postfix func ++(inout x: Float80) -> Float80 {
    x += 1
    return (x - 1)
}

prefix func ++<T : _Incrementable>(inout i: T) -> T {
    i = i.successor()
    return i
}

postfix func ++<T : _Incrementable>(inout i: T) -> T {
    let y = i
    i = i.successor()
    return y
}

// Decrement
prefix func --(inout x: Int) -> Int {
    x -= 1
    return x
}

postfix func --(inout x: Int) -> Int {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt) -> UInt {
    x -= 1
    return x
}

postfix func --(inout x: UInt) -> UInt {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int8) -> Int8 {
    x -= 1
    return x
}

postfix func --(inout x: Int8) -> Int8 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt8) -> UInt8 {
    x -= 1
    return x
}

postfix func --(inout x: UInt8) -> UInt8 {
    x -= 1
    return (x + 1)
}
prefix func --(inout x: Int16) -> Int16 {
    x -= 1
    return x
}

postfix func --(inout x: Int16) -> Int16 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt16) -> UInt16 {
    x -= 1
    return x
}

postfix func --(inout x: UInt16) -> UInt16 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int32) -> Int32 {
    x -= 1
    return x
}

postfix func --(inout x: Int32) -> Int32 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt32) -> UInt32 {
    x -= 1
    return x
}

postfix func --(inout x: UInt32) -> UInt32 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Int64) -> Int64 {
    x -= 1
    return x
}

postfix func --(inout x: Int64) -> Int64 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: UInt64) -> UInt64 {
    x -= 1
    return x
}

postfix func --(inout x: UInt64) -> UInt64 {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Double) -> Double {
    x -= 1
    return x
}

postfix func --(inout x: Double) -> Double {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Float) -> Float {
    x -= 1
    return x
}

postfix func --(inout x: Float) -> Float {
    x -= 1
    return (x + 1)
}

prefix func --(inout x: Float80) -> Float80 {
    x -= 1
    return x
}

postfix func --(inout x: Float80) -> Float80 {
    x -= 1
    return (x + 1)
}

prefix func --<T : BidirectionalIndexType>(inout i: T) -> T {
    i = i.predecessor()
    return i
}

postfix func --<T : BidirectionalIndexType>(inout i: T) -> T {
    let y = i
    i = i.predecessor()
    return y
}

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

मुझे यह पसंद नहीं है, लेकिन मुझे ऐसा करने के किसी अन्य (बेहतर, क्लीनर) तरीके के बारे में नहीं पता है। मैं आपके दूसरे बिंदु को पूरी तरह से नहीं समझता।
0101

1
मैं देख रहा हूँ, मैं ऐसा नहीं चाहता था कि केवल एक और चर बनाने के लिए (या इस मामले में निरंतर)। यदि हम Intकेवल के बारे में बात कर रहे हैं, तो परिणाम का परिणाम अधिक (x + 1)हो जाएगा जो निष्पादन को बाधित करेगा और इसलिए result - 1इसे भी नहीं चलाया जाएगा। Doubleउदाहरण के लिए अन्य डेटाटाइप्स अलग तरह से व्यवहार करते हैं, इसलिए मुझे इसकी जांच करने की आवश्यकता है।
0101

3
आप इसके deferलिए भी उपयोग कर सकते हैं । defer { x += 1 }; return x
टिम वर्म्यूलेन

4
क्यों नहीं जेनेरिक का उपयोग करें और इसे कुछ पंक्तियों में लिखें?
--ολ17ν.λαβέ

22

Apple ने ++इसे हटा दिया है और इसे एक और पुराने पारंपरिक तरीके से बहुत सरल बना दिया है।

इसके बजाय ++, आपको लिखने की ज़रूरत है +=

उदाहरण:

var x = 1

//Increment
x += 1 //Means x = x + 1 

इसी तरह डिक्रिप्शन ऑपरेटर के लिए --, आपको लिखना होगा-=

उदाहरण:

var x = 1

//Decrement
x -= 1 //Means x = x - 1

के लिए forछोरों:

वृद्धि उदाहरण:

के बजाय

for var index = 0; index < 3; index ++ {
    print("index is \(index)")
}

तुम लिख सकते हो:

//Example 1
for index in 0..<3 {
    print("index is \(index)")
}

//Example 2
for index in 0..<someArray.count {
    print("index is \(index)")
}

//Example 3
for index in 0...(someArray.count - 1) {
    print("index is \(index)")
}

कमी का उदाहरण:

for var index = 3; index >= 0; --index {
   print(index)
}

तुम लिख सकते हो:

for index in 3.stride(to: 1, by: -1) {
   print(index)
}
//prints 3, 2

for index in 3.stride(through: 1, by: -1) {
   print(index)
}
//prints 3, 2, 1

for index in (0 ..< 3).reverse() {
   print(index)
}

for index in (0 ... 3).reverse() {
   print(index)
}

उम्मीद है की यह मदद करेगा!


उन्होंने कुछ भी प्रतिस्थापित नहीं किया है; +=वहाँ सब साथ था।
निकोलस मिआरी

@ निकोलसमीरी हां सिर्फ बेहतर प्रारूप के साथ संपादन
सोहिल आर। मेमन

@NicolasMiari क्या आप कृपया अब जांच कर सकते हैं?
सोहिल आर। मेमन

3
के बारे में ++iऔर क्या --i?
जिगि वोंग

7

क्रिस लट्टनर ++ और - के खिलाफ युद्ध के लिए गया है। वह लिखते हैं, "कोड जो वास्तव में इन ऑपरेटरों के परिणाम मूल्य का उपयोग करता है, अक्सर एक पाठक / कोड के अनुरक्षक के लिए भ्रमित और सूक्ष्म होता है। वे "अत्यधिक मुश्किल" कोड को प्रोत्साहित करते हैं, जो प्यारा हो सकता है, लेकिन समझने में मुश्किल हो सकता है।…। स्विफ्ट स्विफ्ट ने मूल्यांकन के क्रम को अच्छी तरह से परिभाषित किया है, कोई भी कोड जो उस पर निर्भर है (जैसे कि फू (++ a, a ++)) अवांछनीय होगा यदि यह अच्छी तरह से परिभाषित किया गया था ... ये "अगर हमारे पास पहले से ही ये नहीं थे, तो क्या हम उन्हें स्विफ्ट में जोड़ देंगे?"

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


9
स्वच्छ? इस कॉलबैक नरक को देखो और इसे साफ कहो? मैं असहमत हूं ... और मैं
जोड़ूंगा: +++

22
ऐसा कुछ है ...for i in 0.stride(to: 10, by: 2)...या ...for i in (1...10).reverse()...साफ है ?!
mad_manny

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

2
पार्सिंग जोंस और स्विफ्ट की कोशिश करें और मुझे बताएं कि यह कितना साफ है।
निकुथुडे

6

चेतावनी के लिए स्क्रीनशॉट

Fix-it featureXcode के इस के लिए स्पष्ट उत्तर नहीं देता है।

चेतावनी का समाधान

++ increment operatorपुराने जमाने के value += 1(शॉर्ट-हैंड ऑपरेटर) और के -- decrement operatorसाथ बदलेंvalue -= 1


6

स्विफ्ट 4 के लिए, आप ++और --ऑपरेटरों के लिए Intऔर अन्य प्रकार के एक्सटेंशन के रूप में पुनर्स्थापित कर सकते हैं। यहाँ एक उदाहरण है:

extension Int{
   static prefix func ++(x: inout Int) -> Int {
        x += 1
        return x
    }

    static postfix func ++(x: inout  Int) -> Int {
        defer {x += 1}
        return x
    }

    static prefix func --(x: inout Int) -> Int {
        x -= 1
        return x
    }

    static postfix func --(x: inout Int) -> Int {
        defer {x -= 1}
        return x
    }
}

यह अन्य प्रकार के रूप में इस तरह के लिए उसी तरह काम करता UIInt, Int8, Float, Double, आदि

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

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

इस कारण मैंने यह उत्तर पोस्ट किया है क्योंकि मैं कंप्यूटर प्रोग्रामिंग भाषाओं को एक-दूसरे से अनावश्यक रूप से अलग करने से असहमत हूं।

भाषाओं के बीच बहुत सी समानताएँ होने से लोगों को सीखने और एक भाषा से दूसरी भाषा में स्विच करने में आसानी होती है।

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

मेरा मानना ​​है कि केवल आवश्यक के रूप में भाषाओं के बीच वाक्यविन्यास अंतर होना चाहिए, और इससे अधिक नहीं।


मैं प्यार करता हूँ जब भाषाएं अलग होने की "हिम्मत" करती हैं। ईमानदारी से बहुत सी 'सी-सिंटैक्स' भाषाएं हैं, और सी को एक लंबे समय पहले डिज़ाइन किया गया था .. भाषा के अनुभव के 50 से अधिक वर्षों हो गए हैं .. परवाह किए बिना, इस जवाब के रूप में ऑपरेटरों पर एक छेड़छाड़ में नहीं गया था, अभी भी एक उत्थान।
14:28 पर user2864740

5

यहाँ अब तक पोस्ट किए गए कुछ कोड का एक सामान्य संस्करण है। मैं अन्य लोगों की तरह ही चिंताओं का सामना करूंगा: स्विफ्ट में इनका उपयोग नहीं करना एक सर्वोत्तम अभ्यास है । मैं मानता हूं कि यह आपके कोड को भविष्य में पढ़ने वालों के लिए भ्रमित करने वाला हो सकता है।

prefix operator ++
prefix operator --
prefix func ++<T: Numeric> (_ val: inout T) -> T {
    val += 1
    return val
}

prefix func --<T: Numeric> (_ val: inout T) -> T {
    val -= 1
    return val
}

postfix operator ++
postfix operator --
postfix func ++<T: Numeric> (_ val: inout T) -> T {
    defer { val += 1 }
    return val
}

postfix func --<T: Numeric> (_ val: inout T) -> T {
    defer { val -= 1 }
    return val
}

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


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

4

से डॉक्स :

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


दूसरे शब्दों में, इस ऑपरेशन का उपयोग करना बहुत महंगा है?
ओलेग गोर्डिचुक

2
github.com/apple/swift-evolution/blob/master/proposals/… यहां आप इसके बारे में पढ़ सकते हैं, लेकिन यह महंगा नहीं है, बल्कि भाषा डिजाइन है।
डैनियल नेगी

तो जैसा कि आई-एस स्विफ्ट सी-स्टाइल फीचर्स के समर्थन को छोड़ने जा रही है
ओलेग गोर्डिचुक

2
@OlegGordiichuk अच्छी तरह से मैं कहूंगा कि वे जोर देना चाहते हैं कि स्विफ्ट ऑब्जेक्टिव-सी के विपरीत सी का सुपरसेट नहीं है।
डैनियल नागी

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

0
var value : Int = 1

func theOldElegantWay() -> Int{
return value++
}

func theNewFashionWay() -> Int{
let temp = value
value += 1
return temp
}

यह निश्चित रूप से एक नकारात्मक पहलू है, है ना?


5
आप का अर्थ है "सी प्रोग्रामिंग भाषा की सभी बारीकियों को याद रखना होगा, अन्यथा यह तुरंत स्पष्ट नहीं है कि क्या पहला कॉल 1 या 2 रिटर्न करता है"? मुझे लगता है कि हम सभी कोड की कुछ अतिरिक्त पंक्तियों को कई मिनटों तक खर्च कर सकते हैं, कई मिनटों तक खर्च न करने के लिए हमारे सिर पर एक मूर्खतापूर्ण गलती के कारण बग ढूंढने की कोशिश कर रहा है ...
निकोलस मारी

0

चूंकि आप वास्तव में स्विफ्ट में पॉइंटर्स के साथ काम नहीं करते हैं, यह थोड़े मेरी राय में ++और --ऑपरेटरों को हटाने के लिए समझ में आता है । हालांकि अगर आप बिना नहीं रह सकते हैं, तो आप अपनी परियोजना में इन स्विफ्ट 5+ ऑपरेटर घोषणाओं को जोड़ सकते हैं :

@discardableResult
public prefix func ++<T: Numeric>(i: inout T) -> T {
    i += 1
    return i
}

@discardableResult
public postfix func ++<T: Numeric>(i: inout T) -> T {
    defer { i += 1 }
    return i
}

@discardableResult
public prefix func --<T: Numeric>(i: inout T) -> T {
    i -= 1
    return i
}

@discardableResult
public postfix func --<T: Numeric>(i: inout T) -> T {
    defer { i -= 1 }
    return i
}

-3

स्विफ्ट 4.1 में इसे इस तरह हासिल किया जा सकता है:



    prefix operator ++
    postfix operator ++
    extension Int{
        static prefix func ++(x: inout Int)->Int{
            x += 1
            return x
        }
        static postfix func ++(x: inout Int)->Int{
            x += 1
            return x-1
        }
    }
    //example:
    var t = 5
    var s = t++
    print("\(t) \(s)")


इस तथ्य के बावजूद कि इस पोस्ट में पिछले समाधानों के समान यह समाधान, वे स्विफ्ट 4.1 में अब काम नहीं करते हैं और यह उदाहरण करता है। यह भी ध्यान दें कि ऊपर दिए गए उल्लेख में कहा गया है कि + = ++ के लिए एक प्रतिस्थापन है बस ऑपरेटर को पूरी तरह से समझ में नहीं आता है क्योंकि ++ असाइनमेंट के साथ संयुक्त है वास्तव में दो ऑपरेशन हैं, इसलिए एक शॉर्टकट। मेरे उदाहरण में:var s = t++दो चीजें करता है: टी का मान असाइन करें एस और फिर वेतन वृद्धि टी। अगर ++ पहले आता है, तो यह उलटे क्रम में किए गए दो ऑपरेशन हैं। मेरी राय में, इस ऑपरेटर को हटाने के बारे में Apple का तर्क (पिछले उत्तरों में उल्लिखित), न केवल गलत तर्क है, बल्कि इसके अलावा, मेरा मानना ​​है कि यह एक झूठ है और सच्चा कारण यह है कि वे अपने संकलक को संभाल नहीं सकते हैं। इसने उन्हें पिछले संस्करणों में परेशानी दी तो उन्होंने हार मान ली। "ऑपरेटर को समझने के लिए बहुत जटिल, इसलिए हटा दिया गया" का तर्क स्पष्ट रूप से एक झूठ है क्योंकि स्विफ्ट में ऑपरेटर कहीं अधिक जटिल हैं और बहुत कम उपयोगी हैं जिन्हें हटाया नहीं गया था। इसके अलावा, प्रोग्रामिंग भाषाओं के अधिकांश हिस्से में यह है। जावास्क्रिप्ट, सी, सी #, जावा, सी ++ और इतने सारे। प्रोग्रामर खुशी-खुशी इसका इस्तेमाल करते हैं। जिसके लिए इस ऑपरेटर को समझना बहुत मुश्किल है,

स्विफ्ट के पीछे की रणनीति सरल है: एप्पल का मानना ​​है कि प्रोग्रामर गूंगा है और इसलिए उसी के अनुसार व्यवहार किया जाना चाहिए।

सच्चाई यह है कि सितंबर 2014 में लॉन्च हुई स्विफ्ट अब तक कहीं और होनी चाहिए थी। अन्य भाषाएं बहुत तेजी से बढ़ीं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.