> On May 4, 2016, at 10:15 AM, Jordan Rose <[email protected]> wrote: > >> >> On May 4, 2016, at 10:07, Andrew Trick <[email protected]> wrote: >> >>> >>> On May 4, 2016, at 9:40 AM, Jordan Rose <[email protected]> wrote: >>> >>>> >>>> On May 4, 2016, at 09:18, Joe Groff via swift-evolution >>>> <[email protected]> wrote: >>>> >>>>> >>>>> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> On May 3, 2016, at 8:56 PM, Chris Lattner <[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 >>>>>> >>>>>> * 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
