[swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Andrew Trick]

> On May 9, 2016, at 1:16 PM, Joe Groff <jgroff at apple.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160509/7f8e4728/attachment.html>