Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10207] Immediate execution of defer warning shouldn't be given in a direct-to-storage context #52607

Closed
hamishknight opened this issue Mar 27, 2019 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@hamishknight
Copy link
Collaborator

Previous ID SR-10207
Radar None
Original Reporter @hamishknight
Type Bug
Status Resolved
Resolution Duplicate
Environment

Swift version 5.0-dev (LLVM 94d957ca75, Swift 1d2e2803af)
Target: x86_64-apple-darwin18.2.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 1f82adedcfc33c7205d4e4b6ab5566dd

duplicates:

  • SR-9000 of deinitializers, property observers, and defer

Issue Description:

For the following code we produce a warning that the defer will be executed immediately:

class S {
  var foo = "" {
    didSet { print("didSet") }
  }

  deinit {
    // warning: 'defer' statement before end of scope always executes
    // immediately; replace with 'do' statement to silence this warning
    defer {
      foo = ""
    }
  }
}

The attached fix-it suggests replacing with a do statement, however that has the unfortunate consequence of changing the program's behaviour, as now the access to foo is done direct-to-storage and the property observer is no longer called. It's a shame that defer doesn't also perform a direct-to-storage access, but unfortunately quite a few people now rely on that behaviour.

Therefore I think we should limit this warning to only apply to contexts where property accesses are done normally, such as methods.

Interestingly enough, the warning already doesn't trigger on a defer that's the last statement of an initialiser, but I couldn't find specific logic that excludes this case. But even then, the exclusion isn't broad enough, as it doesn't cover the following case:

class S {
  var s = "" {
    didSet {
      print("didSet")
    }
  }

  init() {
    do {
      // warning: 'defer' statement before end of scope always executes
      // immediately; replace with 'do' statement to silence this warning
      defer {
        s = ""
      }
    }
  }
}
@belkadan
Copy link
Contributor

This was never really intended to be supported…

@hamishknight
Copy link
Collaborator Author

Indeed, however changing the behaviour now would be fairly source breaking as I believe quite a few people rely on defer calling property observers. Is this something that we'd still be willing to change? (If so, would it need to go through SE?)

If we do make this change to defer, then we'll also want to fix this case where the warning doesn't fire:

class C {
  var foo = ""

  init() {
    defer {
      foo = ""
    }
  }
}

@belkadan
Copy link
Contributor

Yes, full-on changing the behavior would require an evolution proposal at this point. I'm just not sure if we-as-a-project want to encourage this pattern in the mean time.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

2 participants