Silence 'consider changing to 'let' constant' warning

Evolution Discussion
1

I have a variable that isn’t currently mutated, but will be once further bits are completed. To satisfy my desire to not have a warning while testing, I copy the line and change it to let.

//var result = slots
let result = slots

This is fine. But, (var) result = slots could silence that warning and remind me to take off the ()’s once it actually becomes mutating. (var) is still let in every way.

Would anyone else use this?

1 Like
2

I'm not sure I'm understanding how this is superior to silencing the warning by leaving as let for the time being, and then being prompted to change it to var as soon as you attempt to mutate it.

10 Likes
3

I think it would be reasonable to show that warning just when explicitly building, and not while editing source (but I don’t think that there’s a warning group for such diagnostics at this time).

1 Like
4

No, I'd just use:

let result = slots
// TODO: don't forget to change this
5

just when explicitly building, and not while editing source

FWIW this is already my experience in Xcode at least.

6

This just needs to go away completely. As much as I like to know about these things, it's a linter's job.

func f() {
  var x = 1   // Warning.

  struct S {  // S is never used. Why no warning?
    var x = 1 // // x is never mutated. Why no warning?
  }

  func f() async { } // f is never used. Nothing async happens. Why no warnings?
}
2 Likes
7

Why not just make it a let? The compiler will definitely tell you when it’s time to make it a `var`.

2 Likes
8 
 struct S {
    // S is never used. Why no warning? 
    var x = 1 // // x is never mutated. Why no warning?
 }

The reason you get no warning for var x = 1 inside the declaration of the struct S is because you could do var s1 = S(); s1.x = 2

You could argue that there should be a warning about S never being used, but as you say that is heading into linter territory.

My head cannon for why the var is never mutated warning exists is because it goes to the core of one of Swift's safety goals of preferring immutability. It really doesn't bother me TBH.

1 Like