<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=""><div class=""><div class="">Hello Swift Evolution! What a wonderful discussion going on here :)</div><div class=""><br class=""></div><div class="">== What is your evaluation of the proposal? ==</div><div class="">== Does this proposal fit well with the feel and direction of Swift? ==</div><div class=""><br class=""></div><div class="">I am against the proposal.</div><div class=""><br class=""></div><div class="">The way I see it, what we have here is a struggle between two forces:</div><div class=""><br class=""></div><div class="">- Readability, convenience, and a general desire to keep signal-to-noise ratio high</div><div class="">- Safety, explicitness, and a desire not to be ambiguous</div><div class=""><br class=""></div><div class="">This what makes it a difficult proposal to review, as there isn't a universally "right" or "wrong" answer — both forces are important and both points of view are correct. In my opinion, what it comes down to is how we (the community, and ultimately, the Core Team) weigh those two sets of values.</div><div class=""><br class=""></div><div class="">One of the things I love about Swift is that it clearly values both and tries to strike a careful balance when they’re in conflict. It’s a compiled, statically-typed language. It forces me to think about types, and make all my function signatures explicit. And it removes ambiguity regarding nullability with Optionals.</div><div class=""><br class=""></div><div class="">But it also has all sorts of syntax and tools to reduce noise and get rid of stuff I really don’t care about: type inference, implicit member expressions, shortcut closure forms, a bunch of syntax for dealing with Optionals, and _a lot_ more.</div><div class=""><br class=""></div><div class="">And most of these things carry some risk of ambiguity. But I think most of us still value them, because working with unnecessarily verbose code is exhausting.</div><div class=""><br class=""></div><div class="">Clarity is number one priority, of course, and we shouldn’t value brevity for its own sake. But by adding words and syntax to our code that carry little to no information, we’re essentially creating noise. We’re not improving clarity and understanding, we’re taking away from it. We’re just adding to the wall of text every reader has to scan and understand. We’re just diluting the signal — the names and symbols and constructs that actually contribute to the meaning of code.</div><div class=""><br class=""></div><div class="">And yes, there’s a balance to be struck there, and the question of whether `self.` should always be explicit is right at the edge of that balance.</div><div class=""><br class=""></div><div class="">However, there’s nothing in my experience of writing Swift to suggest that the balance should tip in favor of explicitness. I don’t recall being in a situation where I would be reading my code, confused whether a symbol is an instance method/property, or a global one. Nor do I recall a situation where I would mistakenly call the wrong thing because `self.` wasn’t required. A combination of context awareness of the code, knowledge of my codebases, and cues from the editor (syntax coloring, autocompletion, and warnings/errors when I do something wrong) do the job just fine.</div><div class=""><br class=""></div><div class="">Some people like things explicit and as safe as possible. That’s great! It seems like the kind of thing that would be considered best practice/preferred coding style for many groups no matter what. That doesn’t necessarily mean explicit self should be imposed on all users of Swift. I believe it’s the sort of decision best left to a linter.</div><div class=""><br class=""></div><div class="">That’s because the verbosity cost is rather large and the safety advantage not overwhelmingly obvious — therefore it will always be a divisive topic. By leaving implicit self allowed, both groups can be satisfied. By disallowing it, only one.</div><div class=""><br class=""></div><div class="">== Is the problem being addressed significant enough to warrant a change to Swift? ==</div><div class=""><br class=""></div><div class="">Clearly it’s a significant enough problem to warrant a big discussion. But I rather strongly disagree with the conclusion of the proposal.</div><div class=""><br class=""></div><div class="">I’m not completely against considering other alternatives on this topic, but I’m also not convinced that this is much of a problem in practice that _needs_ solving.</div><div class=""><br class=""></div><div class="">== If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? ==</div><div class=""><br class=""></div><div class="">I’ll just mention one language which had an interesting approach to this: CoffeeScript. In CS, self (this) is always explicit, however it is shortened to a single symbol: @. So you can pass @, call @method(), retrieve a @property.</div><div class=""><br class=""></div><div class="">It’s interesting, because, yes, you’re explicit, so there’s no ambiguity (I mean… there is… because JavaScript… but that’s another topic), but you also shorten the noisy `self.` repeated over and over and over to a single symbol.</div><div class=""><br class=""></div><div class="">Clearly @ is probably a wrong symbol in Swift context, and it would seem syntactically unlike Swift to introduce it now, however I’d be more willing to consider such proposal as it strikes a better balance between the two forces.</div><div class=""><br class=""></div><div class="">My opinion is also influenced by Objective-C, Ruby, JavaScript and please-don’t-tell-anyone PHP.</div><div class=""><br class=""></div><div class="">== How much effort did you put into your review? ==</div><div class=""><br class=""></div><div class="">Clearly too much.</div><div class=""><br class=""></div><div class="">Thank you for enduring my rant, and good night!</div><div class=""><br class=""></div><div class="">Best,</div><div class="">— Radek</div></div><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Hello Swift community,
The review of “Require self for accessing instance members” begins now and runs through Sunday, December 20th. The proposal is available here:
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md</a>
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>>
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a> <<a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a>>
Cheers,
Doug Gregor
Review Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/66b50e7c/attachment.html" class="">https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/66b50e7c/attachment.html</a>>
</pre></blockquote><div class=""><br class=""></div></body></html>