<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1.<div class=""><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Richard</div></div>
</div>
<br class=""><div style=""><blockquote type="cite" class=""><div class="">On May 18, 2017, at 01:48, Anders Kierulf via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I want to bring this up one last time in swift-evolution to give this issue a chance to not fall through the cracks. Passing a value to UnsafeRawPointer should not force that method to be mutating. Either the call should not require &, or this use of & should not require the method to be mutating. The workaround of copying to a temporary variable is not viable (see sample project in SR-4649).<br class=""><br class="">Hope there’s some way this issue can be addressed sooner rather than later.<br class=""><br class="">Thanks,<br class=""> Anders Kierulf<br class=""><br class=""><blockquote type="cite" class="">On Apr 20, 2017, at 1:10 PM, Anders Kierulf <<a href="mailto:anders@smartgo.com" class="">anders@smartgo.com</a>> wrote:<br class=""><br class="">Summary: Currently, only mutable values can be passed to UnsafeRawPointer, except for a special case for arrays. That special case should be generalized, allowing any values to be passed to UnsafeRawPointer without using &.<br class=""><br class="">The following code shows the inconsistency in passing values to UnsafeRawPointer:<br class=""><br class="">var varArray = [Int](repeating: 0, count: 6)<br class="">var varTuple = (0, 0, 0, 0, 0, 0)<br class=""><br class="">let letArray = [Int](repeating: 0, count: 6)<br class="">let letTuple = (0, 0, 0, 0, 0, 0)<br class=""><br class="">func get(_ pointer: UnsafeRawPointer, at index: Int) -> Int {<br class=""> let a = pointer.bindMemory(to: Int.self, capacity: 6)<br class=""> return a[index]<br class="">}<br class=""><br class="">// Array can be passed directly, automatically takes address.<br class="">_ = get(varArray, at: 2) // okay<br class="">_ = get(letArray, at: 2) // okay<br class=""><br class="">// When explicitly taking address, can only pass mutable variables.<br class="">_ = get(&varArray, at: 2) // okay, but seems inconsistent<br class="">_ = get(&letArray, at: 2) // fails: & not allowed<br class=""><br class="">// Passing tuple instead of array fails.<br class="">_ = get(varTuple, at: 2) // fails: wrong type<br class="">_ = get(letTuple, at: 2) // fails: wrong type<br class=""><br class="">// Adding & to pass a tuple only works for mutable values. Having to<br class="">// pass the address using & means that any methods calling this must<br class="">// be mutating, even though they don't mutate.<br class="">_ = get(&varTuple, at: 2) // okay, but forces mutating<br class="">_ = get(&letTuple, at: 2) // fails: cannot pass immutable value<br class=""><br class="">Passing a value to an UnsafeRawPointer parameter should not require use of &, as that forces all code calling it to be mutating. Having a special case for array also doesn't make sense, as the idea of UnsafeRawPointer is that we're interpreting that memory content as whatever we want. Logged as SR-4649.<br class=""><br class="">Proposal:<br class="">- Never require & when passing value to UnsafeRawPointer.<br class="">- Always require & when passing value to UnsafeMutableRawPointer.<br class=""><br class="">(Fixed size arrays are still needed, but with this tweak, workarounds can be made to work.)<br class=""><br class="">Anders Kierulf<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>