> On Aug 8, 2017, at 8:29 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > > On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick <atr...@apple.com > <mailto:atr...@apple.com>> wrote: > >> On Aug 8, 2017, at 6:51 PM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> >> >> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick <atr...@apple.com >> <mailto:atr...@apple.com>> wrote: >> >>> > 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 >> <https://bugs.swift.org/browse/SR-5664> >> >> yikes i was not aware of this. I don’t think it’s bad enough to warrant >> dropping the argument like with deallocate(capacity:) but I can imagine bad >> things happening to code that crams extra inhabitants into pointers. > > If we ever need to do pointer adjustment during deallocation to accommodate > alignment, then I think the Swift runtime can track that. I see no reason to > muddy the UnsafeRawPointer API with it. So, I agree with your proposed change > to drop `alignedTo` there. > > -Andy > > oh lol I was talking about assuming the pointer returned by > allocate(bytes:alignedTo:) is a multiple of alignedTo. Some code might be > relying on the last few bits of the pointer being zero; i.e. sticking bit > flags there like how some implementations store the red/black color > information in a red-black tree node.
Oh, sure. But I think it will be easy to fix the runtime. We could probably do it before the proposal is accepted if necessary. -Andy
_______________________________________________ swift-evolution mailing list firstname.lastname@example.org https://lists.swift.org/mailman/listinfo/swift-evolution