[swift-evolution] SE-184 Improved Pointers

[Andrew Trick]

> On Aug 19, 2017, at 5:33 PM, Taylor Swift <kelvin13ma at gmail.com> 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 hundred places in the stdlib that use this default value.

Alright, I could agree to that if no one else wants to weigh in. As long as you remove the default from the memory binding API.

-Andy

> On Sat, Aug 19, 2017 at 6:02 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
> 
>> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> 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 <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/de9f6906/attachment.html>