“++” ve “-” operatörleri Xcode 7.3 kullanımdan kaldırıldı


139

Xcode 7.3 notlarına bakıyorum ve bu sorunu fark ettim.

++ ve - operatörleri kullanımdan kaldırıldı

Bazıları neden reddedildiğini açıklayabilir mi? Ve doğru Xcode yeni sürümünde artık yerine kullanacağız oyum ++bu x += 1;

Misal:

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

Uyarı için ekran görüntüsü


6
Bence bu soru, stackoverflow'un kapsamı dışında, hızlı evrim için kabul edilen tüm tekliflerin Github'da bulunabilmesi nedeniyle
Victor Sigler

7
Ciddi olarak sadece Objective-C'ye dönmeyi düşünüyorum. Swift'teki tüm değişikliklere ayak uydurmaya çalışmak değmez.
Greg Brown

3
@OlegGordiichuk C-stili de kaldırılacağı için döngüler için bir şey, bu github.com/Vkt0r/swift-evolution/blob/master/proposals/… 'a bakın, böylece daha fazla ++ve --operatör kullanmanıza gerek yok
Victor Sigler

10
Lezzetim için çok fazla kırılma değişikliği var. Ben tüm iyileştirmeler için değilim, ama gerçekten bir Xcode nokta sürümü her çıktığında benim kod tabanı önemli bölümlerini yeniden yazmak için zaman harcamak istemiyorum.
Greg Brown

4
@Fogmeister Nasıl daha net olabileceğimden emin değilim. Swift'i kullanmayı tercih ederim, ama yeterince kararlı olduğunu düşünmüyorum. Geçmişte diğer dillerle yoğun bir şekilde çalıştım ve bu kadar kısa bir sürede hiç bu kadar çok değişiklik yapmadım. Apple'ın hepimizin Swift'i benimsemesini istediğini hissediyorum, ancak olması gerekenden daha zor hale getiriyorlar.
Greg Brown

Yanıtlar:


210

Bir tamamını buradan açıklama Chris Lattner, Swift'in yaratıcısı. Puanları özetleyeceğim:

  1. Swift öğrenirken öğrenmeniz gereken başka bir işlev
  2. Şundan çok daha kısa değil: x += 1
  3. Swift C değil. Sadece C programcılarını memnun etmek için onları taşımamalısınız
  4. Ana kullanımı döngü için C tarzıdır: for i = 0; i < n; i++ { ... }Swift'in daha iyi alternatifleri vardır, for i in 0..<n { ... }(döngü için C tarzı da çıkıyor )
  5. Okumak ve bakımını yapmak zor olabilir, örneğin, x - ++xveya değeri ne foo(++x, x++)?
  6. Chris Lattner bunu sevmiyor.

İlgilenenler için (ve bağlantı çürümesinden kaçınmak için), Lattner'ın kendi sözleriyle nedenleri:

  1. Bu operatörler Swift'i ilk programlama dili olarak veya bu operatörleri farklı bir dilde bilmediğiniz başka bir durum olarak öğrenme yükünü artırır.

  2. Etkileyici avantajları minimumdur - x ++, x + = 1'den çok daha kısa değildir.

  3. Swift zaten =, + = ve diğer atama benzeri işlemlerin Void (bazı nedenlerle) döndürmesi nedeniyle C'den sapmıştır. Bu operatörler bu modelle tutarsız.

  4. Swift, diğer dillerde döngü için C-stilinde ++ i'yi kullanmanın yaygın nedenlerinin çoğunu ortadan kaldıran güçlü özelliklere sahiptir, bu nedenle bunlar iyi yazılmış Swift kodunda nispeten nadiren kullanılır. Bu özellikler, for-in döngüsü, aralıklar, numaralandırma, harita vb.

  5. Bu işleçlerin sonuç değerini kullanan kod genellikle kafa karıştırıcıdır ve bir kod okuyucusu / koruyucusudur. Onlar sevimli ama anlaşılması zor olabilir "aşırı zor" kod teşvik.

  6. Swift iyi tanımlanmış bir değerlendirme sırasına sahip olsa da, ona bağlı olan herhangi bir kod (foo (++ a, a ++ gibi) iyi tanımlanmış olsa bile istenmeyen bir durum olacaktır.

  7. Bu işleçler nispeten az sayıda türe uygulanabilir: tamsayı ve kayan nokta skalaları ve yineleyici benzeri kavramlar. Karmaşık sayılar, matrisler vb. İçin geçerli değildir.

Son olarak, bunlar "daha önceden sahip olmasaydık, onları Swift 3'e ekler miydik?"


54
Şey, gerçek cevap 6 numara. Tamam, biz (eski C, Java, ... programcılar) yeterince esnek :-). Genellikle, gerçek dünya için mutasyon, geçiş ve seçim yeterlidir. Ben, sen ve Cris de, hepimiz bu üç operatörün
sonucuyuz

