[swift-evolution] Should Swift apply "statement scope" for ARC

[Dave Abrahams]

on Thu Sep 22 2016, John Holdsworth <swift-evolution at swift.org> wrote:

>> On 22 Sep 2016, at 23:57, Michael Gottesman <mgottesman at apple.com> wrote:
>> 
>>> As a result the following transfer of a Java instance always worked:
>>> 
>>>     init(imageProducer:ImageProducer) {
>
>>>         let supr = CanvasBase()
>>>         super.init( javaObject: supr.javaObject )
>>>         image = createImage(imageProducer)
>>>     }
>>> 
>>> But the following only worked for debug compiles:
>>> 
>>>     init(imageProducer:ImageProducer) {
>>>         super.init( javaObject: CanvasBase().javaObject )
>>>         image = createImage(imageProducer)
>>>     }
>>> 
>>> Felt like a bit of a bear trap is all. Statement scope would avoid problems like this.
>> 
>> You are thinking about this the inverse way. That the first case
>> works is an artifact of the optimizer failing to do a good enough
>> job. Future improved ARC optimization can cause both to fail.
>
> Were this the case I think it would be a step in the wrong direction. Swift is getting
> very eager at deallocating objects hence all the "withXYZ()" methods of late which
> seem like noise to me. Certainly, having something perform differently from debug
> to release builds was not a feature! Viva la Statement Scope which solves all this.

Having had a background in C++, where that rule is de rigeur, and after
working on its core language definition including move semantics, I am
*really* happy we're not making the same mistake in Swift.

The lack of such a guarantee, which is very seldom actually useful
anyhow, is what allows us to turn costly copies (with associated
refcount traffic and, often CoW allocation and copying fallout) into
moves, which are practically free.  Adopting it would basically kill our
performance story for CoW.

-- 
-Dave