-
Notifications
You must be signed in to change notification settings - Fork 503
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
Styling for context receiver #1672
Comments
Absens of coding convention is not really a problem. For now I will look at default IntelliJ IDEA formatter and the sources you have provided. |
For now, I have identified a few code sample on which special indentation is needed: Context receiver with a list of parameters on separate lines
Default IntelliJ IDEA formatter however does not indent the
Context receiver with a generic type
Default IntelliJ IDEA formatter however does not de-indent the closing ">" , resulting in:
Although, this can be fixed in KtLint quite easily, I propose to use the IntelliJ IDEA default formatting for now to keep it in sync with other TYPE_ARGUMENT_LISTs which are formatted in this way. Context receiver combined with a modifier
Default IntelliJ IDEA formatter however indents modifiers, resulting in:
A comparable example on a property has already been submitted as https://youtrack.jetbrains.com/issue/KTIJ-21072/Provide-proper-indentation-on-declarations-with-context-receivers Please let me know, if you have other examples of context receivers for which special indentation is required. |
* Format context receiver * Add experimental rule "context-receiver-wrapping" Closes #1672
Context receiver was discussed in #1436 and introduced in Kotlin 1.6.20 https://kotlinlang.org/docs/whatsnew1620.html#prototype-of-context-receivers-for-kotlin-jvm
Expected Rule behavior
Ensure that we have context receiver separated from other declarations based on the code examples in https://kotlinlang.org/docs/whatsnew1620.html#prototype-of-context-receivers-for-kotlin-jvm
Of course when context receiver is added to the coding convention, there is a chance that Kotlin coding convention might suggest against the above.
Additional information
The text was updated successfully, but these errors were encountered: