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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 =

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

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

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 =

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

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

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

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,

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

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

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

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

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

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

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,

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

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,

[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,