> On May 4, 2016, at 10:07, Andrew Trick <[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. (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
