Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 4:53 PM, Andrew Trick wrote: > > >> On Jun 23, 2016, at 6:40 PM, Andrew Trick via swift-evolution >> wrote: >> >> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md > > Would anyone like to bikeshed the allocation API? Here ar

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 28, 2016, at 6:54 PM, Dmitri Gribenko wrote: > > On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick wrote: >> >>> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko wrote: >>> >>> Hi Andy, >>> >>> Everything is clear now, thank you! >>> >>> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrot

Re: [swift-evolution] [Draft] UnsafeRawPointer API

On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick wrote: > >> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko wrote: >> >> Hi Andy, >> >> Everything is clear now, thank you! >> >> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote: >>> Initializing via a typed pointer, in addition to changing the temp

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko wrote: > > Hi Andy, > > Everything is clear now, thank you! > > On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote: >> Initializing via a typed pointer, in addition to changing the temporal >> memory state, also imposes a type on the allocated

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Hi Andy, Everything is clear now, thank you! On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick wrote: > Initializing via a typed pointer, in addition to changing the temporal memory > state, also imposes a type on the allocated memory for the entire lifetime of > the memory itself, from allocation

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 10:18 PM, Dmitri Gribenko wrote: > > Hi Andy, > > Thank you for the proposal! A few comments from me. Thanks for the feedback (again)! I updated the language in the proposal (again). > - In the "Custom memory allocation section" you write: > >> Note: The same allocated

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 3:27 PM, Dave Abrahams wrote: >> >> Any gripes about this syntax? >> >> let ptrB = UnsafeRawPointer(ptrA).cast(to: UnsafePointer.Type) > > Aside from the fact that it doesn't compile? (s/Type/self/) ;-) Sorry, I keep converting between decl/use style and forgetting to up

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:25 AM, Dave Abrahams wrote: > > >> on Mon Jun 27 2016, "L. Mihalkovic" wrote: >> >> Regards >> (From mobile) >> >>> On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: >>> >>> >>> on Fri Jun 24 2016, Andrew Trick wrote: >>> > On Jun

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Hi Andy, Thank you for the proposal! A few comments from me. - In the "Custom memory allocation section" you write: > Note: The same allocated raw memory cannot be used both for this custom > memory allocation case and for the C buffer case above because the C buffer > requries that the alloc

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:18 AM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic >>> wrote: >>> >>> think you mean T.Type, not T.self, because this looks like a declaration. >>> >>> To evaluate, you have to look at the use-site: >>> >>> l

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: >> On Jun 27, 2016, at 7:15 PM, Dave Abrahams wrote: >> >> >> >> Sent from my moss-covered three-handled family gradunza > >> >> On Jun 27, 2016, at 4:27 PM, Andrew Trick > > wrote: >> >>> On Jun 27, 2016, at 3:35 PM, D

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 7:15 PM, Dave Abrahams wrote: > > > > Sent from my moss-covered three-handled family gradunza > > On Jun 27, 2016, at 4:27 PM, Andrew Trick > wrote: > >> >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams >> > wrote: >>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my moss-covered three-handled family gradunza > On Jun 27, 2016, at 4:50 PM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 4:27 PM, Andrew Trick via swift-evolution >>> wrote: >>> >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams wrote: Casting from a raw pointer

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my moss-covered three-handled family gradunza > On Jun 27, 2016, at 4:27 PM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams wrote: >>> >>> Casting from a raw pointer to a typed pointer is only more dangerous >>> than other raw pointer operations because it

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 23, 2016, at 6:40 PM, Andrew Trick via swift-evolution > wrote: > > https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md Would anyone like to bikeshed the allocation API? Here are two options with a slight stylistic difference: # Option 1: e

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 4:27 PM, Andrew Trick via swift-evolution > wrote: > > >> On Jun 27, 2016, at 3:35 PM, Dave Abrahams > > wrote: >> >>> Casting from a raw pointer to a typed pointer is only more dangerous >>> than other raw pointer operations because it is the

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 3:35 PM, Dave Abrahams wrote: > >> Casting from a raw pointer to a typed pointer is only more dangerous >> than other raw pointer operations because it is the first step in this >> sequence of operations, which is undefined: >> >> ptrA = rawPtr.cast(to: UnsafePointer.self)

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 3:27 PM, Dave Abrahams wrote: > > Aside from the fact that it doesn't compile? (s/Type/self/) ;-) Sorry, I keep converting between decl/use style and forgetting to update that. > No gripes. I think I suggested it. I was responding to LM, and the rest of the list… Andy

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: > I agree, this syntax works best, all considered: > > UnsafeRawPointer.cast(to: UnsafePointer.Type) > >> On Jun 26, 2016, at 11:39 PM, Dave Abrahams wrote: >> is better. But I hate that the language doesn't give us a way to say >> “don't deduce generic

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: >> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic >> wrote: >> >> think you mean T.Type, not T.self, because this looks like a declaration. >>> >>> To evaluate, you have to look at the use-site: > >>> >>> let p = UnsafePointer(r, to: Int.self) >>> >>>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, "L. Mihalkovic" wrote: > Regards > (From mobile) > >> On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: >> >> >> on Fri Jun 24 2016, Andrew Trick wrote: >> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution wrote: > On Jun 24, 2016, at 11

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic > wrote: > > think you mean T.Type, not T.self, because this looks like a declaration. >> >> To evaluate, you have to look at the use-site: >> >> let p = UnsafePointer(r, to: Int.self) >> >> I don't find “to” to be descriptive enough. Maybe >

