<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><span></span></div><div><div>I can't believe I let it get this far before I began to post regarding these language proposals.</div><div><br></div><div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">What is your evaluation of the proposal?</span></font></li></ul></div></div></blockquote>I like the proposal, and the direction it shows for Swift. I'm particularly fond of the concise nature of the language.</div><div><br></div><div>I wonder specifically whether cases of ivars should be lower or upper case. I tend to think lower case makes more sense in the context of Swift, but I am personally fond of the upper camel case. Perhaps my eyes have just grown accustomed?</div><div><br></div><div>I am particularly in favour of the sort() vs sorted() verb vs noun. I definitely see the points raised and acknowledge that the subtleties of language mean there will always be exceptions to rules where it doesn't make sense, and I think the "inPlace" wording makes sense to fill this gap.</div><div><br></div><div>I'm personally not a fan of the strong guidance to eliminate initial argument labels. I find this somewhat of a holdover from the awkward translation of Obj-C APIs, and I think there are cases where the initial parameter makes sense to be named. The login example, while it has its flaws, makes some sense here.</div><div><br></div><div>loginWithUsername("Rod", password: "Password")</div><div>vs</div><div>login(username:"Rod", password: "Password")</div><div><br></div><div>Placing the WithUsername prior to the bracket implies that the username has more importance, at least to my eye. As has been discussed, it probably does have more importance, but I think it makes a fair point that there are cases where both arguments are simply peers that should be labeled without emphasis on the leading item. I think that naming each parameter for clarity makes sense in those cases, and this should be noted in documentation. </div><div><br></div><div>For all other elements, I am definitely in favour.</div><div><br></div><div><br></div><div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Is the problem being addressed significant enough to warrant a change to Swift?</span></font></li></ul></div></div></blockquote>I definitely think the language benefits from guidance like this. I wonder whether we may need to come back and review this in a few years as we see where Swift goes, but my hope is it keeps the same basic feel.</div><div><br></div><div><br></div><div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Does this proposal fit well with the feel and direction of Swift? </span></font></li></ul></div></div></blockquote>These language directions seem very consistent with Swift's direction.</div><div><br></div><div><br></div><div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></font></li></ul></div></div></blockquote></div><div>I find languages with clear guidelines tend to be somewhat more ordered. I'm definitely in favour of the a reference document that outlines standard practice, as it is beneficial both when teaching, and when reading people's code. Consistency breeds clarity, and these</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>On 31 Jan 2016, at 3:09 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span></span><br><span>on Sat Jan 30 2016, Howard Lovatt <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>I disagree that a property should imply O(1), this is an implementation</span><br></blockquote><blockquote type="cite"><span>detail that might change. </span><br></blockquote><span></span><br><span>Not that I really want to argue this, as I am resigned to the fact that</span><br><span>we will not tie performance to property-ness, but...</span><br><span></span><br><span>Efficiency characteristics are no mere implementation detail, at least</span><br><span>not in the standard library. </span><br><span></span><br><blockquote type="cite"><span>For example an array based collection will almost always have a count</span><br></blockquote><blockquote type="cite"><span>property that is O(1), </span><br></blockquote><span></span><br><span>You can strike "almost" :-)</span><br><span></span><br><blockquote type="cite"><span>but a liked-list based collection will almost always be O(N).</span><br></blockquote><span></span><br><span>It really depends on whether you allow O(1) splicing. Without</span><br><span>supporting O(1) splicing, it's really easy for a linked list</span><br><span>to have an O(1) count. And with cacheing, you can even arguably have an</span><br><span>amortized O(1) count.</span><br><span></span><br><span>But even if a linked list has O(N) count, I don't see that what you're</span><br><span>describing indicates anything, by itself, about whether something being</span><br><span>a property should have performance implications. There has to be an</span><br><span>underlying assumption that an Array's count must be a property, or</span><br><span>something else of that sort, in the background.</span><br><span></span><br><blockquote type="cite"><span>On Friday, 29 January 2016, Michael Wells <<a href="mailto:michael@michaelwells.com">michael@michaelwells.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>,----[ Side Note, since you mentioned efficiency ]</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| I originally wanted to uphold the principle that, “if it isn't</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>O(1),</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>you</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| don't make it a property.” The implication is that on collections,</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| “count” would be a method. That would include Array, for which</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>counting</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| the elements *is* O(1). Some people argued that:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>|</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| 1. The idea of writing “a.count()” instead of “a.count” to count</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>the</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| elements of an Array was absurd.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| 2. Programmers don't draw conclusions about efficiency based on</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>whether</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| something is a property.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| 3. The fact that Array would have an O(1) non-property that *could*</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>have</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| been a property (if it weren't for CollectionType conformance)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| undermines any communicative power that you might get from using</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>this</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| distinction to choose properties.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>|</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>| I did not win that argument :-)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I strongly agree that properties imply O(1) and most programmers I’ve ever</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>worked with make the same assumptions. Even if the documentation says</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>otherwise, code like</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>fibonacciNumbers.count</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>looks as if you’re accessing a c-style field ‘count’ and that implies (at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>least to me) that it is a near-costless operation. Some of the biggest</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>design mistakes I’ve ever seen use properties that trigger time-consuming</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>operations like database or network access.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>And I don’t think having to use a.count() is absurd. :-)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><span></span><br><span>-- </span><br><span>-Dave</span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></body></html>