>
> My migration guide landed on swift.org today! I think it will be a big
> help.
> https://swift.org/migration-guide/se-0107-migrate.html
>
> -Andy
>
Thanks Andy, this is great!
I hope that over time, even more accessible material is added for
newcomers. I still feel I would have a hard time answering the question of
what bindMemory "does", if someone asked me. My impression is that all
these methods are really just hints to the compiler about which kinds of
transformations/optimizations are allowed and which are not — making it
aware of aliasing.
The example below (from your proposal) is a good, practical showcase of
what might go wrong with aliasing. But what *should* this look like when
using the new API / how do the changes help prevent these problems? The
example shows only the "old version".
// --- old version ---func testUndefinedExecution() {
let pA = UnsafeMutablePointer<A>.allocate(capacity: 1)
pA[0] = A(value:42)
if pA[0].value != 42 {
// Code path should never execute...
releaseDemons()
}
// This compiler may inline this, and hoist the store above the
// previous check.
unforeseenCode(pA)
}
func releaseDemons() {
// Something that should never be executed...
}
func assignB(_ pB: UnsafeMutablePointer<B>) {
pB[0] = B(value:13)
}
func unforeseenCode(_ pA: UnsafeMutablePointer<A>) {
// At some arbitrary point in the future, the same memory is
// innocuously assigned to B.
assignB(UnsafeMutablePointer(pA))
}
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
