<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 4:30 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">As far as I understand it, the Rust Dream™ is one day being able to pass around classes and certain other types without the overhead of ARC, thanks to compile-time borrow checking. This would be handy for resource-constrained platforms and performance critical use cases.</div></div></blockquote><div><br class=""></div><div>I see. This would, I assume, provide the ‘correct’ approach in situations where I’m using inout now.</div><div><br class=""></div><div>I hope Swift gets this.</div><div><br class=""></div><div>—CK</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">In order to support this sort of feature we'd probably need to be able to annotate parameters to functions (like 'inout') to indicate e.g. whether 'ownership' of a variable opting into this system is being transferred or not. Rust's system is described here: <a href="https://doc.rust-lang.org/book/ownership.html" class="">https://doc.rust-lang.org/book/ownership.html</a></div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 29, 2016 at 4:22 PM, Charles Kissinger via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 3:50 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">The great advantages are:</div><div class=""><br class=""></div><div class="">1. It removes a potentially confusing overlap with C-style expectations. People see & and think "POINTERS!", which is not how things work in Swift with copy-back.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, I’ve seen the argument. I just don’t have any idea if that leads to any bad developer decisions.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">(2. It eventually frees up &, so we can have more Rust)</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I’m just going to go ahead and assume that’s a good thing.</div><div class=""><br class=""></div><div class="">—CK</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">-- E</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 4:42 PM, Charles Kissinger <<a href="mailto:crk@akkyra.com" target="_blank" class="">crk@akkyra.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Sorry, I wasn’t clear at all there. I was thinking of the most common case where there is either only one parameter or the inout parameter is the first one. Then there will typically be no argument label involved at the call site. In that case ‘inout’ will be the first word inside the parens at the call site (assuming it replaces ‘&’). If it also is kept in its current position in function declarations, it will be in that same leading position in declarations and (I’m assuming) people will have an easy time remembering where to put it.<div class=""><div class=""><br class=""></div><div class="">When there is a label involved, it is a different story. I was implicitly, and probably wrongly, assuming that would be a much less common case in practice. A poorly worded, and probably poorly reasoned, argument on my part, though I still don’t see any great advantage to replacing ‘&'.</div><div class=""><br class=""></div><div class="">—CK</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 2:13 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 3:04 PM, Charles Kissinger <<a href="mailto:crk@akkyra.com" target="_blank" class="">crk@akkyra.com</a>> wrote:</div><div class=""><div style="word-wrap:break-word" class=""><div class="">The related idea of replacing ‘&’ with ‘inout’ at the call site seems completely contradictory to this proposal. Developers would then have to remember that the ‘inout’ goes before the argument at the call site but after it in the function definition. That seems like a constant source of mis-typings and something that would be viewed as an inconsistency in the language. Or do people want to put it after the argument name at the call site too? It seems a little like change just for the sake of change, IMO.<br class=""></div></div></div></blockquote><br class=""></div><div class="">If you have a function</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">f(x: Int) {}</font></div><div class=""><br class=""></div><div class="">you call it with f(8), and potentially f(x: 8). Even when labeled, the 8 value is to the right of the colon.</div><div class=""><br class=""></div><div class="">Now consider</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">f(x: inout Int) {}</font></div><div class=""><br class=""></div><div class="">you call it with f(&y) or f(inout y), and with a label, you'd call it f(x: &y) or f(x: inout y).</div><div class=""><br class=""></div><div class="">It seems consistent to me.</div><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></span></div><br class=""></div><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="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>