> On May 18, 2017, at 7:23 AM, Anders Kierulf <[email protected]> wrote:
>
>> Thanks for refusing to let your pitch die. Something should eventually be
>> done here and it's good to get feedback. The only reason to bring this up in
>> Swift 4 is if we decide to outlaw some code pattern that's already in use.
>> If this ends up just an additive convenience request, than it can be a bug
>> report for now and come back in Swift 5. There have been a couple +1's
>> already but I don't know whether it's a serious problem or just an annoyance.
>
> For me, it’s a serious annoyance. A single wrong `mutating` in an API would
> be a minor issue, but the problem is that it infects the rest of the code
> like a plague. It’s bad enough that I’ve delayed work on that project, hoping
> for a resolution.
Ok. I hear you.
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
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.t
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?
… 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
