[swift-evolution] Guard Implicit Fallback

[Thorsten Seitz]

+1 to the arguments of Robert and Xiaodi

-Thorsten


> Am 11.02.2016 um 18:46 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org>:
> 
> I believe this has already been proposed on the list in the past. I don't have easy access to the archives at the moment so I can't provide a convenient link.
> 
> The gist of it--or at least one of the compelling arguments against the idea--was that the 'obvious' implicit behavior becomes non-obvious when you take into account guard statements inside loops, for example. Do you continue? break? return? And once you make a decision for each of the scenarios envisioned you end up with a complicated series of fallbacks that need extensive documentation, which is no longer much of a win over explicitly writing your fallback.
> On Thu, Feb 11, 2016 at 11:38 AM Developer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I agree the nil fallback case is a common one, but the loss of readability and decreased understanding of control flow here makes me think special-casing this isn't all it's cracked up to be.
> 
> ~Robert Widmann
> 
> 2016/02/10 22:40、Tighe Racicot via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/9b64e45d/attachment.html>