> On Sep 22, 2016, at 5:13 PM, John Holdsworth <m...@johnholdsworth.com> wrote:
>
>
>> On 22 Sep 2016, at 23:57, Michael Gottesman <mgottes...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
