[swift-evolution] Inconsistencies in recursive types

[David Sweeris]

> On Mar 13, 2017, at 10:56 AM, rintaro ishizaki via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> final class First {
>     let item: First
>     init(item: First) {
>         self.item = item
>     }
> }
> 
> extension First {
>     convenience init() {
>         self.init(item: self)
>     }
> }
> 
> let a = First()
> 
> I'm actually a bit surprised that this compiles.
> This should be diagnosed as: "error: 'self' used before self.init call" I think.

Interestingly enough, this code:
final class First {
    let item: First
//    let int: Int
    let string: String
    init(item: First) {
        self.item = item
//        self.int = item.int
        self.string = item.string
    }
}

extension First {
    convenience init() {
        self.init(item: self)
    }
}

let a = First()
//print("a.int:")
//print(a.int)
print("a.string:")
print(a.string)
print("done”)
Outputs
a.string:
fatal error: unsafelyUnwrapped of nil optional
(followed by a trace and lldb prompt)
But if I switch which stored properties are commented out (and printed), it usually outputs:
a.int:
562949953421312
done
Program ended with exit code: 0
or
a.int:
0
done
Program ended with exit code: 0
with the one exception being when `a.int`’s value started with a 7 instead of a 5 (but I didn’t think to copy/paste it). That’s not the interesting part, though. If both properties are uncommented and printed, it seems to always output:
a.int:
0
a.string:

done
Program ended with exit code: 0
(note that `a.string` seems be equal to “” now)

Anyway, I’d assume this is just a demonstration of the dangers of accessing uninitialized memory, but what I don’t know is why having two properties seems to remove the randomness in one’s value and stops the crashing when accessing the other's.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170313/f863e036/attachment.html>