[swift-evolution] [Draft] UnsafeRawPointer API

[L. Mihalkovic]

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 <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