Perhaps a better approach to the shadow variables problem is to enable the objc compiler flag -Wshadow to be available in Swift.
In the same way a "requiring self" compiler flag should help enforce self on the programer by always showing a warning when the flag is on. > On May 18, 2016, at 9:13 AM, Sean Heber via swift-evolution > <[email protected]> wrote: > > I’ve been wondering if shadowing variable names should just be an error. I > know that it’s a very common pattern when unwrapping such as: > > if let thing = thing {} > > But that not only looks ugly, there’s often better ways to solve this and > using different names there would also likely improve clarity anyway. > Wouldn’t an error when shadowing any variable name also have prevented this > bug without requiring self since there would have been no way for there to be > a local variable with the same name? Would that be too restrictive or would > it actually further Swift's goals of clarity and safety? I think I could > probably argue that making shadowed names a straight up error would improve > code quality. > > l8r > Sean > > >> On May 18, 2016, at 12:09 AM, Krystof Vasa via swift-evolution >> <[email protected]> wrote: >> >> Hi there, >> >> I've been an OS X developer for over a decade now and was a huge fan of >> ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge >> University and my Masters thesis was a modular ObjC runtime that ran on Win >> 3.11. With the advance of Swift, it was clear to me, however, that this is a >> point to say goodbye to ObjC and move to Swift. >> >> And so, I've migrated all my projects over 5 months into Swift, which is >> over 200 KLOC of code, with one project being 90 KLOC. This has lead >> unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, >> where I was unable to build a project for a month, etc. - I've filed 84 bug >> reports at bugreport.apple.com over the past few months regarding developer >> tools (including Swift) and have begun closely watching the evolution of >> Swift. >> >> While I strongly disagree with the rejection of SE-0009, I understood the >> reasoning that it's a boilerplate to keep adding self. in front of all >> variables. I personally always refer to self when accessing instance >> variables (and methods), unless they are private variables starting with >> underscore. I know the underscore thing isn't very Swift-y, but on the other >> hand, reading the code you immediately know you are dealing with a private >> instance variable, not something local. >> >> This was until I spent 2 hours chasing a bug that was caused by the exact >> issue this proposal was trying to prevent. I was furious. >> >> a) When you read someone elses code and you see myVar.doSomething(), you >> assume it's refering to a local variable. Which is incredibly confusing, if >> this is an instance variable. Swift is all about compile-time checks and >> this is where it fails. >> >> b) If you indeed decide not to go with this proposal, please consider adding >> a warning option. When you take a look at LLVM warning options, I bet there >> would be a place for this. Let the user decide. I personally would >> immediately turn it on on all my projects. Don't make it an error, make it a >> warning. >> >> I speak to you as someone with quite a huge real-life experience with Swift, >> mainly in the last year - the question whether to force the reference to >> self is something that may be dividing the community, but I believe that >> most people with more developing experience would be all for this. At least >> as an option. >> >> Sincerely yours, >> >> Krystof Vasa >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
