Very cool... Couple thoughts
UnsafeMutableRawPointer: func store<T>(, WITH: T) does not flow very well Fill:with: seems nicer or write(, from:T) which means changing 'load' into 'read' func read<T>(_ : T.Type) -> T func write<T>(_: T.T.Type, from: T) (write even match the method doc) UnsafeRawPointer.toType(): Should it nit be something like typed(as:) instead Regards LM (From mobile) > On Jun 24, 2016, at 3:40 AM, 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
