> On Jun 27, 2016, at 2:45 AM, Manuel Krebber via swift-evolution 
> <[email protected]> wrote:
> 
> On 06/26/2016 09:10 PM, Christopher Kornher via swift-evolution wrote:
>> The core proposal:
>> ——————
>> 
>> Closures capturing object references should automatically capture all
>> object references as weak.
> In my code, most closures are used in a functional programming capacity,
> e.g. with map(), reduce, etc. Hence, most closures are non-escaping and
> local, where strong capture is the desired way. Otherwise I would have
> to litter everything with optional unwrapping or add the explicit
> capture definition which would both make the code less readable in my
> opinion.

I thought about this some more and it makes sense to treat non-escaping 
closures are they are treated now. This might increase the burden on the 
compiler especially because these closures may not be declared inline. This 
would be far more straightforward than having to worry about changes to object 
existence within one or more invocations of a @nonescaping closure, especially 
in multi-threaded code.

I do not think that this would be a significant change for developers in 
practice. Any developer who would try to rely upon object references changing 
within the application of a @nonescaping closure would probably have read the 
manual very carefully :)


>> 1) Closures with object references could be simplified further by
>> implicitly including ‘let’ guards for all object references:
> This sounds good for closures without return value, but how would you
> handle closures with non-optional non-void return values?

Good point.

1) The simplest solution would be to have these closures require capture lists 
to some or all object references. Given the prevalence of the weak/strong 
dance, calling these out in some way probably should be done anyway.

2) Another option would be to eliminate the implicit nil check guards, making 
all object references optional. The compiler would force these to be unwrapped, 
so users would be guided to do the right thing.

3) Just always weakly capturing all object references would treat all closures 
uniformly.

> Also I think that explicit error handling in case of "expired" objects
> is safer than silent failure (by not executing the closure).


I believe that it is decision that should be left up to the author of the 
closure. Sometimes it is, sometimes it isn’t.

> 
> Kind regards, Manuel
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to