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

[Austin Zheng]

I agree with Nick that we should clarify the purpose of the proposals: to
convince the community that the idea is worth formally reviewing (hence,
the sales pitch), or to provide an overview of the idea and of the
community's preliminary reaction to it on the lists (more impartial).

In terms of actual review: I am against the proposal.

The primary contention seems to be safety versus programmer convenience.

In terms of programmer convenience, having pervasive self for instance
member access adds visual noise that makes reading code more tedious. To
me, Swift code within a method is easier to visually parse than equivalent
Objective-C code because I'm not constantly being distracted by "self.".

In terms of safety: to me, non-mandatory 'self' is about as dangerous as
the more general variable shadowing/name masking which you can do elsewhere
in the language. Programmer experience is anecdotal and of limited utility;
that being said the stated issue has not been a problem for me, or for any
of the Swift developers that I've worked with.

In the context of mandatory/optional "self.", the possibility of shadowing
exists between instance members and local variables/parameters. Best
practice is to keep methods short enough to be intelligible as a whole,
with complex sub-tasks delegated to other methods. In this situation it
should be trivial to tell if a particular name refers to an instance member
or a local variable/parameter.

In terms of alternatives, this is something that an opt-in warning or a
linter should be able to handle, for those disinclined to allow use of
implicit self within their own codebases.

In terms of language philosophy, Swift is clearly not a "safety at any
costs" language. (If it were, the language would look very different: array
subscripts returning optionals, prohibition of shadowing altogether, etc.)
Instead, Swift aims to balance safety with other factors, such as
performance, accessibility to programmers coming from C-style languages,
programmer ergonomics, etc (as seen by the pitch on the Swift web site and
previous posts from the developer team). In that light, it only makes sense
to degrade programmer ergonomics/code readability if the resultant increase
in safety (or some other dimension) is worth it. I don't think it is.

Best,
Austin


On Wed, Dec 16, 2015 at 12:49 PM, Hooman Mehr via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Dec 16, 2015, at 10:55 AM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> * What is your evaluation of the proposal?
>
>
> -1
>
> Not much to add to the discussion.
>
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
>
>
> No. Although a suppressible/enforceable warning might be beneficial.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
>
> I don’t think so. It enforces a lot of visual clutter *everywhere* to
> provide some benefit for people with certain coding/naming habits.
>
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> A quick reading.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/468e8034/attachment.html>