[ratww]

No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility.

Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns.

This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.

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

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