5
Nokta 5: Bunlar her zaman C'de uygulamaya bağımlıydı ve hiç kimse hiç bir anlam ifade etmedi. Davranışı tanımlamanız yeterlidir. Gerçek bir sebep olmadan geri dönmek ve mükemmel eski kod değiştirmek zorunda daha iyi.
Echelon

3
3. noktayı seviyorum. Miras sözleşmesine sonsuza kadar zincirlenemezsiniz. C'yi seviyorum ama yeni bir programlama dili oluşturuyorsunuz; slate ile ihtiyacınız olduğu kadar temiz başlamak mantıklı.
Nicolas Miari

8
Çünkü elma sizi onlar gibi düşünmeye zorluyor. Bence gayet iyi ve bir değişkeni arttırmak veya azaltmak için ihtiyacınız olan her yerde kullanılıyor. Bu, onsuz iyi yapacağınız "öğrenmek zorunda olduğunuz" bir şey değil. Ve # 5, beğenilerini hiç görmediğim sadece kötü yazılmış bir kod. Yani # 6. Kafamı çizmemi ve bir google araması yapmam yeterli, bu yüzden zamanımı boşa harcadığın için teşekkürler Chris.
csga5000

4
@ csga5000 Gerçekten isterseniz operatörü kendiniz tanımlayabileceğiniz göz önüne alındığında bu oldukça zayıf bir argüman. Elma ile insanların onlar gibi düşünmesini isteyen bir şey yoktur. Sadece dile uymuyor. Eğer ++C tarzı dillerinde olmasaydı, aklı başında hiç kimse Swift 3.0 tasarımında bakıp bir düşünürdüm ++operatör kendisine güzel bir katkı olacaktır.
overactor

37

Bununla birlikte, bu yorumun soruyu cevaplamadığını fark ettim, ancak bu operatörlerin nasıl çalışmasını sağlayacak bir çözüm arayan insanlar olabilir ve böyle bir çözüm en altta bulunabilir. 😇

Ben şahsen ++ve --operatörleri tercih ederim . Zor veya yönetilmesi zor olduğu fikrine katılıyorum. Geliştirici, bu operatörlerin ne yaptığını anladıktan sonra (ve oldukça basit şeyler hakkında konuşuyoruz) kodun çok açık olması gerekir.

Operatörlerin neden kullanımdan kaldırıldığına ilişkin açıklamada, ana kullanımlarının döngüler için C stili olduğu belirtiliyor. Diğerleri hakkında bilmiyorum ama ben şahsen hiç C tarzı döngüler kullanmayın ve zaman hala pek çok başka yerlerde veya durumlar vardır ++ya --operatör yararlıdır.

Ayrıca, varName++bir değer döndürür, böylece returnvarken kullanılabilir varName += 1olamaz bahsetmek istiyorum.

Bu operatörleri burada çalışmaya devam etmek isteyen herkes için çözüm:

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)Postfix operatörleri için hoşlanmıyorum - IMHO, aldığınızdan ziyade orijinal değerin döndürdüğü semantikleri korumak için daha temizx + 1 - 1
Alnitak

Ben de sevmiyorum ama bunu yapmak için başka (daha iyi, temiz) bir yol hakkında bilmiyorum. İkinci noktanı tam olarak anlamıyorum.
0101

1
Görüyorum ki, sadece başka bir değişken (ya da bu durumda sabit) oluşturmak için bunu yapmak istemedim. Eğer Intsadece bahsediyorsak , (x + 1)yürütme işlemini kesintiye uğratacak ve bu nedenle result - 1bile çalıştırılmayacak olan sonuç taşacak . DoubleÖrneğin, gibi diğer veri türleri farklı davranır, bu yüzden bunu araştırmak gerekir.
0101

3
Bunun için de kullanabilirsiniz defer. defer { x += 1 }; return x
Tim Vermeulen

4
neden jenerik ilaç kullanmıyorsunuz ve bunu birkaç satırda yazmıyorsunuz?
μολὼν.λαβέ

22

Apple, bir ++başka eski geleneksel yolla kaldırıldı ve çok daha basit hale getirdi.

Bunun yerine ++yazmanız gerekiyor +=.

Misal:

var x = 1

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

Benzer şekilde azaltma operatörü --için yazmanız gerekir-=

Misal:

var x = 1

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

For fordöngüleri:

Artış Örneği:

Onun yerine

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

Yazabilirsin:

//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)")
}

Azaltma Örneği:

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

Yazabilirsin:

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)
}

Bu yardımcı olur umarım!


Hiçbir şeyin yerini almamışlar; +=başından beri oradaydı.
Nicolas Miari

@NicolasMiari Evet, çok daha iyi formatla düzenleme
Sohil R. Memon

