Implicit nil compare

Evolution Discussion
1

It was so nice to use nil check in Object like:

‘object ? title : “isEmpty” ‘

‘if object {‘

Instead of ‘if _ = object {‘

What about to return it to Swift?

2

Swift is about as sugared as it can be here. if let value was added a few years ago.

5 Likes
3

How should we define the behaviour for Bool? in this case?

let optionalBool = false as Bool?
if optionalBool {   // should we execute this block or not?
    // do something 
}
3 Likes
4

You could do:

let title = object?.title ?? "isEmpty"
1 Like
5

Is this what you wanted to use?[1]

if let optionalBool, optionalBool {
    // do something
}

Or if optionalBool is not used as a Boolean in the body then

if 
    optionalBool ?? false,
    optionalBool == true
{
    // do something
}

The code provided would only make sense like this as

let assumedBool: Bool! = false // Compiler treats as `Bool` with an invalid `nil` state
if assumedBool {
    // do something
}

This would be hazardous though as if assumedBool wasn’t a real Bool then you crash.

  1. this is valid by having optionalBool not need any further unwrapping as it is using optionalBool via the Bool definition rather the Bool? definition ↩︎

6

Indeed that’s what we need to do in current Swift design. What I mean is that we need to think about what the compiler should response to such codes if “implicit nil compare“ is adopted. Should it give an error? a warning? or allow it?

7

Currently if you did this

let assumedBool: Bool! = nil
if assumedBool { // Crash
    // do something
}

When the code is executed, the compiler would error out as it is your responsibility to accurately deal with force unwrapping, the compiler cannot help you if you use this as this acts like the rust unsafe block where it is uncheckable and as such should be used sparingly.

8

I’m not discussing about using Bool! here. I mean in current swift, the following codes does not compile

let optionalBool = false as Bool?
if optionalBool { 
    // do something 
}

However, if the “implicit nil compare“ proposed in this post is adopted, this code can potentially become valid. And we need to consider how the compiler should deal with it.

9

I don't think any of the original examples were complete enough to start a meaningful conversation. While everything that everyone has said has been valuable, I'm not sure that any of it addresses what in the original post.

That said, I see this a lot, and hate it:

Please use the following instead.

if optionalBool == true  {
5 Likes
10

‘Bool?’ currently is the abridged form of ‘Optional’ which would make changes like this a severe breaking change. ‘Bool!’ on the other hand acts as the only way I am aware of to declare a implicitly unwrapped ‘Optional’ type[1]. This would mean that we would be making the compiler have to guess about how the type should be unwrapped causing significantly more bugs or confusion on the developer side and could be hazardous for code usage.

  1. Technically these types have been gone since 2018 in Swift 4.1 ↩︎

11

Should never be executed:

if nil == false

if false == false