Re: [swift-evolution] [Draft] UnsafeRawPointer API

I agree, this syntax works best, all considered: UnsafeRawPointer.cast(to: UnsafePointer.Type) > On Jun 26, 2016, at 11:39 PM, Dave Abrahams wrote: > is better. But I hate that the language doesn't give us a way to say > “don't deduce generic parameters here.” This is the only syntax that > f

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards (From mobile) > On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: > > > on Fri Jun 24 2016, Andrew Trick wrote: > >>> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution >>> wrote: >>> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic >>>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Fri Jun 24 2016, Andrew Trick wrote: >> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution >> wrote: >> >>> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic >>> >> > wrote: >>> >>> I like the watch-what-you-wish-for warning of unsafeCast. >> >>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 23, 2016, at 6:40 PM, Andrew Trick via swift-evolution > 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 pro

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution > wrote: > >> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic > > wrote: >> >> I like the watch-what-you-wish-for warning of unsafeCast. > > I’ll try porting stdlib to the “UnsafeRawPointer.unsaf

Re: [swift-evolution] [Draft] UnsafeRawPointer API

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

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my iPad > On Jun 24, 2016, at 1:27 PM, John McCall wrote: > >>> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution >>> wrote: >>> On Jun 24, 2016, at 8:19 AM, Matthew Johnson wrote: >>> >>> Andrew, thank you for working on this. The latest draft is much improved! >>>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my iPad > On Jun 24, 2016, at 12:58 PM, Andrew Trick wrote: > > >> On Jun 24, 2016, at 8:19 AM, Matthew Johnson 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 t

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution > wrote: >> On Jun 24, 2016, at 8:19 AM, Matthew Johnson > > wrote: >> >> Andrew, thank you for working on this. The latest draft is much improved! >> >> I have a few questions. >> >> Why do you re

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic > wrote: > > I like the watch-what-you-wish-for warning of unsafeCast. I’ll try porting stdlib to the “UnsafeRawPointer.unsafeCast(to: T.Type)” syntax and see how bad it is. > I think it was really brilliant to introduce the extra step... basical

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 7:43 PM, Andrew Trick wrote: > > >> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic >> wrote: >> >> Very cool... >> >> Couple thoughts >> >> UnsafeMutableRawPointer: >> func store(, WITH: T) >> does not flow very well >> Fill:with: seems nicer or write(, from:T) which mea

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 8:19 AM, Matthew Johnson 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.Type, with: T, count: Int = 1) ->

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic > wrote: > > Very cool... > > Couple thoughts > > UnsafeMutableRawPointer: > func store(, WITH: T) > does not flow very well > Fill:with: seems nicer or write(, from:T) which means changing 'load' into > 'read' > func read(_ : T.Type) -> T > func

Re: [swift-evolution] [Draft] UnsafeRawPointer API

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.Type, with: T, count: Int = 1) -> UnsafeMutablePointer func initialize(toContiguous: T.Type, atIndex: Int,

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Very cool... Couple thoughts UnsafeMutableRawPointer: func store(, WITH: T) does not flow very well Fill:with: seems nicer or write(, from:T) which means changing 'load' into 'read' func read(_ : T.Type) -> T func write(_: T.T.Type, from: T) (write even match the method doc) UnsafeRawPointer.to

[swift-evolution] [Draft] UnsafeRawPointer API

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