-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Should conditional_binding_cascade
be removed?
#701
Labels
enhancement
Ideas for improvements of existing features and rules.
Comments
Yes, we should remove this. |
jpsim
added
the
enhancement
Ideas for improvements of existing features and rules.
label
Jun 21, 2016
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 😳.
iisbear83
added a commit
to iisbear83/ReSwift
that referenced
this issue
Aug 5, 2024
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
let
is 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: