> On May 9, 2016, at 1:16 PM, Joe Groff <[email protected]> wrote:
>
> Andy, I think it's worth clarifying the primary purpose of this proposal. Our
> main goal here is to provide a legal means for "type-punning" memory access.
> Like C and C++, it's technically undefined behavior in Swift to cast an
> UnsafePointer<T> to an UnsafePointer<U> of a different type and load a value
> out of memory that's of a different type from what was stored there. We don't
> take much advantage of this yet in Swift's optimizer, since we don't have
> good alternative API. UnsafeBytePointer seeks to fill this gap by providing a
> type that can safely do type-punned loads and stores.
Absolutely, that’s the main point. I’ll work on the proposal's language. But I
should point out that the optimizer has taken advantage of UnsafePointer’s type
for a long time. We’re only saved because when we convert UMP types, we usually
pass the memory off to an external C function, which acts as a boundary to
optimization.
The current proposal grew out of my auditing the standard library, attempting
to weed out undefined behavior.
Also note that I initially wanted to propose a much less ambitious API that
allowed type punning, but otherwise left UMP unchanged. However, I got some
strong feedback early on that if converting UMP types leads to undefined
behavior, then it should be prohibited in the API, unless the programming
explicitly requests the conversion. I happen to agree with that feedback. Since
you and others also wanted a more complete API for manual memory layout, I saw
that as one solution to both problems.
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
