Well, SE-0009 is not related to shadowing, is it? I think it is something 
completely different.

The problem that SE-0009 tries to solve is that when looking at a line in 
isolation, like

    print(foo)

there is no way to tell wether foo is an iVar, a local var or a parameter. This 
can happen if you don't remember the names of all iVars of a class. A warning 
on shadowing will not help here at all. I think shadowing is not bad, and if 
someone wants to disallow shadowing, he should make another proposal. After 
all, if I add another iVar to a class, I want it to still compile. With 
shadowing disallowed, I may give an iVar the same name as the local variable in 
some of the methods.

Regarding the original SE-0009, I think it is better to use syntax highlighting 
for this. Xcode already does it well: local vars are black, other vars have 
some color (with the "Default" syntax highlighting theme).

I know not everyone is using Xcode. But anyways, coding without an IDE is 
always painful if the program you write has more than 500 lines. And for any 
IDE that has autocompletion and something like the "Jump to symbol" feature of 
Xcode, implementing syntax highlighting right is not that hard. Omitting "self" 
is convenient, and the problems arising from it are not so bad that "self" 
should be made mandatory IMO.

-Michael

> Am 19.05.2016 um 20:12 schrieb Vladimir.S via swift-evolution 
> <swift-evolution@swift.org>:
> 
> Oh, in this case IMO warning for 'self.' will never be introduced, it's 
> clear. And as I understand, no support in community for warning for 
> shadowing. OK, so as I understand, the only solution here - tools like 
> SwiftLint and plugins to xcode.
> 
> Btw, regarding 'similar to the override keyword', do you mean something like 
> this:
> 
> class A {
>  public var x = 10
> 
>  func f() {
>    override var x = 100
> 
>    var value: Int? = 1
>    if override let value = value {..}
>  }
> }
> 
> ?
> 
> On 19.05.2016 20:58, David Waite wrote:
>> I believe the Swift Team has previously stated they do not want opt-in
>> warnings defining alternate swift ‘grammars’. I don’t believe there are
>> any existing -W flags for the compiler, for instance.
>> 
>> If there is shadowing warning added, I’m of the opinion it should work
>> similar to the override keyword.
>> 
>> -DW
>> 
>>> On May 19, 2016, at 11:28 AM, Vladimir.S via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> On 18.05.2016 22:43, Krystof Vasa wrote:
>>>> I agree that shadowing variables is not a good idea, but I stand by
>>>> my point that it's potentially dangerous and error-prone to allow
>>>> accessing instance variables without `self`.
>>> 
>>> Could we all agree that we need these options: 1. option to turn on
>>> warnings on accessing instance variables without `self` 2. option to
>>> turn on warnings on shadowing And that by default, none of that
>>> options should be enabled. ?
>>> _______________________________________________ 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

Reply via email to