[_qulr]

> I said backwards compatibility

This phrase isn't entirely clear.

> Objective-C is a superset of C

This phrase is clearer.

In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.

[_qulr]

I would also say that Swift by design is very much constrained, you might say held back, by the needs of Cocoa compatibility. For example, Swift takes features that are mere conventions in Objective-C, such as initializer patterns (which can be ignored when they're inconvenient), and makes them into built-in language requirements. This becomes very awkward at times.

Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.

[ratww]

Optionals doesn't exist because of ObjC compatibility. They are a hallmark feature in functional languages like Haskell and Scala, and in other modern languages like Rust and Kotlin. Even C++17 introduced std::optional.

And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs.

And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.

[_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.

[dwaite]

> Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.

Conceptually, the ability to represent the lack of a value is quite a common requirement. Swift has specific language syntax and compiler data structuring around the Optional type, but it is just a swift enumeration with an associated value at its core.

IUO (implicitly unwrapped optional) is mostly a compatibility feature however, for languages which were designed around the idea of nullable pointers like objc and C. UIKit and AppKit, for example, assume views have properties which can be nil before the view loads and non-nil afterward. IUO allows you to rely on this convention rather than have to safe or force-unwrap every property for use.

[chrisbrandow]

Every object in Objc is already optional. Swift merely formalizes it so that it's easy to reason about.