Open sunshinejr opened 4 years ago
I’m all for removing implicitly unwrapped optionals. But, isn’t the reason for that to create more safety? This technique moves the exact same crash to a different place. The advantages are that you have control over making the fatal error message and the properties are no longer decorated with the dreaded ‘!’. But, sadly, it doesn’t improve safety. Unless, i’m missing something?
That said, it is fun to see how everyone is using property wrappers. Thank you for the posts.
@briancordanyoung I think this improves safety, at least a bit, by using a Type
instead of a Type!
- you avoid optionals, you also avoid availibility to nil
a value that shouldn’t be nil
ed at all. This property wrapper is for the cases where you don’t really have an optional value, but you have to specify the type as that because of some limitations (either Swift’s or any framework’s).
Also I think utility is much bigger gain in this case (type change) than the safety improvement. But again, your mileage may vary.
you also avoid availibility to nil a value that shouldn’t be niled at all.
That is something I didn't consider. So, yes, a little safer.
If you do not have the @IBOutlet
, does it show up inside Interface Builder? I would say it does not, but if that is the case, how are you using it?
You have slightly removed 'weak' from the outlets? Do you use them always as strong? Did you try with property wrapper on a weak property? 🤓
@angelolloqui yes it doesn't as I guess they are hardcoded the IBOutlet
annotation inside IB. I just create the bindings as you would normally do and then remove IBOutlet
and replace it with the @Delayed @objc
. Tiresome but I like the benefits. I guess there could be a build-phase script (before building your files) that would replace all IBOutlet
occurrences with @Delayed @objc
and that way we could automate it a little bit more.
@david-grigoryan-dev ah seems like property wrappers can't be used with weak
properties? Sad limitation but probably only temporary. Also, strong
is the recommended binding type in IBOutlet
s (though there are cases where weak
makes sense but I don't remember last time I needed a weak outlet).
It is an interesting use of wrappers but I do not see the benefit if you lose the ability to link from IB. Too much hazle for nearly no gain (IMHO) which as far I can see it is only the protection against assigning nils (who and why would do that by the way?). Anyway, the idea is pretty nice for other usages I guess! Thanks for sharing!
@angelolloqui fair enough! There are a lot of people that share the same feelings and that's completely fine. I, personally, really dislike the force-unwrapped IBOutlet
s and was looking for a cure for many months so, naturally, I was really hyped when I found out a solution.
But as you've said this can be used in many other places - I especially love it in convenience initializers in ViewController
s to. I'm just a big fan of this property wrapper, really, and I hope you will enjoy it as much as I do.
Some thoughts IMHO. @Delayed
sounds like something to do with time. And the underscore convention is ... strange ...
Agree with most of the comment above but I also wanted to highlight that the use of !
isn't just a hold-over from Objc-C code. Its also a valid approach to inform the API consumer.
Marking a variable as optional, tells the consumer it can be nil. Marking it as explicitly unwrapped
tells the consumer it might be nil during instantiation, however it should NEVER be nil afterwards – It would've been great if this was literally prevented by the compiler, the same way let
only allows a variable to be set once, but that's another topic.
It makes sense with @IBOutlet
since it is late-binding. The use of !
here tells the consumer that the variable MUST not be nil after init
has occurred.
––
Side note: @LateBinding
might have been a better name for your property wrapper. Not a perfect name still, but perhaps a little better.
🚨