[swift-evolution] Proposal: Re-instate mandatory self for accessing instance properties and functions (David Hart)

Wed Dec 16 11:41:45 CST 2015

Simple, have the compiler require an explicit [strong self] if you use
self. inside of a closure.

On Wed, Dec 16, 2015 at 12:00 PM Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> I would also not like to see the return of mandatory self. I’d be in favor
> of going the opposite direction and ban even using “self” whenever it
> *doesn’t* disambiguate anything in the scope just to reinforce the pattern
> of putting self inside closures, etc and keeping things readable.
>
> struct Foo {
>   var x: Int
>
>   func something1(x: Int) {
>     print(x)  // prints the incoming value, as you’d expect
>     print(self.x)  // prints the member var as you’d expect
>   }
>
>   func something2() {
>     print(self.x)  // error - x is not ambiguous, so self is not allowed!
>   }
> }
>
> l8r
> Sean
>
>
> > On Dec 16, 2015, at 10:47 AM, Nick Shelley via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > I keep seeing the argument brought up that "allowing implicit self can
> lead to hard to find bugs," but no one seems to be mentioning the bugs it
> helps avoid. To me, it's not a tradeoff between boilerplate and bugs; it's
> a tradeoff between one type of hard to find bug and another type of hard to
> find bug. Let me share my own experience on both sides to clarify.
> >
> > In Objective-C, self was always required, so I never encountered the
> hard-to-find shadowing bugs discussed in this list. However, because self
> was required everywhere, I had nothing to help me realize that using self
> in a block captured self and potentially created retain cycles. These bugs
> are (for me) some of the hardest to track down because memory leaks aren't
> a problem until they are, and then all of a sudden potentially months of
> bad practice in this area can come back to bite you all at once. And maybe
> I'm just an Instruments noob, but tracking down the leak and the source of
> the retain cycle was always a _huge_ pain.
> >
> > Then we switched to Swift, and our team quickly adopted (and enforced
> through code review) the code style where self is only allowed where it is
> required. By getting in the habit of never using self, every time we write
> code in a closure that implicitly captured self, the compiler would yell at
> us. We learned to interpret these yells as a warning to think about memory
> inside that closure, and the result has been far fewer retain-cycle bugs.
> >
> > And, to be honest, in all my time using Swift (I've been writing in it
> pretty much exclusively since its beta days), I can't recall a shadowing
> bug that has given me much trouble at all.
> >
> > So, for me (and I think I can speak for others I've worked with who also
> love the reminder from the compiler to think about memory), readability
> doesn't even really factor into this proposal. This proposal is mainly
> about sacrificing help with avoiding very-hard-to-find bugs in retain
> cycles for the sake of making easier-to-find bugs with shadowing less
> likely. That is an obvious loss in my experience, and I'm hoping this
> proposal won't be taken seriously until there is an alternate way for the
> compiler to warn me about retain cycles.
> >
> > On Wed, Dec 16, 2015 at 9:20 AM, James Dempsey via swift-evolution <
> swift-evolution at swift.org> wrote:
> > >> I think the mandatory self problem is analogous to never wanting to
> use x!, as! or try!. If you restrict yourself to always using
> self.whatever, it is not unusual to someone else, and if they leave off the
> compiler flag or pragma that enforces this, the code will still compile.
> >
> > I think there is a fundamental difference between code that does / does
> not use x! as! or try! and code that may or may not require the use of self.
> >
> > Even if you do not use x! as! or try! in your own code, you can easily
> read and understand code that does use those features.
> >
> > But if you choose to enforce using self in your own code, suddenly you
> need to read and reason about code in two different ways.
> >
> > In ‘mandatory self’ code, you can assume self is always being used and
> you cannot accidentally use something in local scope by mistake.  The
> ‘mandatory self’ removes a set of potential bugs you need to check for when
> reading code.  But when you encounter ’non enforced self’ code, you can’t
> make those assumptions and you need to check for those issues.
> >
> > For me, choosing not to use x! as! or try!  in your code is like
> choosing not to use swear words when you speak. You easily understand them
> when someone else uses them, but you choose not to.
> >
> > Being able to choose ‘mandatory self’ or not is more like a dialect. For
> each dialect you need to adjust your mental model of how the language works.
> >
> > Overall, I am +1 for the proposal of making self mandatory because I
> find the lack of 'mandatory self' makes the code less readable, less
> explicit as to intent and can also introduce subtle bugs.
> >
> > If it comes down to adding some sort of switch or not I am -1 for that
> because that does seem like the creation of two dialects of the language.
> >
> > James
> >
> >
> > > On Dec 15, 2015, at 9:54 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > >
> > >
> > >> On Dec 15, 2015, at 8:10 PM, Kenny Leung via swift-evolution <
> swift-evolution at swift.org> wrote:
> > >>
> > >> This is the full text of what Chris said in regard to “Proposal: Add
> Flags to Disable [Optional] Conversions"
> > >>
> > >>> I don’t like the idea of having different incompatible dialects, and
> behavior changing modes.  That said, I’m personally not opposed to
> providing functionality that would enable people to use a reduced subsets
> of the language, and have the compiler enforce it.  For example, I don’t
> have a problem with someone saying they never want to use the x!, as!, try!
> family and have the compiler tell them if they do.
> > >>>
> > >>> To relate this to your question, I’d be fine with functionality that
> causes the compiler to produce an error when code requires an implicit
> conversion, but I wouldn’t want them to be just “disabled”, because I think
> this could change the interpretation of valid swift code (in admittedly
> weird cases).
> > >>>
> > >>> In terms of how to express this, I’m not in love with modal compiler
> flags :-).  I’d much rather this sort of requirement be specified as a
> pragma-like construct that applies to an arbitrary scope (e.g. class or
> function body) or a whole file.  This keeps the code self describing.
> > >>
> > >> I think the mandatory self problem is analogous to never wanting to
> use x!, as! or try!. If you restrict yourself to always using
> self.whatever, it is not unusual to someone else, and if they leave off the
> compiler flag or pragma that enforces this, the code will still compile.
> > >
> > > I agree with you.
> > >
> > > -Chris
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >  _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/607efd86/attachment.html>