<div dir="ltr">Thanks Erica. I just read the post and I still can't help wonder if things are that bad?<div><br></div><div>The post doesn't mention much about C-pointers other than calling inOutParameter parameter a pointer (it isn't) that doesn't need to be dereferenced. It does seem like the compiler helps catch any usage errors as intended. But I don't see how something detrimental, whether in terms of grokking Swift or an unintended usage consequence arises in this scenario.</div><div><br></div><div>- Allen Ding</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 30, 2016 at 8:25 AM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>></span> wrote:<br><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><span class=""><blockquote type="cite"><div>On Jan 29, 2016, at 5:14 PM, Allen Ding <<a href="mailto:allen@snappymob.com" target="_blank">allen@snappymob.com</a>> wrote:</div><br><div><div dir="ltr">1. Is there some data or real world story to support (1)? I've never had the same expectations even when first encountering Swift and definitely less so after reading the documentation, because the concept and syntax for inout and & is not really profound. And even if I did *pointers!*, I would figure things out rather quickly because nothing else would work.</div></div></blockquote><div><br></div></span>Going from personal experience?</div><div><br></div><div><a href="http://ericasadun.com/2015/04/10/swift-var-parameters/" target="_blank">http://ericasadun.com/2015/04/10/swift-var-parameters/</a></div><div><br></div><div>-- E, "professionally dense"</div><span class=""><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>(2. I don't have experience with Rust, so there would need to be some details on why being more Rust like is a good thing :)</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 30, 2016 at 7:50 AM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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>The great advantages are:</div><div><br></div><div>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>(2. It eventually frees up &, so we can have more Rust)</div><span><font color="#888888"><div><br></div><div>-- E</div></font></span><div><div><div><br></div><div><blockquote type="cite"><div>On Jan 29, 2016, at 4:42 PM, Charles Kissinger <<a href="mailto:crk@akkyra.com" target="_blank">crk@akkyra.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">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><div><br></div><div>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><br></div><div>—CK</div><div><br><div><blockquote type="cite"><div>On Jan 29, 2016, at 2:13 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 29, 2016, at 3:04 PM, Charles Kissinger <<a href="mailto:crk@akkyra.com" target="_blank">crk@akkyra.com</a>> wrote:</div><div><div style="word-wrap:break-word"><div>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></div></div></div></blockquote><br></div><div>If you have a function</div><div><br></div><div><font face="Menlo">f(x: Int) {}</font></div><div><br></div><div>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><br></div><div>Now consider</div><div><br></div><div><font face="Menlo">f(x: inout Int) {}</font></div><div><br></div><div>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><br></div><div>It seems consistent to me.</div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div></div>
</div></blockquote></div><br></span></div></blockquote></div><br></div>