<div><div><div class="gmail_quote"><div dir="auto">Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> schrieb am Sa. 14. Okt. 2017 um 05:18:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Oct 13, 2017, at 7:40 PM, Andrew Trick via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_-2342244228468880348m_-5562088499276197478Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Oct 12, 2017, at 3:52 AM, Geordie Jay via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_-2342244228468880348m_-5562088499276197478Apple-interchange-newline"><div><div><br><div class="gmail_quote"><div dir="auto">Guillaume Lessard via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> schrieb am Mi. 11. Okt. 2017 um 23:49:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A lot of the MutableCollection implementation is in protocol extensions (swapAt, for example.)<br>
<br>
Should an additional version be written just for the Unsafe*BufferPointer types?</blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Would this kind of change need to go through swift evolution or is it a “no brainer”?</div><div dir="auto"><br></div><div dir="auto">Geordie</div></div></div></div></blockquote><br></div><div>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.</div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div dir="auto"><br></div></div></div></div><div><div class="gmail_quote" dir="auto"><div dir="auto">I’m not 100% sure either tbh, although I can imagine putting in a PR for it once i understand it.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">The original question though was about why .<span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">withUnsafeMutableBufferPointer takes a closure whose first argument is an <b>*inout*</b> 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.</span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)"><br></span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px;background-color:rgb(255,255,255)">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?</span></div><div dir="auto"><br></div><div dir="auto">- Geordie</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div><div><br></div><br></div></blockquote></div></div>