I’m not in favor of this proposal, and rather than repeat arguments that have already been made, I thought I’d share a small piece of data from the project I’m working on to illustrate the impact of implicit self in terms of reducing repetitive boilerplate cruft.
Our project consists of a legacy ObjC code base for an iOS app and a new version written entirely in Swift. The feature set is largely the same in both code bases, so it’s a good A vs B comparison. In the Objective C version of the app, there are ~25,000 explicit references to self. (Keep in mind that this could easily have been a much bigger number if there weren’t such pervasive usage of ivars in the code.). In the Swift version, there are ~1,000 explicit references to self, mostly in initializers and when passing self as an argument to a protocol — and about 10% of those would disappear with the proposal to allow implicit references to self with a strong capture list. I know self is just a 4-letter word, and I know Swift’s goal isn’t to reduce character count simply for the sake of reducing character count, but it least for our project, avoiding “self”-blindness has really mode code more readable. > On Dec 16, 2015, at 1:55 PM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > 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: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md> > > 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
