[swift-evolution] [Draft] UnsafeRawPointer API

[Matthew Johnson]

Sent from my iPad

> On Jun 24, 2016, at 12:58 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Jun 24, 2016, at 8:19 AM, Matthew Johnson <matthew at 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.

I suspected it was something like this.  Thanks for explaining and updating the proposal!

> 
>> 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 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/b87079fe/attachment.html>