[swift-evolution] Making capturing semantics of local

[David Hart]

> On 26 Oct 2017, at 21:40, John McCall <rjmccall at apple.com> wrote:
> 
>> On Oct 26, 2017, at 3:24 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>> On 26 Oct 2017, at 21:16, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>>> 
>>>> class A {
>>>>     func foo() {
>>>>         func local() {
>>>>             bar() // error: Call to method ‘bar' in function ‘local' requires explicit 'self.' to make capture semantics explicit
>>>>         }
>>>> 
>>>>         // ...
>>>>     }
>>>> }
>>>> 
>>>> it's not only about calling "bar"... any variable access will require self. which will be quite annoying, especially given the fact that "local" my not even be used in an escaping context discussed. (*)
>>>> 
>>>> i think it is more consistent to prepend local with self if it is used in an escaping context:
>>> 
>>> I think this would be possible, yes.  If nothing else, we could allow the function to be explicitly declared escaping or non-ecaping to get this rule.
>> 
>> I don’t see how this makes any sense or be possible:
>> 
>> * It doesn’t make sense for me because local is not a member function of A.
>> * It would cause ambiguity when trying to call another member function with the same name as the local function.
> 
> Oh, sorry, I should've actually read the rest of the email instead of leaping to conclusions.  I meant that it would make sense to disallow implicit "self." in a local function that's used as an escaping function (and by implication, allow implicit "self." in a local function that's only used as a non-escaping function), not that we should require uses of local functions that capture self to explicitly mention that fact at the use site.

Gotcha.

> John.
> 
> 
>> 
>>> John.
>>> 
>>>> 
>>>> func foo() {
>>>> 
>>>>     func local() {
>>>>         bar()              // no self needed here ever
>>>>         variable = 1   // no self needed here, ever
>>>>     }
>>>>     
>>>>     func otherLocal() {
>>>>         print("i am not capturing self")
>>>>     }
>>>>     
>>>>     DispatchQueue.main.async {
>>>>         local()            // error without self
>>>>         self.local()       // ok
>>>>         otherLocal()       // ok without self
>>>>     }
>>>> }
>>>> 
>>>> (*) interestingly, closures always treat themselves as "escaping", even if it's not the case, e.g. even if i only use them in a non-escaping contexts. worth to add an explicit attribute to denote non-escaping closures?
>>>> 
>>>> let closure = @nonescaping {
>>>>     print("i am not escaping")
>>>>     variable = 1 // ok without self
>>>> }
>>>> 
>>>> DispatchQueue.main.async(execute: closure) // error, non escaping closure passed
>>>> 
>>>> Mike
>>>> 
>>>> _______________________________________________
>>>> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171027/fc6ef631/attachment.html>