-
Notifications
You must be signed in to change notification settings - Fork 506
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: