Re: [swift-evolution] SE-184 Improved Pointers

done: https://github.com/apple/swift-evolution/pull/744 On Wed, Aug 23, 2017 at 1:56 PM, Andrew Trick wrote: > Kelvin, > > Please resubmit a clean swift-evolution PR now. I personally think this is > ready for formal review given that all feedback was positive and all issues > brought up during

Re: [swift-evolution] SE-184 Improved Pointers

Kelvin, Please resubmit a clean swift-evolution PR now. I personally think this is ready for formal review given that all feedback was positive and all issues brought up during review have been addressed. -Andy > On Aug 22, 2017, at 12:59 PM, Michael Ilseman wrote: > > This is an excellent,

Re: [swift-evolution] SE-184 Improved Pointers

This is an excellent, thoroughly thought out, and well written proposal! I’m eager to see these improvements land. > On Aug 22, 2017, at 11:33 AM, Taylor Swift wrote: > > > > On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick > wrote: > >> On Aug 21, 2017, at 10:59 PM,

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick wrote: > > On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of >> `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the >> typical use case and doesn't appear

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of > `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the typical > use case and doesn't appear to solve any important use case. The *only* fully > i

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:00 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > >> >> On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: >> >> New draft of the proposal is up here: >

Re: [swift-evolution] SE-184 Improved Pointers

On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > > On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md> > > Important changes start here >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: > > > > >

Re: [swift-evolution] SE-184 Improved Pointers

ps the implementation in pr 11464 has been updated with documentation comments and changes in the latest version of the proposal On Mon, Aug 21, 2017 at 9:19 PM, Taylor Swift wrote: > > > On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman > wrote: > >>

Re: [swift-evolution] SE-184 Improved Pointers

On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman wrote: > > On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: swift-e

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 21, 2017, at 3:11 PM, Michael Ilseman wrote: > >> >> I can’t defend breaking existing source without having seen real code that >> was actually written incorrectly. I don’t see the downside of using the same >> deprecation strategy as the other changes. I expect code that was already

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution > wrote: > > >> On Aug 20, 2017, at 6:03 PM, Taylor Swift > > wrote: >> >> New draft of the proposal is up here: >>

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: > > > > >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 20, 2017, at 7:25 PM, Taylor Swift wrote: > > a method like `buffer.segment(0 ..< 5)` or something which would avoid > constructing the slice type (and save typing that long > `UnsafeMutableBufferPointer(rebasing:)` name) like that would be nice . but > that’s just sugar and not very

Re: [swift-evolution] SE-184 Improved Pointers

On Sun, Aug 20, 2017 at 10:18 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 9:12 PM, Taylor Swift wrote: > >> >> and the other methods should take both an *offset* parameter instead of >> a count parameter: >> >> initialize(from:at:) >> assign(from:at:) >> moveInitialize(from:at:) >> moveAssig

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 19, 2017, at 9:12 PM, Taylor Swift wrote: > >> and the other methods should take both an offset parameter instead of a >> count parameter: >> >> initialize(from:at:) >> assign(from:at:) >> moveInitialize(from:at:) >> moveAssign(from:at:) >> >> which provides maximum explicitness. Thi

Re: [swift-evolution] SE-184 Improved Pointers

New draft of the proposal is up here: < https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md > Important changes start here . On Sun, Aug 20, 20

Re: [swift-evolution] SE-184 Improved Pointers

actually never mind that, UnsafeMutablePointer should be the only type to not support at: arguments since offsetting them is easy with +. > On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution > wrote: > > > >> On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: >> >>> On Aug 1

Re: [swift-evolution] SE-184 Improved Pointers

