[jchb]

The idea of an option type (Optional in Swift) is to use it only for a variables truly assume a "none" value at some point. With the guarantees of such a type it is easier to reason about the correctness of a program - compared to Objective-C where a pointer anywhere may be null at any time. Optional shouldn't be used for most variables and parameters. `guard let param = param else { return }` should be something pretty rare. I would mostly expect to see that for weak self variables in completion blocks.

Also, take into account that in Objective-C you can send any message to a nil pointer, and the result will be nil or 0 (for scalar types), as defined by the language standard.

[gurkendoktor]

> Optional shouldn't be used for most variables and parameters.

I'd agree if Swift was a general-purpose C++ replacement, but most developers use Swift to write Cocoa apps. viewController.navigationController is optional, view.superview is optional, label.text is optional; all of Apple's frameworks are built on mutable state where almost everything can be or become nil.

(We can make sure that most variables and parameters aren't optional, but that only pushes the problem to other lines of code.)

If we know that we've loaded a view controller from a storyboard, is `self.storyboard!.foo` really a code smell? What else should we do? The type system doesn't let us express what we know/assume about the situation, unless we completely sidestep Apple's controller infrastructure and write our own thing.

> Also, take into account that in Objective-C you can send any message to a nil pointer, and the result will be nil or 0 (for scalar types), as defined by the language standard.

Right, I am not saying that Objective-C handled this any better. But it boggles my mind that we have Swift's complicated type system now, and use it to rebuild an implicit source of errors from Objective-C.

[jchb]

Replying to your specific examples, I would say `storyboard!.foo` and `viewController.navigationController!` (when you know the view controller is in a navigation controller) is the correct thing to do. And if your assumptions are false that is going cause a trap at runtime, and you will get your crash report.

All the existing Apple frameworks where originally designed for Objective-C, and if redesigned with Swifts type system they could have a much safer API. But what are you suggesting Apple should do? Throwing thousands of man years of their own and third party developers code away, and ask everyone to start from a clean state? I prefer the current approach where, while the Swift language and tooling is maturing, Swift acts as an incremental improvement over Objective-C.

I should also add that if you avoid putting too much of your code in your views (networking, data storage ...) then you can put those components in embedded frameworks that can have a nice safe Swift API.

[gurkendoktor]

> But what are you suggesting Apple should do?

Apple could have spent less time on their new programming language if they hadn't insisted on reverting every single design decision in Objective-C: the way mutability and constness are handled, NSObject as a root class, naming conventions, the string class, creating their own package manager, etc. There's so much pointless bridging going on.

That would have given Apple plenty of resources to iterate on their current UI frameworks. If the IB/storyboard infrastructure leads to nil-heavy and stringly-typed code, why not push a first-party UI DSL? Why do we even need a third-party platform like Crashlytics to debug errors? Why is it so hard to write UI tests and have them run on a CI? Has IB_DESIGNABLE started working reliably at some point? Why is basic stuff like this not a blocker? [1]

And yes, at some point I think UIKit and AppKit should be scrapped in favor of a new framework (with a slow migration path, not a clean cut). I was hoping for UXKit to be just that, but instead we got the monstrosity that is Marzipan. Apple's focus is on the language, when it should be on the frameworks.

[1] https://bugs.swift.org/plugins/servlet/mobile#issue/SR-6795

[dwaite]

>Apple could have spent less time on their new programming language if they hadn't insisted on reverting every single design decision in Objective-C: the way mutability and constness are handled, NSObject as a root class, naming conventions, the string class, creating their own package manager, etc. There's so much pointless bridging going on.

But every one of these is arguably a good decision. Swift.String has a significantly better interface. immutable types are a huge win. It doesn't make sense to have a root class when you have non-class value types. You have to change the naming conventions if you change the calling syntax, which was a swift goal.

You also can't take LLVM gurus working on a new language and re-task them to take on UI framework feature adds without a lot of friction.

(BTW, my understanding was that NSObject isn't the only root)

[apple4ever]

I disagree. I think all their decisions were bad, which makes Swift a bad language. They focused on the wrong thing.

[dep_b]

I did notice that a lot of Objective-C's uncertainties were paved over when the years passed. Most libraries feel a lot more Swift-y but there are some problems and it's a pity that Storyboards are one of them. I hope they'll revise the system some day.

[wool_gather]

The point stands, however, that just because developers are forced to handle the `nil` somehow, doesn't mean they're handling it in a sensible way that makes for consistent UX. Crashing sucks from a user perspective, obviously data corruption is even worse, but just throwing up your hands and returning early from a view controller method doesn't really do anything for the user either.

I generally find it useful to have the concept of Optional, making me think about "could this thing be missing?" explicitly. But I've started to wonder if it is, rather than "preventing an entire class of bugs", actually just making them pop up elsewhere when Optional values start brushing up against that top level of user-visible stuff.

Maybe we (I) just need to get better at thinking about missing data conditions at the product design stage, or more robust defaults.

[jchb]

> when Optional values start brushing up against that top level of user-visible stuff

Perhaps you are under-using sum types - or enums with associated values as they are called in Swift. Difficult to get into details in this format, but for example, instead of:

`enum State { case connected(Connection, SomeOtherStateRelatedToConnected) case disconnected }

let state: State `

You have: ` var connection: Connection? var someOtherState: SomeOtherStateRelatedToConnected? `

[lewisj489]

j