[swift-users] Why does the withUnsafeMutableBufferPointer closure take an inout parameter?

[Geordie Jay]

Chris Lattner <clattner at nondot.org> schrieb am Sa. 14. Okt. 2017 um 05:18:

>
> On Oct 13, 2017, at 7:40 PM, Andrew Trick via swift-users <
> swift-users at swift.org> wrote:
>
>
>
> On Oct 12, 2017, at 3:52 AM, Geordie Jay via swift-users <
> swift-users at swift.org> wrote:
>
>
> Guillaume Lessard via swift-users <swift-users at swift.org> schrieb am Mi.
> 11. Okt. 2017 um 23:49:
>
>> A lot of the MutableCollection implementation is in protocol extensions
>> (swapAt, for example.)
>>
>> Should an additional version be written just for the Unsafe*BufferPointer
>> types?
>
>
> Makes sense to me, given the examples above. It doesn’t seem to be a high
> priority task though, and one one suited to a contributor pull request
> rather than taking resources away from the core team.
>
> Would this kind of change need to go through swift evolution or is it a
> “no brainer”?
>
> Geordie
>
>
> I’ll just point out that it’s already the case that methods defined in
> Unsafe*BufferPointer that write to memory are “nonmutating”. So I think
> it’s both a “no brainer” and needs to go through evolution.
>
>
> I’m not familiar with the specifics of this “proposal” but if it really is
> just moving something obvious from being a mutating member to a nonmutating
> member, then I’m sure the core team can find a fast-path way to accept it
> without a formal review period.
>

I’m not 100% sure either tbh, although I can imagine putting in a PR for it
once i understand it.

The issue with changing .swapTo (et al.?) to nonmutating is that
semantically it really is a mutation. But pointers as collections have
different mutation semantics to other collections: Mutating an Array’s
storage is the same as mutating its value, whereas a pointer’s value is its
address, not its storage.

Making the Unsafe*Pointer MutableCollection methods themselves nonmutating
probably wouldn’t be a source-breaking change (it’d just lower the “bar of
entry” to include let constant instances too). I imagine this is
noncontroversial.

The original question though was about why .withUnsafeMutableBufferPointer
takes a closure whose first argument is an **inout**
UnsafeMutableBufferPointer, implying that its base address could legally be
mutated. This was probably done to ease use of MutableCollection methods
given the var parameter. That would no longer be necessary given the first
change.

But removing the inout attribute would be source-breaking. And maybe people
really are moving around the array storage’s base address? This seems like
a very bad idea to me but it’s currently part of that API contract. In any
case this change would need to go through evolution, right?

- Geordie


> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20171014/8e7c7c52/attachment.html>