How disruptive would it be to move the `at:` parameter in ` UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)` to a method in ` UnsafeMutableRawBufferPointer`? (raw_ptr + 16).initializeMemory(as: UInt64.self, from: source, count: 5) instead of raw_ptr.initializeMemory(as: UInt64.self, at

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > >> >> On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: >> >> What you’re describing is basically an earlier version of the p

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick > wrote: > >> On Aug 19, 2017, at 6:16 PM, Taylor Swift > > wrote: >> >> What you’re describing is basically an earlier version of t

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal > which had a slightly weaker precondition (source >= destination) than yours > (source == destination). That one b

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal which > had a slightly weaker precondition (source >= destination) than yours (source > == destination). That one basically ignored the Sequence methods at the > expen

Re: [swift-evolution] SE-184 Improved Pointers

What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area. On Sat, Aug 19, 2017 at 9:08 PM, A

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 19, 2017, at 5:33 PM, Taylor Swift wrote: > > I agree it’s probably a bad idea to add the default arg to those two > functions. However, the default argument in initialize(repeating:count:) is > there for backwards compatibility since it already had it before and there’s > like a hun

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 19, 2017, at 6:03 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick > wrote: >>> >>> The problem is I would expect to be able to safely call deinitialize() and >>> friends after calling initialize(from:). If Element is a class ty

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick wrote: > >> The problem is I would expect to be able to safely call deinitialize() >> and friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling deinitialize() >> will crash.

Re: [swift-evolution] SE-184 Improved Pointers

>> >> The problem is I would expect to be able to safely call deinitialize() and >> friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling deinitialize() will >> crash. That being said, since copy(from:bytes:) and copy

Re: [swift-evolution] SE-184 Improved Pointers

I agree it’s probably a bad idea to add the default arg to those two functions. However, the default argument in initialize(repeating:count:) is there for backwards compatibility since it already had it before and there’s like a hundred places in the stdlib that use this default value. On Sat, Aug

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 6:05 PM, Andrew Trick wrote: > > On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: >> >>> >>>

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 11:10 PM, Taylor Swift > > wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution > wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > > > On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift > wrote: > I’ve revised

Re: [swift-evolution] SE-184 Improved Pointers

Added those methods to the implementation and updated the proposal document. On Fri, Aug 18, 2017 at 11:42 PM, Andrew Trick wrote: > > On Aug 18, 2017, at 5:36 PM, Taylor Swift wrote: > > Should the immutable bu

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 18, 2017, at 5:36 PM, Taylor Swift wrote: > > Should the immutable buffer pointer types also get deallocate()? Both UnsafePointer and UnsafeBufferPointer should get deallocate. The Raw API already has those methods. -Andy > On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick

Re: [swift-evolution] SE-184 Improved Pointers

Should the immutable buffer pointer types also get deallocate()? On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution > wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > > > On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift > wrote: > I’ve revised

Re: [swift-evolution] SE-184 Improved Pointers

Implementation is here: https://github.com/apple/swift/pull/11464 On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift wrote: > I’ve revised the proposal based on what I learned from trying to implement > these changes. I think it’s worth tacking the existing methods that take > Sequences at the same t

Re: [swift-evolution] SE-184 Improved Pointers

I’ve revised the proposal based on what I learned from trying to implement these changes. I think it’s worth tacking the existing methods that take Sequences at the same time as this actually makes the design a bit simpler. *The p

Re: [swift-evolution] SE-184 Improved Pointers

okay so I’m implementing this rn, and i just realized that the functions UnsafeMutableRawBufferPointer.initializeMemory(as:from:count:) and UnsafeMutableRawBufferPointer.moveInitializeMemory(as:from:count:) are gonna be a problem. Since they take a strided buffer

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: >> >> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cann

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 8:44 PM, Taylor Swift > > wrote: >> >> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot > find such a function anywhere in the API. There is copyBytes(from:) >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find > such a function anywhere in the API. There is copyBytes(from:) >

Re: [swift-evolution] SE-184 Improved Pointers

cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find such a function anywhere in the API. There is copyBytes(from:) , but the documentation is messed up and mentions a nonexisten

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 8:29 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 6:51 PM, Taylor Swift > > wrote: >> >> >> >> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick >

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 6:51 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > >> >> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >>> >>> Well, I think it's somewhat ridiculous for users to wri

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 6:51 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick > wrote: > >> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >> >> Well, I think it's somewhat ridiculous for users to write this every time >> they a

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > > > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >> >> Well, I think it's somewhat ridiculous for users to write this every time >> they allocate a buffer: >> >> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: >> Me

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 5:49 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Since Swift 5 just got opened up for

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers > is ready for community review, and I encourage everyone to look

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution > wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is > ready for community review, and I encourage everyone to look it over and > provide feedback. Thank you! >

Re: [swift-evolution] SE-184 Improved Pointers

This is an excellent document that demonstrates great care and attention. It addresses pain points discovered through real-world use by a minimum of well-justified API changes. The motivating example is compelling, and my only suggestion there is to show a before-and-after comparison of how the pr

Re: [swift-evolution] SE-184 Improved Pointers

> On 8 Aug 2017, at 17:53, Taylor Swift via swift-evolution > wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is > ready for community review, and I encourage everyone to look it over and > provide feedback. Thank you! >

[swift-evolution] SE-184 Improved Pointers

Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you! < https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md >