So what's in it for us as Swift devs?<br><br>It may be technically undefined behaviour (by that I think you mean there's no real knowing what could happen), but it seems to be rampant throughout pretty much all the C code I've come in contact with (I'm less familiar with C++).<br><br>If we lose type information by calling a C API that takes a void pointer, how can we hope to retrieve it in any safe way, other than saying "we assume with good reason and hope to hell that this is what we say it is". And if we can't do that, what advantage does this proposal provide over what we already have?<br><div class="gmail_quote"><div dir="ltr">Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> schrieb am Mo., 9. Mai 2016 um 22:16:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 9, 2016, at 12:38 PM, Geordie Jay via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I read this proposal and I'm a bit unsure what its purpose would be:<br>
><br>
> Basically you want to prevent UnsafePointer<XYZ>(UnsafePointer<Void>) conversions and/or vice-versa? And you'd achieve this by replacing UnsafePointer<Void> with UnsafeBytePointer that has no bound pointer type?<br>
><br>
> In one sense the change seems fine to me, but as someone who uses a lot of C APIs and a lot of CoreAudio/CoreMIDI in Swift already I can't really see what benefit it'd bring. Presumably we'd still want an option of converting UnsafeBytePointer to UnsafePointer<SomeActualType> for things like C function pointer callback "context"/"userInfo" uses, so it's not like we'd be preventing programmer error in that way.<br>
><br>
> Call me conservative but to me the current system seems to work as well as it can. If anything it's already enough boilerplate going through hoops converting an UnsafeMutablePointer<Void> into a [Float] even when I know and the C API knows perfectly well what it actually contains... Would happily be convinced otherwise about this proposal though, I'm pretty new at all this.<br>
><br>
> Geordie<br>
<br>
> On May 9, 2016, at 12:57 PM, Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I’m sympathetic to the elimination of UnsafePointer<Void> as general shorthand for an arbitrary pointer, but I lose the plot of this very long proposal. It seems to me that this increases API surface, yet everything I could do before, I could still do; it just involves more typing. What exactly does this make better?<br>
><br>
> Cheers,<br>
> Guillaume Lessard<br>
<br>
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.<br>
<br>
-Joe</blockquote></div>