I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either: - shadowing only causes warnings in some places and is allowed in others (and has a way to indicate intent to turn off warnings) - shadowing is disallowed everywhere, and “if let” has some terse syntax to indicate intent.
-DW > On May 18, 2016, at 10:39 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org> wrote: > > Fully support your opinion. +1 for warning option. > Also, I believe we need a warning (not error as suggested by @Sean in reply > to this thread) when type's property shadowed with local variable. > > Or do we *really* feel that this code don't require at least a warning ?? : > > class A { > var x = 100 > > func f() { > let x = 10 > print(x) > } > } > > > On 18.05.2016 8:09, Krystof Vasa via swift-evolution 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution