I’m not particularly impressed by of any of these extensions, because they don’t seem to actually fix the underlying problems. I used to write code that was overly defensive around Optionals, and I’d carefully do things like wrapping in flatMap or throw guards in, but I’ve come to realize that this just ends up hiding errors in the cases where you know something is supposed to have a value. For this article in particular, I think there are better ways to do what he’s trying to do:

For the converting an Optional to an error example, he could just put both statements in one guard. Sure, being able to show that you’re passing a function into another is pretty, but it really is overkill for something that doesn’t even need an extension to Optional.

I think isNilOrEmpty, personally, just encourages papering over bad APIs: it is never correct to represent an empty Collection with nil. UITextField.text should never be nil (to the point where I think that this method is improperly annotated; I can go check though); if it is your view hierarchy is in a state where asking it for its text returns nil this should be a hard error because you must have messed up somewhere. Just force unwrap in this case, and if you’re designing an API, think twice about returning Collection?.

Lastly, get(orSet:) is just a skirting around the issue. Forget to set the value of this view? Just set it again! Just ignore the fact that a clear logic error that must have occurred if I ended up at a point where I’m trying to access a view that doesn’t exist.