Here is a simple interface for a class with a single property, an initializer and an instance method:. Notice how the references from the Objective-C code appear as implicitly unwrapped optionals in the Swift code.
It is common in Objective-C to return nil for an object reference where in Swift you would use an optional type. Unfortunately there is nothing in the Objective-C code that tells the compiler which references can be nil so it assumes the worst and makes everything an implicitly unwrapped optional.
Consider first the name property in our class. This is a readonly string that we want to initialise when we create the object so it should not be nil.
I'm trying to load some. Solutions from similar questions didn't really help What am i doing wrong? Improve this question. Add a comment. Active Oldest Votes. Improve this answer. Thank Zaph. You saved my remaining day. I had the same issue, but files have already been added to Copy Bundle Resources stage, so that was not the issue. What I had to do however weird this is, and points probably to an error in my current Xcode IDE was moving these respective files from a project Group Folder to the root of project Xcode 5.
OMG took me twenty minutes to figure out where to click. Wish I could add an screenshot for you. Email it to me and I will add it. Show 1 more comment. What if your Objective-C framework has existing code written against it? Is it safe to just change your types like this? Yes, it is. In general, you should look at nullable and nonnull roughly the way you currently use assertions or exceptions: violating the contract is a programmer error. In particular, return values are something you control, so you should never return nil for a non-nullable return type unless it is for backwards-compatibility.
Therefore, an array of optionals does not really have true nullability either, but we can say you have indirect access to nullability. Nullability and dictionaries have been a point of pain for old projects for many years. In case you are following along, this is the code that loads that file dolls. But which is which? In short, in Objective-C, when a dictionary does not have a given key, it will point to nil. When the dictionary does have the key, but said key is null, it will be NSNull. It makes complete sense if you think about it.
Earlier we said NSNull is a placeholder for actual nothingness, and if you want a dictionary that can have nothingness, you need to use a placeholder for nothingness.
This has been the source of many weird crashes for the following reason: In Objective-C, you can send messages to nil , but when you are sending messages to a real object, the object needs to implement the method you want to call - in other words, you want the object to respond to a selector. To clarify the following point, we will try to print the contents of the Nendoroid key, and the dolls in the HarmoniaBloom key, using for in.
Behind the scenes, for-in will call the countByEnumeratingWithState:objects:count: method in arrays. The key does not exist in the dictionary at all:. On the other hand, trying to print the contents of the HarmoniaBloom array will have unexpected consequences:.
On the other hand, when we access an existing key whose value is NSNull , the program will crash, because NSNull is an object like any other, and it expects to receive selector calls that it can respond to. Failing to do so will cause your program to crash.
0コメント