[_qulr]

> Optionals doesn't exist because of ObjC compatibility.

The problem is that every Objective-C type is essentially an optional, so any Swift code using Cocoa frameworks, based on Objective-C, is a deluge of optionals. Your entire code base is constantly dealing with them. It's a mess.

> I didn't understand the part about the initializer pattern... are you talking about constructor overloading?

I'm talking about this: https://docs.swift.org/swift-book/LanguageGuide/Initializati...

[ratww]

I'm pretty familiar with the Objective-C internals, and Swift optionals are not there because of Objective-C, as there are multiple ways of having compatibility between the two languages (but none as safe as having Optionals).

Like I said, Optionals are an extremely popular feature in most modern languages, and Swift would be very criticized if it had not included it.

> I'm talking about this: https://docs.swift.org/swift-book/LanguageGuide/Initializati...

Ok, you are talking about constructor overloading, which is a pretty common and uncontroversial feature present in pretty much every OOP language made in the last 30-40 years.

[_qulr]

> Ok, you are talking about constructor overloading

No, I'm not. I'm talking about, for example, "Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created." Which is not the case in Objective-C.

Also the concept of a "designated initializer", which is again simply a convention in ObjC.

EDIT: To be clear, I'm not trying to make statements about the history of programming languages, or about general programming concepts. I'm trying to say that the very specific way that Swift implements general programming concepts (which may vary greatly in different languages) was obviously inspired and constrained by backward compatibility with Cocoa and Objective-C. If you were to design a new programming language from scratch, without those backward compatibility requirements, you most likely wouldn't implement things exactly the way Swift does. It would be strange if you did. Swift is very much constrained by backward compatibility, and very much non-ideal as a result.

If you read that entire long initializer document from top to bottom, it's clear that this is all specifically based on Objective-C patterns — as it needs to be for Cocoa compatibility — regardless of whether there are historical antecedents of the general concept.

[ratww]

Sorry but let's maybe agree to disagree? You seem to be pointing to Swift features that are very different from ObjC (as you said yourself), but are very close to other similar multi-paradigm languages. You asked "Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility" and I'm answering that other languages have it. It's not that Swift turned ObjC conventions into requirements: it's that in ObjC they were mere conventions, in almost every other new language similar to Swift they are already requirements.

Sure, Swift has ObjC baggage, but those two specific features would be present in any multiparadigm language launched in the same period. Check out Scala, Kotlin and even C#, for example, and you'll see lots of similarities. Swift is going exacly where other languages are converging to.

In fact, the inspiration for the ad-hoc initializer pattern in ObjC you're mentioning probably came from other contemporary languages... maybe C++ or Smalltalk. Optionals in Swift have nothing to do with ObjC: in Swift they come from functional programming tradition, nullability in ObjC is a virtue of being a superset of C. The fact they work together is a virtue of compatibility, but those two Swift features were not specifically designed to serve ObjC.

[saagarjha]

I think the truth is somewhere in the middle–Swift was not created in a vacuum, of course, but it does have to take Objective-C into account and thus we have the concepts of designated and convenience initializers, or implicitly unwrapped optionals. However, if you look at them more closely it's pretty clear they exist to bridge Objective-C to Swift concepts–fully initialize your objects before you use them, or annotate your code for nullability, which is where Swift wants you do go.