> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution
> <[email protected]> wrote:
>
> Implementation is here: https://github.com/apple/swift/pull/11464
> <https://github.com/apple/swift/pull/11464>
>
> On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <[email protected]
> <mailto:[email protected]>> 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 time as this actually makes the design a bit simpler.
> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c
> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c>>
>
> The previous version
> <https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907> of this
> document ignored the generic initialization methods on
> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them to
> be overhauled at a later date, in a separate proposal. Instead, this version
> of the proposal leverages those existing methods to inform a more compact API
> design which has less surface area, and is more future-proof since it
> obviates the need to design and add another (redundant) set of
> protocol-oriented pointer APIs later.
>
> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift <[email protected]
> <mailto:[email protected]>> 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!
> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md>>
Thanks for continuing to improve this proposal. It’s in great shape now.
Upon rereading it today I have to say I strongly object to the `count = 1`
default in the following two cases:
+ UnsafeMutablePointer.withMemoryRebound(to: count: Int = 1)
+ UnsafeMutableRawPointer.bindMemory<T>(to:T.Type, count:Int = 1)
-> UnsafeMutablePointer<T>
To aid understanding, it needs to be clear at the call-site that binding memory
only applies to the specified number of elements. It's a common mistake for
users to think they can obtain a pointer to a different type, then use that
pointer as a base to access other elements. These APIs are dangerous expert
interfaces. We certainly don't want to make their usage more concise at the
expense of clarity.
In general, I think there's very little value in the `count=1` default, and it
creates potential confusion on the caller side between the `BufferPointer` API
and the `Pointer` API. For example:
+ initialize(repeating:Pointee, count:Int = 1)
Seeing `p.initialize(repeating: x)`, the user may think `p` refers to the
buffer instead of a pointer into the buffer and misunderstand the behavior.
+ UnsafeMutablePointer.deinitialize(count: Int = 1)
Again, `p.deinitialize()` looks to me like it might be deinitializing an entire
buffer.
If the `count` label is always explicit, then there's a clear distinction
between the low-level `pointer` APIs and the `buffer` APIs.
The pointer-to-single-element case never seemed interesting enough to me to
worry about making convenient. If I'm wrong about that, is there some
real-world code you can point to where the count=1 default significantly
improves clarity?
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
