> Am 18.05.2016 um 21:53 schrieb Goffredo Marocchi via swift-evolution > <[email protected]>: > > The code you pasted really ought to print a warning out (allowing variable > shadowing without even a warning can lead to annoying bugs), a generation of > Swift developers will be trained by relying on the Swift compiler to make > their code automagically safe and this is another one of those Not Fun To > Debug bits (similar to the dispatching rules of protocol extensions default > methods).
There are dispatching rules of protocol extension default methods? I thought the methods are selected randomly... just kidding - I think this issue would be worth a proposal... > > Sent from my iPhone > >> On 18 May 2016, at 17:39, Vladimir.S via swift-evolution >> <[email protected]> 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 >>> [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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
