Yeah, that makes sense. If your C API requires an intptr_t, you can't solve
that problem by adding more functions to UnsafePointer. I'll go ahead and
start a discussion over on swift-evolution. Thanks!
On Tue, Dec 8, 2015 at 3:07 PM, Jordan Rose wrote:
> The one I can think of is "sometimes a C
The one I can think of is "sometimes a C API only lets you pass data as an Int
(intptr_t) or as an UnsafeMutablePointer (void *), and you have the other kind
of data". That said, it does seem to be sort of a niche use case.
Jordan
> On Dec 8, 2015, at 7:59, Michael Buckley via swift-dev
> wro
Checking alignment good use case, which I did not consider. Not to turn
this into a swift-evolution topic, but couldn't this use case be covered by
adding functions to UnsafePointer? I'm thinking something like this.
func distanceToBoundary(_ boundary: Int) -> Distance {
return Builtin.ptrtoin
When writing high-performance code, it is fairly common to check the alignment
of pointers so that initial elements can be processed until some suitable
alignment is reached to use a faster implementation, or to verify that a fast
algorithm can be used.
> On Dec 8, 2015, at 10:59 AM, Michael Bu
I'm looking for a good starter project, so normally I would be interested
in taking this, but I'm not sure I can think of a good motivation for it.
UnsafePointer's advanceBy and distanceTo functions take care of pointer
arithmetic more safely than converting to int would, and the
debugDescription p
Hi everyone,
The standard library has bitPattern initializers on pointers. But we
are missing initializers to create integers from pointers.
Someone needs to propose these APIs, walk them through
swift-evolution, write a patch for the library and add tests.
extension UInt {
init(bitPattern: Un
