> On Oct 26, 2017, at 3:24 PM, David Hart <[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.
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
