Swift’s Mysterious Behavior Even AI Can’t Predict!

Hello everyone 👋 I came across a real mind-twist in Swift. This one should be very simple (no escaping, no concurrency involved) but the result is very surprising!

Take a look at this code and guess What happens if we run this code:

It’s simple! I’ve added comments to make it more understandable (and you can copy it if you like to play around with it):

// A function that performs an action closure and returns the first argument, untouched.
func foo(date: Date, action: () -> Void) -> Date {
    action()
    return date
}

var actionDate = Date.now // 👈 Setting current time as the initial value

let resultDate = foo(date: Date.now) { // 👈 Passing current time
    actionDate = resultDate // 👈 Using the result of the function, inside the closure argument of the function itself
    print("Assigned")
}

print(actionDate == resultDate)
print(actionDate)

P.S. Don’t bother asking AI about it; it won’t get this one right 😉

🧠 First Thought: Compiler to rescue

We’d expect this to be illegal accessing resultDate. inside its own initialization should cause a compile error. Something like:

or like this:

or this:

or at least this:

But nope… compiler says “it’s fine to me” and compiles it without any error or warnings. Things just get weirder from here. 🤔

🧠 Second Thought: Watch dog

Ok, maybe it compiles, but surely it should crash at runtime! because we’re BAD ACCESS-ing a variable before it’s initialized or infinitely and recursively calling a value, right?

Wrong again! it happily prints. 😕

🧠 Third Thought: Unexpected Expectation

So maybe actionDate == resultDate is true, as ”Assigned” was already printed before that comparison?

Nope. It prints false. 😟

🧠 Fourth Thought: Questioning fundamentals…

For the sake of god, if they’re not equal, maybe the resultDate never happened to have a value at the time, and actionDate should be nil, hm?

Nope. It actually has some value and it is not none. 😨

🧠 Fifth Thought: Today is not Today!

Maybe it evaluates the argument Date.now where ever needed and uses that? Yes! (proudly), it should be actionDate == .now and resultDate == .now. However, since every time we call .now, there’s a tiny fraction of a second difference, it should be false with a slight difference.

But nope again! actionDate is Optional(2001-01-01 00:00:00 + 0000) The reference date??? WHY??? 😱

🧠 Sixth Thought: Free init()

Maybe Swift is using the default initializer (init()) of the type as some “mysterious fallback” for unassigned variables? Let’s test:

Int -> pass 1234 -> prints 0 ✅ Proved!
Bool -> pass true -> prints false ✅ Proved!
Double -> pass 12.34 -> prints 0.0 ✅ Proved!
String -> pass "Hi" -> prints nil ❌ ……! // String.init() is "" no nil

…. and then we remember:

Date() returns .now, not the reference date. What a shame! 🤦🏻‍♂️

🧠 Final Thought: Challenge the language

OK Swift! Let’s see what you do with my custom type without any initializers AT ALL!:

enum Bar { // 👈 No rawValue, no initializer, no anything weird
    case a
    case b
}

func foo(bar: Bar, action: () -> Void) -> Bar {
    action()
    return bar
}

var actionBar = Bar.b  // 👈 Setting the case .b

let resultBar = foo(bar: Bar.b) { // 👈 Passing the case .b
    actionBar = resultBar
    print("Assigned")
}

print(actionBar == resultBar)
print(actionBar)

Result: (drums…. ):
🥁
🥁
🥁

![](https://miro.medium.com/v2/resize:fit:1092/1*ZfDzHTCejnEKzGn-PQZ3ZQ.png)

OH MY GOD! 🤯 HOW ON EARTH DID YOU PICK THE CASE A ??? 🤬 There is literally no mention of `.a` NOWHERE!

What is happening here? Is this unstable behavior of our beloved Swift, by design? How can we fix it in the way we expected?

Drop your theory in the comments before reading **part 2**!
Don’t forget to hold the clap 👏 as long as you can 💪

Thank you and stay tuned.