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 19, 2017 at 6:02 PM, Andrew Trick <[email protected]> wrote: > > 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 > > On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <[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> >> >> *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]> >> 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/propos >>> als/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
