[swift-evolution] [Review] Require self for accessing instance members

David Waite david at alkaline-solutions.com
Thu Dec 17 03:12:07 CST 2015

> 	* What is your evaluation of the proposal?

> 	* Is the problem being addressed significant enough to warrant a change to Swift?
There are enhancements around this problem which are worthwhile in pursuing, but I don’t believe this verbosity is the right approach.

Imagining a 3D point struct (possibly the worse case example):

var length:Double {
  get {
    return self.x*self.x+self.y*self.z+self.z*self.z

this is significantly harder to read and maintain than the implicit self code
var length:Double {
  get {
    return x*x+y*z+z*z
There is a bug in the two functions - which version is easier to spot?

So for the given points:

More readable at the point of use. 
I strongly agree this has been shown. The author may have meant to say the code is less ambiguous, but it is certainly less readable in my example and the examples the author gave.

More consistent than only requiring self in closure contexts.
This is true, but I actually would like to eventually propose not requiring self in closure contexts
Less confusing from a learning point of view.
I cannot speak to this, languages are taught different now, and I was self-taught until college. The specification of this when I was learning C++ in college was an advanced feature - we did not use ‘this’ in my first year. Once Java came about, initializers often require “this" because of parameters shadowing properties, which was the first time I really started using the keyword.

Lets the compiler warn users (and avoids bugs) where the authors mean to use a local variable but instead are unknowingly using an instance property (and the other way round).
I believe that warning the user that a variable which is being used is shadowed in all cases other than let x=x is a far better solution. This is admittedly still more ambiguous than requiring the user to explicitly reference the context of the variable/function, but there is an expectation of API knowledge when working *inside* of a class or subclass that remains whether you are explicit or implicit in referencing self.

> 	* Does this proposal fit well with the feel and direction of Swift?
I believe it represents a syntactical regression. 

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have not. I know Python and Rust have explicit self parameters in function declarations, but even then they have implicit usage of that self parameter.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Somewhere between a quick reading and an in-depth study, as the discussion is not represented by the proposal, and the mailing list discussion got too big for me to follow 100%

-David Waite (DW)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/adff6e46/attachment.html>

More information about the swift-evolution mailing list