[swift-evolution] Guard Implicit Fallback
Kurt Werle
kurt at circlew.org
Thu Feb 11 11:54:45 CST 2016
It seems like this is related to the issue of closures and [weak self]. It
would be nice to have similar mechanisms for both.
func mustHaveAllParameters(arg: String!)*?* -> String? // only executes if
arg is not nil. Else returns nil/Void
object.withClosure() { [unowned self]*?* in ...} // only executes the
closure if self is not nil. Else returns nil/Void
On Thu, Feb 11, 2016 at 9:46 AM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:
> 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> 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> のメッセージ:
>>
>> 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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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
>
>
--
kurt at CircleW.org
http://www.CircleW.org/kurt/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/710d6d5f/attachment.html>
More information about the swift-evolution
mailing list