R.swift: Optional view controllers in Storyboards

Created on 1 Jul 2016 · 4Comments · Source: mac-cain13/R.swift

When I'm trying to instantiate a view controller from storyboard it returns an optional value. Why don't you use force unwrapped values in R.generated (because you know for sure the type of view controller)?

Source

serejahh

Most helpful comment

I just came here 3 years after the question has been asked. @tomlokhorst thanks for a great explanation. Still very helpful!
What do you think about adding a parameter/flag for making the view controllers in R.generated force unwrapped? This could be useful for users that follow the installation process described in Readme and are sure the generated file and the storyboards do match.

darecki on 30 Apr 2019

👍2

All 4 comments

A design goal of R.swift is to never have the generated code crash at runtime.

People have asked about force unwrapping before, mostly in the context of images. For images there are legitimate reasons why the constructor might return nil. In particular for on-demand resources or watchOS-only resources on iOS.

Although these reasons for nil do not apply to view controllers, there is at least one way for this method to return nil at runtime; If the R.generated.swift file was generated at the different time as the storyboard used in the app.

For my personal projects, I've setup R.swift as a custom build step in Xcode (as described in the readme). So when I'm using R.swift, I'm sure the generated file and the storyboards used do match. Therefor I'm fine with force unwrapping in my own app: R.storyboard.planner.plannerNavigationController()!

However R.swift can't assume _all_ users will use a similar setup. If, for some reason, the generated code doesn't match the runtime environment, a force unwrap would crash. If it needs to crash, we'd much rather have the force unwrap be in the code written by the user, instead of in generated code (and getting the tool be blamed for the crash).