@NicolasMiari Şimdi kontrol edebilir misiniz?
Sohil R.Memon

3
Ne hakkında ++ive --i?
Zigii Wong

7

Chris Lattner ++ ve - ile savaşa girdi. “Bu operatörlerin sonuç değerini gerçekten kullanan kod çoğu zaman kafa karıştırıcı ve kod okuyucusuna / bakıcısına sadık. Sevimli ama anlaşılması zor olan “aşırı zor” kodu teşvik ediyorlar… Swift iyi tanımlanmış bir değerlendirme sırasına sahip olsa da, ona bağlı olan herhangi bir kod (foo (++ a, a ++) gibi) istenmeyen olsa bile istenmeyen iyi tanımlanmıştı ... bunlar, "eğer bunlara sahip olmasaydık, onları Swift 3'e ekler miydik?"

Apple hızlı, temiz, anlaşılır, kafa karıştırıcı ve doğrudan bir dil tutmak istiyordu. Ve böylece ++ ve - anahtar kelimelerini kullanımdan kaldırdılar.


9
Temiz? Bu geri arama cehennemine bak ve temiz mi diyorsun? Katılmıyorum ... Ve ekleyeceğim: ++ ve - yalnız bırak
mcatach

22
gibi bir şey ...for i in 0.stride(to: 10, by: 2)...veya ...for i in (1...10).reverse()...temiz mi ?!
mad_manny

6
Katılıyorum. 'Temiz' argüman Swift'in geri kalanıyla temelde çelişkilidir. Nesnel olarak kirli olan Objective-C'den gelince, 'temiz' bir Apple dili hedefi olarak kabul etmek oldukça zordur.
Adrian Bartholomew

2
Json'u ayrıştırmayı deneyin ve çabuk olun ve bana ne kadar temiz olduğunu söyleyin.
nickthedude

6

Uyarı için ekran görüntüsü

Fix-it featureXcode Buna net bir yanıt verir.

Uyarı çözümü

Değiştir ++ increment operatoreski moda ile value += 1(kısa taraftaki operatörü) ve -- decrement operatorilevalue -= 1


6

Swift 4 için ++ve ve --işleçlerini uzantılar Intve diğer türler olarak geri yükleyebilirsiniz . İşte bir örnek:

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
    }
}

Bu gibi diğer türleri için aynı şekilde çalışır UIInt, Int8, Float, Double, vb

Bu uzantıları kök dizininizdeki tek bir dosyaya yapıştırabilirsiniz; buradaki diğer tüm dosyalarınızda kullanılabilir.

Buraya cevabım için bir kaç aşağı oy fark ettim, neredeyse en kısa sürede. Kuralların nasıl işlediğine dair eleştiriden ziyade felsefi bir anlaşmazlık olarak kabul ediyorum. Bir oyun alanında kontrol ederseniz mükemmel çalışır.

Bu yanıtı yayınlamamın nedeni, bilgisayar programlama dillerini gereksiz yere birbirinden farklı kılmama katılmam.

Diller arasında birçok benzerlik olması, insanların öğrenmesini ve bir dilden diğerine geçmesini kolaylaştırır.

Geliştiriciler normalde yalnızca bir dil yerine birkaç programlama dili kullanırlar. Ve sözleşmeler ve diller arasında ortak bir standardizasyon olmadığında, bir dilden diğerine geçmek gerçekten güçtür.

Diller arasında sözdizimi farklılıkları olması gerektiğine inanıyorum, bundan daha fazla değil.


Diller farklı olmaya cesaret edince seviyorum. Dürüst olmak gerekirse çok fazla 'C-sözdizimi' dil var ve C UZUN bir zaman önce tasarlandı .. 50 yıldan fazla bir dil deneyimi oldu ... ne olursa olsun, bu cevap operatörler üzerinde bir tirade girmediği için, yine de bir oylama.
user2864740

5

İşte şimdiye kadar yayınlanan bazı kodların genel bir versiyonu. Ben diğerleri gibi aynı endişeleri dile olacaktır: o kadar iyi bir uygulamadır değil bu Swift kullanmak. İleride kodunuzu okuyanlar için bunun kafa karıştırıcı olabileceğini kabul ediyorum.

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
}

Bu, Sayısal tipte bir uzantı olarak da yazılabilir.


@discardableResultKullanılmayan dönüş değeri hakkındaki uyarıyı susturmak için bu işlevlerin her birine ekledim ; aksi takdirde tam olarak aradığım şey.
Devin Lane

4

Gönderen docs :

Swift'teki artış / azaltma operatörleri, Swift'in geliştirilmesinde C'nin bir aktarımı olarak çok erken eklendi. Bunlar fazla düşünülmeden eklendi ve o zamandan beri çok fazla düşünülmedi. Bu belge onlara yeni bir bakış sağlar ve nihayetinde kafa karıştırıcı oldukları ve ağırlıklarını taşımadığı için bunları tamamen kaldırmamızı önerir.


