Hello Swift Evolution! What a wonderful discussion going on here :)
== What is your evaluation of the proposal? ==
== Does this proposal fit well with the feel and direction of Swift? ==
I am against the proposal.
The way I see it, what we have here is a struggle between two forces:
- Readability, convenience, and a general desire to keep signal-to-noise ratio high
- Safety, explicitness, and a desire not to be ambiguous
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.
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.
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.
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.
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.
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.
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.
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.
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.
== Is the problem being addressed significant enough to warrant a change to Swift? ==
Clearly it’s a significant enough problem to warrant a big discussion. But I rather strongly disagree with the conclusion of the proposal.
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.
== If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? ==
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.
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.
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.
My opinion is also influenced by Objective-C, Ruby, JavaScript and please-don’t-tell-anyone PHP.
== How much effort did you put into your review? ==
Clearly too much.
Thank you for enduring my rant, and good night!
Best,
— Radek
···
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:
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
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
https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
Cheers,
Doug Gregor
Review Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/66b50e7c/attachment.html>