> On May 4, 2016, at 10:15 AM, Jordan Rose <[email protected]> wrote: > >> >> On May 4, 2016, at 10:07, Andrew Trick <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On May 4, 2016, at 9:40 AM, Jordan Rose <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On May 4, 2016, at 09:18, Joe Groff via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On May 3, 2016, at 8:56 PM, Chris Lattner <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>> >>>>>> <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 '&'. > > 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.
That’s good to hear. I completely agree that unsafe conversions need to grow a label. Although I still somewhat prefer implicit Mutable to Immutable conversions not only because it is so convenient but because programmers will expect that behavior. It feels to me like we are mimicking a type qualifier. AFAIK it doesn’t introduce implementation complexity or strange corner cases. -Andy > (The counter-movement is people who want implicit conversions from smaller to > larger integer and floating-point types, so the tide may shift here.) > > Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
