[swift-evolution] Proposal: [stdlib] Remove withUnsafe[Mutable]Pointer[s]()

[Michael Gottesman]

> On Dec 16, 2015, at 3:05 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
> On Wed, Dec 16, 2015, at 11:54 AM, Michael Gottesman wrote:
>> 
>> One thing to keep in mind here is that with*Pointer and friends is also meant to enable one to work around issues with the optimizer if they come up in a convenient manner. I.e. imagine if one is attempting to process an image using a 5d array and for whatever reason, you are not getting the performance you need. Hopefully you would file a bug report and then use with*Pointer for your image processing loop.
> 
> The cited workarounds should all behave identically to withUnsafePointer() and friends. There's no special optimization done in withUnsafePointer() that's relevant. For the array example you cited, you'd actually want to be calling Array.withUnsafeMutableBufferPointer() anyway, as withUnsafePointer() doesn't do anything useful there.

The interesting example is that by using withUnsafePointer one can avoid ARC, COW, or Uniqueness Check overhead.

> 
>> My fear about withExtendedLifetime is that the name is a misnomer. You are not extending the lifetime.
> 
> I assume you mean that you don't need to extend the lifetime, rather than that it's not actually extending anything (because it is, it's just technically extending the lifetime of the UnsafePointer).

No, what I am saying is that withExtendedLifetime implies some sort of special lifetime extension (otherwise, why would one specifically call it out). It is not performing any sort of special lifetime extension, it is just using the normal lifetime extension rules.

> 
> But in a sense it's actually correct anyway. In the rare case where you need one of these workarounds (e.g. you need to use the pointer several times without it changing, or you need to use a value derived from the pointer while the pointer is still valid), you actually do need to extend the lifetime of the value that was passed by-ref into the function. Swift already ensures the lifetime is valid for the duration of the call because it's an inout parameter and the function itself is only going to actually keep the pointer alive, but in a broader sense you are saying "keep this value alive for the lifetime of this closure, and give me a pointer to it".


Michael