> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
