[_qulr]

> For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had.

That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there.

Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.

[Jtsummers]

I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).

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

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