> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution
> <[email protected]> wrote:
>> On Jun 24, 2016, at 8:19 AM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> 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.
One major problematic case: the value could have a defaulted type, e.g.:
pointer.initialize(with: 0, count: 1024)
John.
>
>> 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
>>> <[email protected] <mailto:[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
>>>
>>> <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
>>>
>>> <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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
