Why we use __unsafe_unretained instead of __weak?

[alexgarbarev]

Just wondering why we using __unsafe_unretained? I see only one reason - iOS4 support. But in podspec I see

spec.ios.deployment_target = '5.0'

Any reason to use __unsafe_unretained?

[alexgarbarev]

Also I didn't see reason to use __autoreleasing for values used as return value. ARC handles returned objects automatically (init, copy, new method families returns retained, other cases - autoreleased).
See http://stackoverflow.com/questions/8862023/in-which-situations-do-we-need-to-write-the-autoreleasing-ownership-qualifier to know when use __autoreleading

[jasperblues]

Why __unsafe_unretained:

For a while I forgot the answer to this question (Daniel also raised it earlier), but I remember now. I was working on a project last year and deploying on iPad 1st gen. The client had purchased this hardware as it was sufficient for the job and good value-for-money at the time.

So this project was iOS5.1 (best version of iOS possible on this device), but we had set the deployment target to iOS4.3, because, again, the client wanted to support this.

I therefore needed to drop __weak (very early versions of Typhoon had __weak) and use __unsafe_unretained (you can see that I took special care to nil-out these references in dealloc)

We ended up dropping support for 4.3 (another reason), but I decided to leave it there. I figured if my client wanted this there might be a few others out there who do too, so why not?

I agree that the chance of needing this now is even more unlikely, so we could drop it if we want.

Why __autoreleasing

There was one place where building an object with NSInvocation and ARC wasn't picking it up. Subsequently used the IDE to refactor some methods, and it added __autoreleasing in the method signature. . . I left it there, because I didn't understand at the time.

Now that we've got NSInvocation sorted drop them _all_ - the tests will indicate if this will be ok.

[alexgarbarev]

iPad 1 supports iOS 5.1.1, so client should update his firmware. I didn't see reasons to support 4.3, since older devices (iPhone 3g and iPod touch 2G) supports only 4.2.1, newer (such iPad 1gen) support 5.0.
I prefer to support 5.0 and newer iOS in typhoon.

[alexgarbarev]

About __autoreleasing with NSInvocation, see my answer
http://stackoverflow.com/questions/11874056/nsinvocation-getreturnvalue-called-inside-forwardinvocation-makes-the-returned/21426261#21426261

[jasperblues]

OK, let's make Typhoon 5.0+. . this means:

• We can use weak references
• iPhone 3g and iPod touch 2g are not supported.

[alexgarbarev]

I think we should write about it on github or website and then close the issue

[jasperblues]

Updated FAQ saying:

• We now use weak references in addition to ARC
• What iOS versions/devices are supported
• What OSX vesions/Macs are supported.. . . (10.7 and 'most Macs since 2009' ).

[jasperblues]

Does Rob Mayoff's answer in the Stack Overflow issue that you link to show that we can use ARC for TyphoonInitializer's after all?

"By marking the returnValue as __unsafe_unretained ARC will not balance the release calls, you can then take ownwership of the object by copying it to a strong variable".

[alexgarbarev]

No it can't be used in out case because when you assigning __unsafe_unretained id result = [class alloc] result will be dealloced after asignment