> On Aug 19, 2017, at 5:33 PM, Taylor Swift <kelvin1...@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 <atr...@apple.com > <mailto:atr...@apple.com>> wrote: > >> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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 <kelvin1...@gmail.com >> <mailto:kelvin1...@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 <kelvin1...@gmail.com >> <mailto:kelvin1...@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
