[swift-evolution] [Draft] UnsafeRawPointer API

[Matthew Johnson]

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>



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



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




It looks like there is a type in this example:

var anyT = T(...)
takesTPtr(&anyT)
takesVoidPtr(&any)

Should the last line say `&anyT`?



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/e3404af9/attachment.html>