> On Jun 24, 2016, at 7:43 PM, Andrew Trick <atr...@apple.com> wrote: > > >> 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.
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@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
