Awesome changes! Thanks for working on this. The final section address all the concerns that I was having while reading which is really interesting for a proposal of this kind. I’m glad to see improvements on this part of the API. I pointed out a minor typo on twitter, sorry didn’t saw this thread before ;) https://twitter.com/alexito4/status/746420742661771265
Can’t wait to see be able to use this ;) Cheers, On Fri, Jun 24, 2016 at 8:38 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Jun 24, 2016, at 1:27 PM, John McCall <rjmcc...@apple.com> wrote: > > On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution > <swift-evolution@swift.org> wrote: > > On Jun 24, 2016, at 8:19 AM, Matthew Johnson <matt...@anandabits.com> 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 > <swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Alejandro Martinez http://alejandromp.com _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution