Hi,
-- I just realice that in nested functions the reference to self is not mandatory. For example:
The equivalent implementation with closures instead of functions require self in every reference to bar as expected. What's happen here with those invisible references? You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/7eabe4f2-9e8a-40b6-9232-0eed6f7b1bf3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. |
This is an artificial limitation introduced to make it more obvious when you're capturing self. Basically, the problem is that this: myProperty = { myMethod() } Creates a retain cycle. By requiring you to say "self.myMethod()", Swift's designers hope to make it more obvious that the closure is capturing self. Sent from my iPad -- You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/B9AE8767-C615-4AC9-A47C-2D9B28458B14%40architechies.com. For more options, visit https://groups.google.com/d/optout. |
I know that the requirement of self is just to make clear that you are retaining it, but in closures you can also specify if you want an unowned or weak reference to self.
-- How do you that with nested functions? the syntax for closures doesn't seems to work. El vie., 27 de nov. de 2015 a la(s) 2:10 p. m., Brent Royal-Gordon <[hidden email]> escribió:
You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/CA%2BaYCtf7ovN61-WtYxWX2-Tqr0esn59EKfngLDTpMxuoXMP%2Bvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. |
I think I found something. If my calculous are correct the nested functions approach hold an strong reference to self silently. What I do was look at the intermediate representation of this example and try yo figure out what's going on with the implicit reference to self:
I change my original example a little for simplicity. To get the intermediate representation I use:
Here is what I think are the important parts, the full file is attached:
So my conclusion is: don't use nested functions the way Apple does in the Swift manual because it hold a strong reference to self without tell you anything. If anyone with more solid knowledge of SIL could look at this and give an answer it will be great. Thanks! On Friday, November 27, 2015 at 2:49:42 PM UTC-3, Bruno Berisso wrote:
You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/eb41235a-ee2a-4162-8a97-4849281f1337%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. |
Yes, this is the current (and correct) behavior. You’re right that this can cause a surprising capture of self, which can lead to reference cycles. To combat that, we have briefly considered requiring “self.” qualification within nested functions (just like we do within no-escape closures) but haven’t had time to do the implementation work to make sure it isn’t totally annoying. To roll this out, we’d want to do some local analysis of nested functions, to infer when they are “obviously” only called (not escaping) and not require “self." qualification there (since direct-calls-only are pretty common in some people’s use of nested functions). This isn’t an incredibly difficult analysis, we just haven’t had time to implement it. -Chris -- You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/7436A222-FC38-429B-813E-941E90B1D7B8%40apple.com. For more options, visit https://groups.google.com/d/optout. |
Really appreciate your answer. Thanks! On Tue, Dec 1, 2015 at 3:23 PM Chris Lattner <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "Swift Language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/CA%2BaYCtc68wxFwGPVuqBKFs2wTi1aFWjp%3DgQMtb7c_9hUuwm6Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. |
Free forum by Nabble | Edit this page |