> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution
> <[email protected]> wrote:
> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart <[email protected]
> <mailto:[email protected]>> 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.
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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
