[swift-evolution] Better syntax for deferred?

[Javier Soto]

How would always behave if the function has an early return? Like so:

func testAlways(x: Int) {
print("non-deferred call")
return
let a = 3
always {
print("deferred call: \(a)")
}
}
On Sat, Jan 2, 2016 at 9:56 AM Tim Hawkins via swift-evolution <
swift-evolution at swift.org> wrote:

> Again my 2 cents
>
> Other languages use "deffer", and have very simular semantics, there is no
> benifit gained from being different, and it makes peoples task of
> transfering from other systems easier.
>
> The percieved "simplicity" of the alternative semanatics and naming is
> subjective. What is there works just fine and achives the result it was
> designed to do. Why do we need to change it?
> On Jan 3, 2016 1:47 AM, "Maury Markowitz via swift-evolution" <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s
>> just what it does. And the deferred calls are not always necessary so they
>> can’t always be placed at the end.
>>
>> Can you be more specific about "deferred calls are not always necessary"?
>> Do you mean that you could, for instance, place an if in front of the
>> defer? If so one could do the same with always, of course. I'll use your
>> example, slightly expanded, to illustrate
>>
>> > func testDefer(x: Int) {
>> >    defer {print("deferred call1")}
>> >    if x > 1 { defer {print("deferred call2")} }
>>     print("non-deferred call")
>> > }
>>
>> I would rewrite this as:
>>
>>     func testAlways(x: Int) {
>>         print("non-deferred call")
>>         always {
>>             print("deferred call1")
>>             if x > 1 print("deferred call2")
>>         }
>>     }
>>
>> Which is 100% equivalent to your example, but works precisely as you
>> would expect without needing to "be aware" of any "logical consequence"s.
>> The code runs exactly as it appears.
>>
>> _______________________________________________
>> 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
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160102/eb020e88/attachment.html>