In my latest installment of "Swift, WTF?", we look at the "if" conditional in terms of the Swift convention of:

if let x = y { /* ... */ }

so what this does :
1. declares x in the scope of the braced code
2. sets x to y (an ahem, "optional")
3. decides if x is not *nil*, then executes the braced code.

This is very similar in both the visual and the operation to the C code of:

if (int x = y) { /* ... */ }

1. declares x in the scope of the braced code
2. sets x to the value of y
3. if x is not zero, then executes the braced code

which is considered *exceptionally* poor style.

Neither the C nor the Swift construct result in a legitimate boolean value of "true" or "false", although C comes closer than Swift.

In the Swift case the *imaginary* "nil" value has to be interpreted as "false" and thus there must be extra code is for the conditional to check on whatever constitutes the **actual** value of nil in Swift and then set the condition to "false".

(remember boys and girls, "optionals" are not real, they are an imaginary language construct of Swift and have no legitimate counterpart in the CPU operations with memory and registers)

At least in the case of C, if the value of x is zero or NULL (which is 0) then it is technically a "false" which in C is 0. Regardless, it is really poor programming and anyone doing that on my team gets an ear full.

But in Swift this obfuscation of code is common and condoned! Well, why not put more of the program in the condition of the if? In fact, stuff the whole thing in there.. why not? 🙄

This just reenforces my opinion that Swift is not a bird but the stuff that comes out of the underside of the bird. 🐦💩

when you end up in the ER with excruciating pain early on a Saturday morning from persistent inflammation from chronic job stress and getting sick more than normally, you gotta change jobs.

no amount of money is worth your health.

(the drugs they gave me were pretty fun though, but not something I ever want to go through again)