I'd prefer to raise warning for any shadowing, and so, in case of
`if let value = value` we'll have a warning: in discussions about 'if let!
value' construction proposal there was many opinions that 'if let v = v' is
a bad style and you should avoid to do this and improve your code to not do
this. So I believe warning for 'if let v = v' will be accepted by community.
On 18.05.2016 22:36, David Waite wrote:
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
<[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
