But it is an uninitialized optional

[michelf (Michel Fortin)]

@ibex10

But then if you encounter this:

let u: Int?

if u == 7 {
   ...
}
else {
   ...
}

you would naturally say: hang on a minute, there is something special about the == operator here because the first operand, an optional variable, is not being unwrapped, and the code still compiles.

What's special here is not the operator ==. What's special is the language rule that values are implicitly wrapped in an optional when passed to a function (or an operator) taking an optional parameter.

Here what happens is this:

u == 7

gets promoted to this:

u == Optional(7)

And now you're comparing two Int?. There is no implicit unwrapping of u but instead 7 is implicitly wrapped because == requires two similar types and == is implemented for two optional values of the same type.

The difference with operator < is that it isn't implemented for Optional where Wrapped: Comparable unlike == which is implemented for Optional where Wrapped: Equatable. So no implicit wrapping can allow the operator to be called.

---

By the way, this implicit wrapping in optional is why you can write:

let u: Int? = 7

instead of having to write the more verbose:

let u: Int? = Optional(7)

[ibex10]

@michelf: I got it now. Thank you!

PS: I wish this were in the TSPL Book.

[tera]

@michelf

What's special here is not the operator ==.
....
The difference with operator < is that it isn't implemented for Optional where Wrapped: Comparable unlike == which is implemented for Optional where Wrapped: Equatable.

Which is exactly what makes operator == special: compared to other operators that are left unimplemented == (and its != counterpart) is the one that is implemented. Am I missing something?

[michelf (Michel Fortin)]

I suppose you could say Optional conforming to Equatable when the wrapped value is Equatable is something special. It's actually pretty common however: most collections have such a conformance for instance.

The original question asked why you don't need to unwrap first before calling ==, then proceeded to use other operators like < as an example of something working as expected (requiring to unwrap first). And the reason is because of something unique to optionals granted by the language: implicit wrapping of non-optional values. I see that as a special rule for Optional in the language, whereas the presence of (or not) of some operators is more a normal API usage/design question.

[Slava_Pestov]

@Jumhyn

While we can debate what counts as “serious”, in Swift codebases I’ve worked in I fairly routinely find (and write!) bugs due to the implicit initialization of optionals defeating the usual DI guarantees we get for non-optional properties. It’s just way too easy to write an init which never initializes some property, especially as a codebase evolves and a type has more and more properties added to it.

Feel free to revive the pitch

[tera]

@xwu

A semantically sound implementation of the comparison operators was removed from Swift 3 in SE-0121. See that discussion for detailed rationale.

That discussion happened > 7 years ago, many things changes since then. Now we have mature generics and it it would be possible making a conditional conformance to Comparable. From the pitch:

However, this doesn't work in current versions of Swift, because generics don't support conditional conformances like extension Optional: Comparable where Wrapped: Comparable, so Optional is not actually Comparable.
...
Until generics are more mature, the issue of Optional being conditionally Comparable can't be fully discussed/implemented, so it makes the most sense to remove these questionably-useful operators for now (a breaking change for Swift 3), and add them back in the future if desired.

Good time to have this discussion or everyone is happy with the current status quo?

[sspringer (Stefan Springer)]

@tera

Good time to have this discussion or everyone is happy with the current status quo?

Just before the text you cited:

…what remains is to decide whether these semantics (that nil is "less than" any non-nil value) are actually useful and worth keeping.

I could not find a single use case in the proposal (which is about the removal of comparisons with optionals) which would show the usefulness of such comparisons (e.g. better use a compact map).

I think this would be a case of „too much magic“. Unless someone shows me a compelling example, please spare me such surprising code.

@Jumhyn

I’ve worked in I fairly routinely find (and write!) bugs due to the implicit initialization of optionals

It might be a good idea to review this.

Update: Yes, I do not like implicitly initialized optionals. I even suspect this would be a breaking change that‘s worth it.

[hooman (Hooman Mehr)]

After it happened to me, I started replacing ? sugar with a parametrized type alias and found it useful in other ways. A silly example:

protocol ServiceProvider {}

final class MyServer: ServiceProvider {}
                    
typealias 🧩<Server> = Optional<Server> where Server: ServiceProvider

final class Client { // Now we have error: "Class 'Client' has no initializers."
    var server: 🧩<MyServer>
}

It is verbose, but considering the other benefits, I find it worthwhile. So, I am fine with the status quo.

[sveinhal (Svein Halvor Halvorsen)]

@ibex10

Looks like the == operator is receiving special treatment.

I don't think it is very special, or unexpected, given that Optional<A> is Equatable whenever A: Equatable, combined with optional promotion. All functions and operator behave this way.

However, I did find it somewhat surprising that I could compare a non-equatable optional value against nil.

struct NonEquatable {}
let x: NonEquatable? = nil

if x == nil { // what?! A non-equatable?!
    "nil"
} else {
    "not nil"
}

However, I found that I could replicate this behavior with no special treatment once I realized that nil is in fact a literal, and it is possible to inspect the "optionalness" of an optional using pattern matching:

struct _Nil: ExpressibleByNilLiteral {
    init(nilLiteral: ()) {}
}

func ~= <A>(lhs: A?, rhs: _Nil) -> Bool {
    if case .none = lhs { return true }
    return false
}

Well, "no special treatment" in the sense that there is no compiler magic at play, simply user code. Here, I cannot compare x against any arbitrary other NonEquatable? value, but I can compare it agains the literal nil.

[sspringer (Stefan Springer)]

@sveinhal

However, I did find it somewhat surprising that I could compare a non-equatable optional value against nil.

One should not start to think in some theoretical/complicated way, but start with what an optional is supposed to be conceptually and what follows from that in a "natural" way.:

1. Checking if an optional is equal to nil is at the heart of what an optional should be.

2. Then when you have two optionals of something equatable:

1st optional	2nd optional	equal?
nil	nil	true
value 1	nil	false
nil	value 1	false
value 1	value 2	if and only if value 1 = value 2

This is the starting point and the intuition that most people will have about it, no matter what the compiler is doing in the background. The mechanics of the language should make sure that the intuition is met, and not the way around, so to speak. Else, you will have a hard time writing or understanding code.

Conversely, if you start introducing effects that do not fit well with this "clear" intuition, you should have strong reasons to do so.

[jaleel (Jaleel Akbashev)]

@sspringer

This is the starting point

Not quite, for me starting point is thinking of Optional as a type, then == nil is comparing to .none and == someValue is unwrapping it with Equatable (and whatever rule there for WrappedValue).

[sspringer (Stefan Springer)]

@jaleel

for me starting point is thinking of Optional as a type, then == nil is comparing to .none and == someValue is unwrapping it with Equatable

But then why do you invent this mechanics?

[sveinhal (Svein Halvor Halvorsen)]

@sspringer

One should not start to think in some theoretical/complicated way, but start with what an optional is supposed to be conceptually and what follows from that in a "natural" way.:

Sure, but it's fun to understand how this works. To me, this seemed like compiler magic at first, before I realized it was not.

[1-877-547-7272]

The actual code the standard library uses to enable comparisons of non-Equatable instances to nil is in stdlib/public/core/Optional.swift between lines 430 and 607, if you're interested.

[sveinhal (Svein Halvor Halvorsen)]

@1-877-547-7272

The actual code the standard library uses to enable comparisons of non-Equatable instances to nil is in stdlib/public/core/Optional.swift between lines 430 and 607, if you're interested.

Except for being named _OptionalNilComparisonType instead of _Nil and a few extra overloads and @transparent @frozen etc, the code is more or less the same as I wrote up top <3