> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic <laurent.mihalko...@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. > 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. -Andy > Regards > LM > (From mobile) > >> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution >> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
