Should conditional_binding_cascade be removed?
#701
Labels
Comments
|
Yes, we should remove this. |
masters3d
added a commit
to masters3d/SwiftLint
that referenced
this issue
Jul 30, 2016
jpsim
pushed a commit
that referenced
this issue
Aug 2, 2016
masters3d
added a commit
to masters3d/SwiftLint
that referenced
this issue
Aug 21, 2016
mokagio
added a commit
to ReSwift/ReSwift
that referenced
this issue
Jan 30, 2017
This rule has been removed from SwiftLint by [this PR](realm/SwiftLint#701). When running SwiftLint version 0.16.1 with a config file that disables this rule we endup with this outpus ``` $ swiftlint Loading configuration from '.swiftlint.yml' configuration error: 'conditional_binding_cascade' is not a valid rule identifier Valid rule identifiers: [...] a list of all the valid rules ``` This warning doesn't prevent the linting from running, and doesn't break the Xcode integration. As every warning though it should be looked at and addressed. Furthermore, here's a practical reason why it should be fixed. This issue can end up breaking CI integration of projects like the [iflix](https://iflix.com) iOS app which use the [danger-swiftlint Danger plugin](https://github.com/ashfurrow/danger-swiftlint). This plugin performs a `swiftlint` run for each single file in the PR diff in order to collect violations and report them as a PR comment. Now here's the deal. The GitHub APIs only allow comments with less than 65536 characters. Generating that output for each of the files quickly results in the characters limit being reached 😳.
mokagio
added a commit
to ReSwift/ReSwift
that referenced
this issue
Jan 30, 2017
This rule has been removed from SwiftLint by [this PR](realm/SwiftLint#701). When running SwiftLint version 0.16.1 with a config file that disables this rule we endup with this outpus ``` $ swiftlint Loading configuration from '.swiftlint.yml' configuration error: 'conditional_binding_cascade' is not a valid rule identifier Valid rule identifiers: [...] a list of all the valid rules ``` This warning doesn't prevent the linting from running, and doesn't break the Xcode integration. As every warning though it should be looked at and addressed. Furthermore, here's a practical reason why it should be fixed. This issue can end up breaking CI integration of projects like the [iflix](https://iflix.com) iOS app which use the [danger-swiftlint Danger plugin](https://github.com/ashfurrow/danger-swiftlint). This plugin performs a `swiftlint` run for each single file in the PR diff in order to collect violations and report them as a PR comment. Now here's the deal. The GitHub APIs only allow comments with less than 65536 characters. Generating that output for each of the files quickly results in the characters limit being reached 😳.
mokagio
added a commit
to ReSwift/ReSwift
that referenced
this issue
Feb 12, 2017
This rule has been removed from SwiftLint by [this PR](realm/SwiftLint#701). When running SwiftLint version 0.16.1 with a config file that disables this rule we endup with this outpus ``` $ swiftlint Loading configuration from '.swiftlint.yml' configuration error: 'conditional_binding_cascade' is not a valid rule identifier Valid rule identifiers: [...] a list of all the valid rules ``` This warning doesn't prevent the linting from running, and doesn't break the Xcode integration. As every warning though it should be looked at and addressed. Furthermore, here's a practical reason why it should be fixed. This issue can end up breaking CI integration of projects like the [iflix](https://iflix.com) iOS app which use the [danger-swiftlint Danger plugin](https://github.com/ashfurrow/danger-swiftlint). This plugin performs a `swiftlint` run for each single file in the PR diff in order to collect violations and report them as a PR comment. Now here's the deal. The GitHub APIs only allow comments with less than 65536 characters. Generating that output for each of the files quickly results in the characters limit being reached 😳.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SE-0099 has been accepted and we will be able to freely mix boolean conditions and optional bindings.
The syntax for comma separated bindings without
letis no longer supported, which means this rule enforces behavior which will lead to more work when moving to a future version of Swift. Should it be removed?The text was updated successfully, but these errors were encountered: