[swift-evolution] Guard Implicit Fallback
Myles Schultz
myleslschultz at icloud.com
Thu Feb 11 17:20:40 CST 2016
Generally, if you're using guard, you're looking for something that your program requires before moving on. If you get nil back, you probably want to do more than just return nil. When you're developing something, returning nil is simply convent, but doing something about that so the user realizes something has gone wrong is also important.
At the same time, I don't see why we couldn't have both: guard and guard else. Much like ARC, couldn't the compiler provide a case where lines that only specify guard automatically return nil and guards that specify an else run the specified else in that instance?
Myles
Sent from my iPhone
> On Feb 10, 2016, at 10:40 PM, Tighe Racicot via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hey everyone,
>
> I feel that `guard` could be a little more Swifty and would like to start a conversation concerning it.
>
> For example, I often have a function whose job depends on an optional having a value, and so I guard-let at the start and return if the guard fails. Or if the function returns an optional type, I'll simply return nil if guard fails.
>
> Can we improve on the general fallback case? Could we simply say:
>
> func noReturn() {
> guard let aValue = someOptional
> ....
> }
>
> and have that imply "else { return void or nil }"
>
> What are your thoughts?
>
> Tighe
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/20593f25/attachment.html>
More information about the swift-evolution
mailing list