[swift-evolution] [Draft] UnsafeRawPointer API

[L. Mihalkovic]

> On Jun 24, 2016, at 7:43 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>> 
>> 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)
> 
> Yes but...
> 
> - I was parrotting the current initialize(_: T.Type, with: T) style.
> 
> - I was trying to establish consistency that `from` is used to copy from a pointer which points to a range of elements.
> 
> - Doesn't `fill` imply assigning a range of elements? That would make sense for `storeRaw(contiguous:)` but not the others.
> 
> - `store` by itself may imply assignment. Any previous value will not be destroyed (we don't even know its type). The user needs to be aware of this, at the expense of awkward naming. Safety is more important than convenience here. Hence we need `storeRaw` or `storeBits`. There is a deliberate assymetry between store and load because `load` will initialize its returned value. `store` will not initialize the stored value. `initialize` should be used for that.
> 
> - `writeRaw` sounds a little weird. `writeBits` sounds better.

all makes sense.

>> UnsafeRawPointer.toType():
>> Should it nit be something like typed(as:) instead
> 
> I like "typed(as:)" better than toType(_). I'm debating whether it should be:
> "unsafeCast(toType:)". It's a clarity/safety vs. verbosity tradeoff.

I like the watch-what-you-wish-for warning of unsafeCast.

I think it was really brilliant to introduce the extra step... basically echos the alloc/init dichotomy of objc, so it should feel familiar to people with this bkgnd

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