Sent from my iPad
> On Jun 24, 2016, at 12:58 PM, Andrew Trick <[email protected]> wrote: > > >> On Jun 24, 2016, at 8:19 AM, Matthew Johnson <[email protected]> wrote: >> >> Andrew, thank you for working on this. The latest draft is much improved! >> >> I have a few questions. >> >> Why do you require explicitly passing the type in these signatures? >> >> func initialize<T>(_: T.Type, with: T, count: Int = 1) -> >> UnsafeMutablePointer<T> >> func initialize<T>(toContiguous: T.Type, atIndex: Int, with: T) -> >> UnsafeMutablePointer<T> >> func storeRaw<T>(_: T.Type, with: T) >> func storeRaw<T>(toContiguous: T.Type, atIndex: Int, with: T) >> >> There is probably a good reason, but it seems redundant at first glance and >> isn’t obvious from my reading of the proposal. The alternatives would be >> something like this: >> >> func initialize<T>(with: T, count: Int = 1) -> UnsafeMutablePointer<T> > > Good question. It is deliberately, and unfortunately redundant. We're trading > convenience for safety. I added this note to the proposal: > > Note that the `T.Type` argument on `initialize` is redundant because > it may be inferred from the `with` argument. However, relying on type > inferrence at this point is dangerous. The user needs to ensure that > the raw pointer has the necessary size and alignment for the > initialized type. Explicitly spelling the type at initialization > prevents bugs in which the user has incorrectly guessed the inferred > type. I suspected it was something like this. Thanks for explaining and updating the proposal! > >> The parameter order in this signature is the opposite of the order in >> UnsafeMutablePointer. Is that intentional? If so, what is the rationale? >> You might want to elaborate this in the proposal. >> >> public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer > > Fixed. > >> Shouldn’t the precondition be that memory for all elements is >> *uninitialized* / *deinitialized* in this example? >> >> // - precondition: memory for all elements is initialized. >> func freeCBuffer() { >> UnsafeRawPointer(ptrToA).deallocate(capacity: eltCount, of: A.self) >> } > > Typo. Thanks! > >> It looks like there is a type in this example: >> >> var anyT = T(...) >> takesTPtr(&anyT) >> takesVoidPtr(&any) >> >> Should the last line say `&anyT`? > > Typo. Thanks! > > -Andy > >> Other than these few questions all I can say is that this looks great! I >> believe it will add important clarity to code that works with unsafe >> pointers. >> >> -Matthew >> >>> On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution >>> <[email protected]> wrote: >>> >>> I sent two RFC's for this proposal over the past couple months (see Early >>> swift-evolution threads). High-level feedback was fairly light. This >>> version is a final draft, as I expect it to go through the review process >>> next week. There is a lot more explanation and detail in this proposal now, >>> and the memory model has been simplified and clarified. >>> >>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md >>> >>> If you have opinions or suggestions on API syntax, please make yourself >>> heard. You can jump straight to the naming discussion here: >>> >>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md#variations-under-consideration >>> >>> Of particular interest may be the API names for: >>> >>> - Memory allocation/deallocation: fairly fundamental to the language. >>> >>> - Unsafe casting from raw pointers to typed pointers. This is going to >>> impact a lot of code that needs C interoperability. >>> >>> Keep in mind that we will make additive API improvements later for >>> convenience. We want the fundamentals to be clear, explicit, and reasonably >>> safe. >>> >>> -Andy >>> >>> <XXXX-unsaferawpointer.md>_______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
