> On Aug 8, 2017, at 5:49 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > > On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick <atr...@apple.com > <mailto:atr...@apple.com>> wrote: > >> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution >> <swift-evolution@swift.org <mailto: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 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>> > > > Excellent. Thanks for patiently iterating on this. I know it's time consuming. > > > add a default value of 1 to all size parameters on > > UnsafeMutablePointer and applicable size parameters on > > UnsafeMutableRawPointer > > I'm generally ok with this if you have seen the benefit of it in real > code. However, I do not think any `repeating:` methods should have a > default count. > > Actually, i believe initialize(to:count:) is currently the one method that > already has a default count. That’s probably because the standard library > calls this method with a count argument of 1 more than any other memorystate > method. I don’t know if this decision was only made for the sake of the > stdlib or if it had an API justification.
Right you are. I had just noticed that none of the other `repeating` APIs had a default. But if this default argument simplifies real code patterns then I’m fine with it. > > 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: > MemoryLayout<UInt>.alignment)` > > If anyone reading the code is unsure about the Swift API's alignment > guarantee, it's trivial to check the API docs. > > You could introduce a clearly documented default `alignedTo` > argument. The reason I didn't do that is that the runtime won't > respect it anyway. But I think it would be fair to go ahead with the > API and file a bug against the runtime. > > Default argument of MemoryLayout<Int>.alignment is the way to go but as you > said i don’t know if that is actually allowed/works. An alternative is to > have two allocate methods each, one that takes an alignment argument and one > that doesn’t (and aligns to pointer alignment) but that feels inelegant. > Default arguments would be better. Default argument makes sense to me too. Then the raw buffer pointer and regular raw pointer APIs can be consistent with each other. Runtime bug: https://bugs.swift.org/browse/SR-5664 > > and initializeMemory<Element>(as:at:repeating:count:), > > initializeMemory<Element>(as:from:count:) > > moveInitializeMemory<Element>(as:from:count:), and > > bindMemory<Element>(to:count:) to UnsafeMutableRawBufferPointer > > I think you should move the raw pointer changes to a separate bullet point. > > Presumably the raw buffer capacity must match or exceed count * stride? > > -Andy > > The reason the raw buffer pointers don’t fill in their own size is the > destination type might not line up with the raw buffer size, and then there’s > questions of rounding and whatnot. bindMemory(to:count:) would also have to > perform integer division or some other defined behavior. Though if people > think computing the strided count inside the buffer pointer method is the > right way to go, I’m open to that. No, I think your API is fine. I just wanted to clarify that we will trap if the raw buffer is too small to fit the requested elements. -Andy
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
