<div dir="ltr"><span style="font-size:14px">+1</span><div style="font-size:14px"><br></div><div style="font-size:14px">have a look with my library: <a href="https://github.com/SusanDoggie/Doggie/tree/master/Doggie/Accelerate" target="_blank">https://github.com/SusanDoggie/Doggie/tree/master/Doggie/Accelerate</a></div><div style="font-size:14px"><br></div><div style="font-size:14px"><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:rgb(187,44,162)">public</span> <span style="color:rgb(187,44,162)">func</span> Add<T: <span style="color:rgb(112,61,170)">IntegerType</span>>(count: <span style="color:rgb(112,61,170)">Int</span>, <span style="color:rgb(187,44,162)">var</span> <span style="color:rgb(187,44,162)">_</span> left: <span style="color:rgb(112,61,170)">UnsafePointer</span><<span style="color:rgb(112,61,170)">T</span>>, <span style="color:rgb(187,44,162)">_</span> left_stride: <span style="color:rgb(112,61,170)">Int</span>, <span style="color:rgb(187,44,162)">var</span> <span style="color:rgb(187,44,162)">_</span> right: <span style="color:rgb(112,61,170)">UnsafePointer</span><<span style="color:rgb(112,61,170)">T</span>>, <span style="color:rgb(187,44,162)">_</span> right_stride: <span style="color:rgb(112,61,170)">Int</span>, <span style="color:rgb(187,44,162)">var</span> <span style="color:rgb(187,44,162)">_</span>output: <span style="color:rgb(112,61,170)">UnsafeMutablePointer</span><<span style="color:rgb(112,61,170)">T</span>>, <span style="color:rgb(187,44,162)">_</span> out_stride: <span style="color:rgb(112,61,170)">Int</span>) {</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> <span style="color:rgb(187,44,162)">for</span> <span style="color:rgb(187,44,162)">_</span> <span style="color:rgb(187,44,162)">in</span> <span style="color:rgb(39,42,216)">0</span>..<count {</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> output.<span style="color:rgb(112,61,170)">memory</span> = left.<span style="color:rgb(112,61,170)">memory</span> <span style="color:rgb(61,29,129)">+</span> right.<span style="color:rgb(112,61,170)">memory</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> left += left_stride</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> right += right_stride</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> output += out_stride</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> }</p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">}</p></div><div class="gmail_extra" style="font-size:14px"><br></div><div class="gmail_extra" style="font-size:14px">There are lots of code moving pointers by modifying the shadow copy of pointer type. This move will add plenty of redundant code lines.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-22 19:26 GMT+08:00 David Farler <span dir="ltr"><<a href="mailto:dfarler@apple.com" target="_blank">dfarler@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone,</div><div><br></div><div>I'd like to reconsider SE-0003 for Swift 3 and propose cancelling the change in its entirety. After collecting feedback since Swift's open source launch, I no longer feel this is a good move and there are a few reasons why.</div><div><br></div><div>There are two main patterns that the removal penalizes:</div><div><br></div><div>- Get-Modify-Reassign</div><div>- Get-Modify-Return</div><div><br></div><div>I've found that many of the problems with this proposal stem from the uses before and after the "Modify" part, before returning or reassigning with the new value.</div><div><br></div><div>I've seen a few common responses to the var removal. Consider a `Rectangle` struct:</div><div><br></div><div><br></div><div>struct Rectangle {</div><div> var origin: (x: Double, y: Double)</div><div> var size: (width: Double, height: Double)</div><div>}</div><div><br></div><div><br></div><div>Even with mutable variables `origin` and `size`, this pattern would be impossible:</div><div><br></div><div><br></div><div>var selection = getRectangularSelection()</div><div>if var rect = selection?.rect {</div><div> // Mutate `rect` ...</div><div> selection.rect = rect</div><div>}</div><div><br></div><div><br></div><div>So, one might shadow the variable, which is not ideal:</div><div><br></div><div><br></div><div>var selection = getRectangularSelection()</div><div>if let rect = selection?.rect {</div><div> var rect = rect // Not so great</div><div> // Mutate `rect` ...</div><div> selection.rect = rect</div><div>}</div><div><br></div><div><br></div><div>Or, you might make a transformation function on `Rect`:</div><div><br></div><div><br></div><div>struct Rectangle {</div><div> var origin: (x: Double, y: Double)</div><div> var size: (width: Double, height: Double)</div><div> func withOrigin(x: Double, y: Double) -> Rect {</div><div> var r = self</div><div> r.origin = (x, y)</div><div> return r</div><div> }</div><div>}</div><div><br></div><div><br></div><div>This is a much better solution than shadowing but you would need one of these for any property that you want to mutate and I think you'll agree that it doesn't scale with the language we have today. This response begs for a kind of initializer that takes all of the fields of the original struct except any that you want to override:</div><div><br></div><div><br></div><div>if let rect = selection?.rect.with(origin: newOrigin) {</div><div> // ...</div><div>}</div><div><br></div><div><br></div><div>Straw syntax, but maybe you'll see something along these lines on swift-evolution in the future, which would provide a clear alternative to direct mutation patterns. Even then, I think having complementary patterns in the language isn't a bad thing.</div><div><br></div><div>These problems come up with the other variable bindings but the one that ended up bothering me the most was `guard var`:</div><div><br></div><div><br></div><div>func transform(selection: Rect?) {</div><div> guard let rect = selection else { return }</div><div> var _rect = rect</div><div> // Mutate `_rect` ...</div><div>}</div><div><br></div><div><br></div><div>One of the guard statement's main purposes is to conditionally bind a value as a peer in its own scope, not an inner scope like if statements. Not having var makes the guard statement much weaker.</div><div><br></div><div>There is certainly a bit of confusion about the nuances between value and reference semantics, who owns a value and when, how effects are propagated back to values, but I think we can attack the problem with more finesse.</div><div><br></div><div>Value types are one of the attractive features of Swift – because of their semantics, mutating algorithms are written in a familiar style but keeping effects limited to your unique reference. I don't think we should give that up now to address confusion about semantics, out of principle, or in anticipation of new language features. I propose cancelling this change for Swift 3 and continue to allow `var` in the grammar everywhere it occurs in Swift 2.2.</div><div><br></div><div>Regards,</div><div>David</div></div>
</blockquote></div><br></div></div>