<div dir="ltr">Would `consumeReleased` work at all? It captures the 'don't use this again' aspect and 'release' without much extra.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 7:45 PM, Rainer Brockerhoff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/12/15 16:46 , <a href="mailto:swift-evolution-request@swift.org">swift-evolution-request@swift.org</a> wrote:<br>
> Date: Fri, 18 Dec 2015 11:38:31 -0800<br>
> From: Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>><br>
> Subject: Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged<T><br>
> Message-ID: <<a href="mailto:E82AADA9-F4A4-4E4E-98C3-6E9A3CEC4D12@apple.com">E82AADA9-F4A4-4E4E-98C3-6E9A3CEC4D12@apple.com</a>><br>
<span class="">><br>
>> > On Dec 17, 2015, at 6:23 PM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com">griotspeak@gmail.com</a>> wrote:<br>
><br>
>> > My main point of contention with `.release()` is that it has the *exact* same name as a method from the MRC strategy. Maybe this is a silly point, but this overlap could further complicate teaching how ARC works and in what ways it is based on MRC conventions.<br>
>> > I am not of the opinion that ARC is fundamentally more difficult to understand than MRC, but I do believe that it takes a very particular kind of faith now that we don't get to manually write the retains and releases. This is completely worth it, in my opinion, but I want to avoid making it *more* confusing to explain what ARC doing at compile time.<br>
</span><span class="">> Well, unsafeRef.release() is equivalent to<br>
><br>
> {<br>
> let x = $0.object<br>
> CFRelease($0) // if CFRelease() wasn't @unavailable<br>
> return x<br>
> }(unsafeRef)<br>
><br>
> If you let the return value drop on the floor, it ends up being<br>
> exactly equivalent to the method with the exact same name from the<br>
> MRC strategy. So the correspondence is strong and shouldn’t be a<br>
> problem. That’s just my opinion, though, and part of the reason<br>
> we’re asking for feedback here is so people steeped in MRC like you<br>
> can argue with me about that :-), so if you find this unconvincing<br>
> please explain why.<br>
<br>
</span>OK, guess I qualify as "steeped" there - I still use MRC in all my<br>
shipping apps, although I've tentatively used ARC in small fry like<br>
build-time utilities. (Never got used to GC.)<br>
<br>
Anyway, much of my code looks like one of these patterns:<br>
<br>
// 1<br>
NSDictionary* dict = [(id)CFCreateSomeCFDictionary() autorelease];<br>
... use dict for some lines, done<br>
<br>
// 2<br>
NSArray* array = (NSArray*)CFGetSomeCFArray();<br>
... use array for some lines, done<br>
<br>
// 3<br>
NSString* str = (NSString*)CFCreateSomeCFString();<br>
... use str for some lines<br>
[release str];<br>
<br>
One thing about my not migrating to ARC is that I find the bridging cast<br>
names opaque - can't memorize them! Same, sadly, was true for the<br>
Umanaged<T> methods.<br>
<br>
So I'd say, use `.release` or `.autorelease` if they'd be used in the<br>
same place as above...<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Rainer Brockerhoff <<a href="mailto:rainer@brockerhoff.net">rainer@brockerhoff.net</a>><br>
Belo Horizonte, Brazil<br>
"In the affairs of others even fools are wise<br>
In their own business even sages err."<br>
<a href="http://brockerhoff.net/blog/" rel="noreferrer" target="_blank">http://brockerhoff.net/blog/</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>