[swift-evolution] [Review] Require self for accessing instance members
kevin at klundberg.com
Sun Dec 20 09:54:05 CST 2015
-1, for this reason, and for the extreme loss in conciseness already
mentioned elsewhere. The purported extra clarity is not worth the extra
burden placed on writing code in my opinion. I would favor a compiler
warning at the most, and this can be solved on an individual/team basis
with linting tools as well.
On 12/18/2015 1:02 AM, Jed Lewison via swift-evolution wrote:
> 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
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> Reviews are an important part of the Swift evolution process. All
>> reviews should be sent to the swift-evolution mailing list at
>> 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
>> Doug Gregor
>> Review Manager
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution