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

[Andrew Trick]

> On May 18, 2017, at 7:23 AM, Anders Kierulf <anders at smartgo.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170518/5b5b1010/attachment.html>