[swift-evolution] [Draft] UnsafeRawPointer API

[Alejandro Martinez]

Awesome changes! Thanks for working on this.
The final section address all the concerns that I was having while
reading which is really interesting for a proposal of this kind.
I’m glad to see improvements on this part of the API.
I pointed out a minor typo on twitter, sorry didn’t saw this thread
before ;) https://twitter.com/alexito4/status/746420742661771265

Can’t wait to see be able to use this ;)
Cheers,


On Fri, Jun 24, 2016 at 8:38 PM, Matthew Johnson via swift-evolution
<swift-evolution at swift.org> wrote:
>
>
> Sent from my iPad
>
> On Jun 24, 2016, at 1:27 PM, John McCall <rjmccall at apple.com> wrote:
>
> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution
> <swift-evolution at swift.org> 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.
>
>
> One major problematic case: the value could have a defaulted type, e.g.:
>   pointer.initialize(with: 0, count: 1024)
>
>
> Yes, this one crossed my mind.  :)
>
> It would be more convenient to not have to explicitly pass the type in every
> case even if we had to explicitly specify it here like
> 'pointer.initialize(with: Int(0), count: 1024)' but there probably isn't a
> good way to require it only in cases like this.   And given the safety
> concerns I think the minor inconvenience is very warranted.  In any case,
> it's nice to have the rationale documented in the proposal.
>
>
> 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
> <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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com