Başka bir deyişle, bu işlem kullanılamayacak kadar pahalı mı?
Oleg Gordiichuk

2
github.com/apple/swift-evolution/blob/master/proposals/… burada okuyabilirsiniz, ancak bunun nedeni pahalı değil, dil tasarımı.
Dániel Nagy

Ben andersen Swift C-tarzı özelliklerin desteğini düşürecek gibi
Oleg Gordiichuk

2
@OlegGordiichuk iyi, Swift'in Objective-C'nin aksine C'nin bir üst kümesi olmadığını vurgulamak istediklerini söyleyebilirim.
Dániel Nagy

1
@mah söylediklerinin çoğu hiç mantıklı değil. "Mevcut geliştiricilere yönelik değil" ne şekilde? Java'nın PHP geliştiricilerine yönelik olmadığı gibi? "geliştirici olmaya eğilimi olmayanlara yönelik"? Evet, çünkü tüm bu geliştiriciler, protokole yönelik programlama ve jenerikler ile el ele. "İyi tasarımı etkinleştirmenin bir yolu" sadece SO'ya bir göz atın, hiçbir programlama dilinin "iyi tasarımı etkinleştiremeyeceğini" göreceksiniz.
Fogmeister

0
var value : Int = 1

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

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

Bu kesinlikle bir dezavantaj, değil mi?


5
"C programlama dilinin tüm inceliklerini hatırlamanız gerekiyor, aksi takdirde ilk çağrının 1 veya 2 döndürdüğü hemen anlaşılamıyor" mu? Aptalca bir hata nedeniyle bir hata nedeni bulmaya çalışan kafalarımızı kaşıyarak birkaç dakika geçirmemek karşılığında hepimiz birkaç ekstra kod satırı
yedekleyebiliriz

0

Swift'teki işaretçilerle hiçbir zaman gerçekten çalışmadığınız için , bence ++ve --operatörleri kaldırmak mantıklı . Ancak onsuz yaşayamazsanız , projenize şu Swift 5+ operatör bildirimlerini ekleyebilirsiniz :

@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

Swift 4.1'de şu şekilde elde edilebilir:



    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)")


Bu çözümün bu yazıda önceki çözümlere benzer olmasına rağmen, Swift 4.1'de artık çalışmadığına ve bu örneğin işe yaramadığına dikkat edin. Ayrıca, yukarıdaki her kimin + = ++ yerine geçebileceğinden bahsettiğinde operatörün tam olarak anlamadığını anlayın. Örneğimde:var s = t++iki şey yapar: t değerini s'ye atayın ve sonra t'yi artırın. ++ daha önce gelirse, ters sırayla yapılan iki işlemle aynıdır. Benim düşünceme göre, Apple'ın bu operatörü (önceki cevaplarda belirtildiği gibi) neden kaldırdığına dair akıl yürütmesi sadece yanlış bir akıl yürütme değil, aynı zamanda bir yalan olduğuna inanıyorum ve asıl sebep derleyicilerinin bununla başa çıkamamasıdır. Onlara önceki versiyonlarında sıkıntılar verdi, bu yüzden vazgeçtiler. "Operatörü anlamak için çok karmaşık, dolayısıyla kaldırıldı" mantığı açık bir şekilde yalan. Ayrıca, programlama dillerinin büyük çoğunluğu buna sahiptir. JavaScript, C, C #, Java, C ++ ve daha fazlası. Programcılar bunu mutlu bir şekilde kullanıyor. Bu operatörü anlamak kim için çok zorsa,

Swift'in arkasındaki strateji basit: Apple, programcının aptal olduğuna ve bu nedenle buna göre tedavi edilmesi gerektiğine inanıyor.

Gerçek şu ki, Eylül 2014'te başlatılan Swift'in şu an başka bir yerde olması gerekiyordu. Diğer diller çok daha hızlı büyüdü.

Dilde birçok önemli hatayı, ciddi olanlardan listeleyebilirim: referansla değil, değere yapıştırılan diziler gibi can sıkıcı olanlara: varyasyon parametreleri işlevleri, arkasındaki tüm fikir olan bir diziyi kabul edemez. Apple çalışanlarının Java gibi diğer dillere bakmalarına bile izin verilmediğini düşünmüyorum, böylece Apple'ın ışık yıllarının geride olduğunu bile bilmiyorlar. Apple Java'yı bir dil olarak benimseyebilirdi, ancak bugünlerde meydan okuma teknoloji değil, ego. Bazı Java yazmak için IntelliJ'i açarlarsa, bu noktada iş anlayışlarını kesinlikle kapatacaklardı, bu noktada hiç yakalayamayacaklar ve olmayacaklar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.