[swift-evolution] [Draft] UnsafeRawPointer API

L. Mihalkovic laurent.mihalkovic at gmail.com
Fri Jun 24 00:10:27 CDT 2016

Very cool...

Couple thoughts

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)

Should it nit be something like typed(as:) instead 

(From mobile)

> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list