> On 26 Oct 2017, at 21:40, John McCall <[email protected]> wrote:
>
>> On Oct 26, 2017, at 3:24 PM, David Hart <[email protected]
>> <mailto:[email protected]>> wrote:
>>> On 26 Oct 2017, at 21:16, John McCall via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution
>>>> <[email protected] <mailto:[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.
>>
>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
