[swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

[Joe Groff]

> On May 4, 2016, at 10:15 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On May 4, 2016, at 10:07, Andrew Trick <atrick at apple.com> wrote:
>> 
>>> 
>>> On May 4, 2016, at 9:40 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>>> 
>>>> 
>>>> On May 4, 2016, at 09:18, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> 
>>>>> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>>> On May 3, 2016, at 8:56 PM, Chris Lattner <clattner at apple.com> wrote:
>>>>>> 
>>>>>> Hello Swift community,
>>>>>> 
>>>>>> The review of "SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer" begins now and runs through May 9. The proposal is available here:
>>>>>> 
>>>>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md
>>>>>> 
>>>>>> 	* What is your evaluation of the proposal?
>>>>> 
>>>>> The new methods are needed, but they don’t need to be overloads. I have no idea why the argument type was originally declared Mutable.
>>>>> 
>>>>> func assignBackwardFrom(source: UnsafePointer<Pointee>, count: Int
>>>>> )
>>>>> 
>>>>> func assignFrom(source: UnsafePointer<Pointee>, count: Int
>>>>> )
>>>>> 
>>>>> func initializeFrom(source: UnsafePointer<Pointee>, count: Int)
>>>>> 
>>>>> FWIW: I made precisely this change a while back on an experimental branch while experimenting with UnsafePointer conversion. I don’t see a problem with it.
>>>>> 
>>>>> Implicit argument conversion from UnsafeMutablePointer<Pointee> to UnsafePointer<Pointee> is normal and extremely obvious.
>>>> 
>>>> Yeah, Andy's approach seems cleaner than overloading.
>>> 
>>> :-( …but it’s an implicit conversion. Which we’re trying to expunge from the language. (Sort of.)
>> 
>> I’ve heard exactly the opposite argument recently. Namely that explicit UnsafePointer construction indicates an “unsafe” cast (I personally don’t agree with that argument though).
>> 
>> Tangential: Which of our current implicit conversions are considered bad? I can’t think of a good alternative, particularly for String/Array to UnsafePointer.
> 
> String/Array to UnsafePointer can't be safely expressed in the language right now without the lifetime-extending wrapper closure, so I feel less bad about those. Inout-to-pointer conversions don't feel implicit because of the '&'.

These conversions are also geared toward interop with well-behaved C APIs, and have caused problems when they fire in unwanted contexts (for example, [] - [] ends up taking the pointer difference of the two arrays' buffers). We've discussed limiting those conversions in particular to imported APIs for these reasons.

> 
> For other conversions, the remaining implicit value-to-reference bridging conversion is up for review, and we've talked about tightening up when implicit optional wrapping can occur. IUOs are out of the type system, which is probably as far as they'll go. I think subclass-to-superclass and covariant function pointer conversions are likely to stay as is, though.
> 
> I think converting initialization from UnsafeMutablePointer<T> to UnsafePointer<T> is always safe, but all the other initializers may need to grow a label (under our rules). That doesn't mean there should be an implicit conversion for it, as convenient as it may be.
> 
> (The counter-movement is people who want implicit conversions from smaller to larger integer and floating-point types, so the tide may shift here.)

Yeah, UnsafeMutablePointer to UnsafePointer conversion feels to me like it fits in the same bucket of "safe" conversions as Int8-to-Int16 etc. There's a well-behaved unidirectional subtype-ish relationship between the types, so many of the problems with ad-hoc user-defined implicit conversions don't apply.

-Joe