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

[Joe Groff]

> On Sep 22, 2016, at 5:13 PM, John Holdsworth <mac at johnholdsworth.com> 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.

Statement scope is a brittle solution these problems. There's no shortage of C++ code that ends up subtly broken when it's refactored and ends up breaking due to hidden dependencies on statement scope. The precise lifetime semantics of C++ also prevent practically any optimization of nontrivial types without the explicit blessing of a handful of special cases like NRVO.

-Joe