[swift-evolution] Proposal: Extend the &x -> UnsafePointer behavior to work with immutable values

[Joe Groff]

> On Dec 16, 2015, at 2:24 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Dec 16, 2015, at 11:54 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Dec 16, 2015, at 11:44 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> # Introduction
>>> 
>>> Swift allows you to pass a &x ref to a function taking Unsafe[Mutable]Pointer, as long as x is mutable.
>> 
>>> # Solution
>>> 
>>> Allow for using &x with immutable values if and only if the reference is passed as a parameter to a function expecting UnsafePointer
> 
> +1 from me on the feature.
> 
>> Seems reasonable. As I mentioned on swift-dev, '&x' in Swift indicates "this call mutates x with inout semantics", not the C sense of "I'm passing a pointer", so doing the conversion without an '&' seems more Swift-ish to me.
> 
> I don’t think that "more Swift’ish” is a good enough rationalization here :-)
> 
>> The semantics of the implicit const pointer conversion also only allow the C call to treat the parameter as if it were an immutable value operand; any capture of or mutation through the variable is UB.
> 
> & is a sigil foisted onto the caller, in order to make the semantics of the function more clear, there is no implementation reason to require it.  I suppose what you’re really claiming is that the caller shouldn’t have to use & here, since no mutation is possible and nothing for the caller to need to think about.
> 
> I’m not sure about that. Consider that this is our current behavior:
> 
> 	func f(a : UnsafePointer<Int>) {}
> 	var a = 42
> 	f(&a)  // ok
> 	f(a)  // error: cannot convert value of type 'Int' to expected argument type 'UnsafePointer<Int>’
> 
> It seems weird to me that we’d change this behavior for var, or make UnsafePointer be inconsistent with UnsafeMutablePointer.

The UnsafePointer and UnsafeMutablePointer conversions have different semantics—the former can't change the variable, but the latter can—so it seems reasonable to me that they look different.

> Further, UnsafePointer should *also* accept an array as it currently does, and it would be weird to either take a scalar or an array.

We already do this for UnsafeMutablePointer, which can take &scalar or &array. The point of the conversions is similar to IUO—we don't know whether the C API is intended to behave as an 'in' scalar, 'in' array, or significant pointer parameter purely from its declaration, so we try to make all of the common possibilities work.

-Joe

-Joe