[swift-evolution] SE-184 Improved Pointers
Taylor Swift
kelvin13ma at gmail.com
Tue Aug 8 20:51:43 CDT 2017
On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick <atrick at 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
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/b46ef132/attachment.html>
More information about the swift-evolution
mailing list