[swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

[Anders Kierulf]

> To be clear, the only case that’s really giving you grief is this one right?
> 
>   func get(_ pointer: UnsafeRawPointer, at index: Int) -> Int
> 
>   _ = get(letTuple, at: 2) // fails: wrong type

Yes. If that one could work without performance penalty, that’s perfect. (Assuming that homogeneous tuples are the best approximation of fixed-size arrays, for now.)

Actually, an indexed access into homogeneous tuples would solve this without even needing to use UnsafeRawPointer. Any +1 for that?

> And you don’t want to create a temp copy:
> 
>   var tupleMemory = letTuple
>   get(&tupleMemory, at: 2)
> 
> In this case, the letTuple->UnsafeRawPointer conversion is likely going to create that copy anyway in order to give the tuple a memory address. A slightly more compelling example would be:
> 
> struct S {
>   var tuple: (Int, Int, Int, Int, Int, Int)
> }
> 
> func foo(s: S) -> Int {
>   var tupleMemory = s.tuple // was s.t, should be s.tuple [AK]
>   return get(&tupleMemory, at: 2) // fails: wrong type
> }
> 
> Are you more concerned that the copy won't be optimized away or that you need the extra line of code?

My main concern is performance. In my code, the tuple is often 380 words long, so a copy completely kills performance. This part of my code is performance critical, which is why I can’t just use Swift’s standard Array type.

> … I forgot to mention. Regarding this line:
> 
>   let a = pointer.bindMemory(to: Int.self, capacity: 6)
> 
> If the tuple memory is always viewed as (Int, Int...), then you can use assumeMemoryBound(to:) and don't need to specify capacity.
> 
> -Andy

Thanks, assumingMemoryBound(to:) is good to know.

Anders