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

[Kevin Ballard]

On Wed, Dec 16, 2015, at 01:38 PM, Joe Groff wrote:
> 
> The pointer conversions are already poorly discoverable, and people don't know they exist since code completion doesn't make it apparent. Showing the APIs as overloaded taking 'inout's or something similar would make it more apparent how you can use them.

I'm hoping that adding documentation to UnsafePointer/UnsafeMutablePointer that mentions the conversions will help a lot, and ideally the book would mention this too (presumably as a note in the section on in-out parameters). If I didn't already know about the conversion and I encountered a function expecting an UnsafePointer/UnsafeMutablePointer, my first inclination is to type "UnsafePointer" (or "UnsafeMutablePointer") into the documentation browser and read the results. This is why I don't like withUnsafe[Mutable]Pointer[s]() existing, because it makes people think that's what you have to use, when in most cases the &x conversion is simpler.

> It's my hope that better SDK annotations can make these conversions less necessary too, by letting us eventually import well-behaved in/inout/out arguments directly as value arguments/inouts/extra returns.

That would be nice.

> >> We added them because they *are* necessary.
> > 
> > You still haven't demonstrated that. Every single use of withUnsafe[Mutable]Pointer[s] that can't be handled with the implicit &x conversion can be replaced with a nested function, a call to an anonymous closure, or an (ab)use of withExtendedLifetime. And the existence of the functions encourages people to call them when a simple &x ref would have sufficed.
> 
> I guess it's a difference of perspective. Your alternatives hinge on blessing the pointer conversions as a core part of the language, rather than an affordance to make many C APIs not totally awful, which I'm not comfortable with.

I guess it is. From my perspective they're already a core part of the language.

-Kevin