[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
find such a function anywhere in the API. There is copyBytes(from:)
<https://developer.apple.com/documentation/swift/unsafemutablerawbufferpointer/2635415-copybytes>,
but the documentation is messed up and mentions a nonexistent count:
argument over and over again. The documentation also doesn’t mention what
happens if there is a length mismatch, so users are effectively relying on
an implementation detail. I don’t know how to best resolve this.

On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick <atrick at apple.com> wrote:

>
> On Aug 8, 2017, at 8:29 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
>
>
> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick <atrick at apple.com> wrote:
>
>>
>> On Aug 8, 2017, at 6:51 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>
>>
>>
>> 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.
>>
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/6aad2a52/attachment.html>