> 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.

swift-evolution mailing list

Reply via email to