Fero
Fero

Reputation: 676

What's the difference between testing an optional for "nil" and ".None"?

I see everywhere in swift language, people testing for optional values with if statements so they can safely force unwrap, in 2 ways:

if optionalValue != .None {   

... some code ...

}

or

if optionalValue != nil {   

... some code ...

}

What's the difference and can it somehow influence my app/code in any way? What's better?

Upvotes: 4

Views: 5281

Answers (3)

Ashutosh Mishra
Ashutosh Mishra

Reputation: 1939

There is no difference, as .none (basically it's Optional.none) and nil are equivalent to each other.

In fact, this statement run in playground then it's outputs is true:

nil == .none || print(nil == .none) -> true

The use of nil is more common and is the recommended convention.

Upvotes: 1

Antonio
Antonio

Reputation: 72790

In normal usage there's no difference, they are interchangeable. .None is an enum representation of the nil (absence of) value implemented by the Optional<T> enum.

The equivalence of .None and nil is thanks to the Optional<T> type implementing the NilLiteralConvertible protocol, and an overload of the != and == operators.

You can implement that protocol in your own classes/structs/enums if you want nil to be assignable, such as:

struct MyStruct : NilLiteralConvertible {
    static func convertFromNilLiteral() -> MyStruct {
        return MyStruct() // <== here you should provide your own implementation
    }
}

var t: MyStruct = nil

(note that the variable is not declared as optional)

Upvotes: 8

Mundi
Mundi

Reputation: 80271

The answer is readily available if you command-click on the word .None. Here is what the Swift package reveals:

enum Optional<T> : Reflectable, NilLiteralConvertible {
    case None
    case Some(T)
    init()
    init(_ some: T)

    /// Haskell's fmap, which was mis-named
    func map<U>(f: (T) -> U) -> U?
    func getMirror() -> MirrorType
    static func convertFromNilLiteral() -> T?
}

So in most cases you can use either because optional values should conform to the protocol NilLiteralConvertible (although I am not sure about this last point).

Upvotes: 3

Related Questions