update: add limitations for open expect classes (KT-22841) #4176
Conversation
| @@ -399,6 +399,24 @@ typically provides an expected `CommonViewModel` class whose actual Android coun | |||
| from the Android framework. See [Use platform-specific APIs](multiplatform-connect-to-apis.md#adapting-to-an-existing-hierarchy-using-expected-actual-classes) | |||
| for a detailed description of this example. --> | |||
|
|
|||
| #### Limitations of open expected classes | |||
There was a problem hiding this comment.
I don't know if it's common in our documentation, but "expected" feels wrong to me.
expect is a keyword and converting it to the adjective sounds incorrect
There was a problem hiding this comment.
I don't disagree, and I avoided using the adjective in the text. But writing "expect classes" in the title, when we cannot highlight the keyword, reads like a grammar mistake. All the rest of the modifiers I can remember are adjectives to begin with (internal, abstract, actual...), so they don't have this problem. Here, we need a compromise.
Right now the concept we introduce on the page is "expected declarations," and that's the convention. I think it's possible to have clearer terminology here. We'll keep thinking about this.
|
In the end we decided not to highlight these limitations in docs: they are easily dealt with with compiler's help, and shouldn't affect too many people. https://youtrack.jetbrains.com/issue/KT-22841 has the history of the problem and decision-making. |
Clarifying the limitations of actualizing an open expect class.