In Xcode’s Swift compiler, types may define failable init() methods—i.e., ones which may return nil if something fails. This may be done like so:
class Something {
init?() {
// Do some checks, return nil if we fail
}
}
This compiles just fine in Xcode, and works as expected. If for some reason we can’t create the object—whether by some quirk of resource access or some other runtime condition—we simply return nil, which would pass a nil object to the caller, of the receiver’s type.
let thing = Something()
Our thing could be nil as easily as an instance of the Something class. This works for structs, classes, even protocols, and works just fine.
In Fire, and presumably with the Silver flavor of Swift, an attempt to define one of these handy things compiles just fine. However, if one calls return nil in their init?() function, the compiler balks, spitting out something like, “Method has no result”
Without this line, we compile just fine, but we lose the useful functionality that init?() was designed to provide. And as self here his non-nullable, we can’t simply call self = nil either…
But the constructor compiles just fine on its own, like any good constructor for a class that does nothing.
I thought that, maybe, it had something to do with some fancy implied return of nil when not all properties are successfully initialized, but something entirely unexpected happened:
This shouldn’t compile. We never initialize value, yet we try to read from it… in our constructor. Xcode would throw a fit! I thought, “Maybe it’s a constructor thing!” I that. Same problem.
This is starting to look like another bug entirely. Moving on…
Anyway, my point here is that init?() doesn’t work as expected. And the compiler doesn’t check that variables get initialized.
I’m using version 8.3.93.197 (master). As nothing happened when I clicked “Check for Updates,” I assume this is the latest version. If I am in error in any way here, please do tell me, and I hope to find a reasonable solution to this very soon.
Thanks for the help!
