[swift-evolution] Proposal SE-0009 Reconsideration

Michael Peternell michael.peternell at gmx.at
Thu May 19 14:15:12 CDT 2016


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 at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list