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

[Rule Request] Prefer new block based KVO API in Swift 3.2 or 4 #1714

Closed
marcelofabri opened this issue Jul 27, 2017 · 3 comments
Closed

[Rule Request] Prefer new block based KVO API in Swift 3.2 or 4 #1714

marcelofabri opened this issue Jul 27, 2017 · 3 comments
Labels
rule-request Requests for a new rules.

Comments

@marcelofabri
Copy link
Collaborator

When using Swift 3.2 or 4, the new block based API KVO API is preferred.

kvo

// should trigger
func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {

}

// ok
let observer = foo.observe(\.value, options: [.new]) { (foo, change) in
    print(change.newValue)
}
@marcelofabri marcelofabri added the rule-request Requests for a new rules. label Jul 27, 2017
@marcelofabri
Copy link
Collaborator Author

marcelofabri commented Jul 27, 2017

Probably the most trick thing here is to detect the Swift version.

We can the new keypath syntax and the structure to find if it's Swift >= 3.2.

  • file.swift
let nameKeyPath = \ForceUser.name
  • Command
    sourcekitten structure --file file.swift

  • Result with Swift 3.1:

{
  "key.offset" : 0,
  "key.diagnostic_stage" : "source.diagnostic.stage.swift.parse",
  "key.length" : 34,
  "key.diagnostics" : [
    {
      "key.filepath" : "\/Users\/marcelofabri\/dev\/SwiftLint\/file.swift",
      "key.column" : 19,
      "key.description" : "invalid character in source file",
      "key.fixits" : [
        {
          "key.offset" : 18,
          "key.sourcetext" : " ",
          "key.length" : 1
        }
      ],
      "key.line" : 1,
      "key.diagnostic_stage" : "source.diagnostic.stage.swift.parse",
      "key.severity" : "source.diagnostic.severity.error"
    }
  ],
  "key.substructure" : [
    {
      "key.nameoffset" : 4,
      "key.accessibility" : "source.lang.swift.accessibility.internal",
      "key.length" : 33,
      "key.name" : "nameKeyPath",
      "key.kind" : "source.lang.swift.decl.var.global",
      "key.namelength" : 11,
      "key.offset" : 0
    }
  ]
}
  • Result with Swift 3.2 or 4:
{
  "key.diagnostic_stage" : "source.diagnostic.stage.swift.parse",
  "key.substructure" : [
    {
      "key.nameoffset" : 4,
      "key.accessibility" : "source.lang.swift.accessibility.internal",
      "key.length" : 33,
      "key.name" : "nameKeyPath",
      "key.kind" : "source.lang.swift.decl.var.global",
      "key.namelength" : 11,
      "key.offset" : 0
    }
  ],
  "key.offset" : 0,
  "key.length" : 34
}

Unfortunately, I couldn't find a way do identify whether it's Swift 3.2 or 4.

@ornithocoder
Copy link
Contributor

Maybe using #if swift()?

$ swift --version
Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42)
Target: x86_64-apple-macosx10.9
$ cat file.swift 
#if swift(>=3.1)
    print("3.1.x")
#endif
$ sourcekitten structure --file file.swift
{
  "key.diagnostic_stage" : "source.diagnostic.stage.swift.parse",
  "key.substructure" : [
    {
      "key.namelength" : 5,
      "key.nameoffset" : 21,
      "key.length" : 14,
      "key.name" : "print",
      "key.bodyoffset" : 27,
      "key.bodylength" : 7,
      "key.kind" : "source.lang.swift.expr.call",
      "key.offset" : 21
    }
  ],
  "key.offset" : 0,
  "key.length" : 43
}
$ cat file.swift 
#if swift(>=4.0)
    print("4.0.x")
#endif
$ sourcekitten structure --file file.swift
{
  "key.diagnostic_stage" : "source.diagnostic.stage.swift.parse",
  "key.substructure" : [

  ],
  "key.offset" : 0,
  "key.length" : 43
}

@marcelofabri
Copy link
Collaborator Author

@ornithocoder Nice! Unfortunately, we still can't tell if it's 3.2 or 4. But I guess in most cases it won't matter anyway. We can leave that for later if needed.

marcelofabri added a commit that referenced this issue Jul 27, 2017
marcelofabri added a commit that referenced this issue Jul 27, 2017
marcelofabri added a commit that referenced this issue Jul 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

2 participants