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

[Dennis Lysenko]

Dan, +1, that is an excellent writeup of why implicit self is so dangerous.
It's exactly because it's sneaky and hard to find. Similar to bad access
errors (which, for a wealth of reasons, is impossible to "fix", but
implicit self errors ARE possible to fix.)

On Wed, Dec 16, 2015, 8:19 AM Dan Loewenherz 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:
> > > 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.
>
> The big difference is that “!” is instantly recognizable as a code
> smell (because there’s an operator which makes you feel bad for using
> it) and implicit usage of “self” is not at all, (because, well, it’s
> implicit). If you want to eliminate issues of force-unwrapping in your
> codebase—even discounting any compiler flags—you can simply search for
> the exclamation mark or use a simple regex and replace. There’s no
> similar easy way to address implied self.
>
> Indeed, both the ability to force unwrap and use of implied self can
> lead to bugs, but they’re of a different variety. By force unwrapping,
> you know that you’re opening up the possibility of a nil reference.
> The bugs stemming from implied self are much more sneaky, bizarre, and
> hard to track down (again, there is nothing that can give it away,
> such as an operator).
>
> Perhaps most importantly, any developer can make a mistake, and
> despite their tendencies towards explicit self, can forget to use if
> it’s a situation where its presence would prevent a bug. At least with
> “?” and “!”, you’re forced to make a decision (and one of those
> decisions makes you feel somewhat guilty…).
>
> Dan
> _______________________________________________
> 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/3f15a270/attachment.html>