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

[David Waite]

> On Dec 17, 2015, at 4:33 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What other solutions can we think up? We already discussed using other prefix keywords which are less verbose than self, but couldn't come up with any great solution. I would just like the language help us here to make things safer without everybody using their own naming conventions or Hungarian notation.

I believe that the compiler should give warnings (on use, not declaration/import) of a variable or function overload which has been implicitly shadowed and is ambiguous. Explicit shadowing today I believe is only defined by let x=x or var x=x (where the local copy and original have the same name). Of course, a recommendation for resolving these issues would be part of any such proposal.

That does still leave the following issue from your proposal:
    func updateButton() {
        // var title = "Hello \(name)"
        button.setTitle(title, forState: .Normal) // forgot to comment this line but the compiler does not complain and title is now referencing UIViewController’s title by mistake
        button.setTitleColor(UIColor.blackColor(), forState: .Normal)
    }

This is not ambiguous, so I would not expect such a problem to take long to debug. Moreso, any run of the code *before* they commented out the var title=… line would have had a warning about the shadowing.

This would also make some of the method cascading approaches (where a value behave like an implicit self within a block of code) possible without introducing massive ambiguity - the compiler likely just requires you to fully specify the types in the case where your names are ambiguous. Who knows, this might encourage people to come up with more descriptive names! ;-) 
 
-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/cd6b603a/attachment.html>