Sent from my iPad
> On Jun 24, 2016, at 1:27 PM, John McCall <[email protected]> wrote: > >>> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution >>> <[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. > > One major problematic case: the value could have a defaulted type, e.g.: > pointer.initialize(with: 0, count: 1024) Yes, this one crossed my mind. :) It would be more convenient to not have to explicitly pass the type in every case even if we had to explicitly specify it here like 'pointer.initialize(with: Int(0), count: 1024)' but there probably isn't a good way to require it only in cases like this. And given the safety concerns I think the minor inconvenience is very warranted. In any case, it's nice to have the rationale documented in the proposal. > > John. > >> >>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
