Documentation comments
KDoc on an exported Kotlin declaration becomes an XML doc comment (///) on the matching generated C# declaration, so a bound member's <summary>, <param>, <returns>, and <exception> show up in the consumer's own IDE. Nothing needs to be written differently in Kotlin to get this.
The second overload above is the omitting overload suite's default synthesizes; it keeps the doc but drops the <param> it has no parameter for.
What carries a doc comment
Every generated declaration that mirrors a documented Kotlin one: a class, object, interface (and its members), enum (and a documented entry), sealed base and arm, value class, constructor (including a secondary one), method, property, extension function, top-level function, and the Async projection of a suspend function (see Coroutines and Flow).
Tag mapping
KDoc | C# |
|---|---|
body, first paragraph |
|
|
|
|
|
|
|
| no doc comment on that declaration at all |
everything else ( | dropped |
Every parameter gets a tag, or none do
C# requires either every parameter of a member to carry a <param> tag or none of them to (otherwise an IDE, and this project's own build, sees a partial set as a defect, CS1573). A partially-documented member still gets a tag for the parameter it didn't document, just an empty one:
The same rule covers the cancellationToken parameter the generator adds to a suspend function's Async projection: there's no Kotlin @param for it, so it gets an empty tag too, next to the Kotlin parameters that do have one:
@suppress opts a declaration out
SecretTreat() still generates and works exactly as before; it just has no /// block at all. @suppress anywhere in the comment drops the whole thing, including any @param/@return on the same declaration.
What doesn't carry a doc comment
A dependency (klib) declaration renders undocumented. KSP reads no KDoc from compiled metadata, so a type reached only through a dependency module carries no comment in the generated C#, however it was documented at its own source.
Only the first paragraph survives. A later paragraph, a
`code span`, a[link],@property,@constructor, and@seeare all dropped rather than rendered as something misleading; keep the summary line self-contained.A Kotlin
object's own property has no C# surface at all (unrelated to documentation, see ROADMAP.md), so there's nothing generated for its KDoc to attach to either.
expect/actual
KDoc written on an expect declaration reaches the generated C#, even though the actual Kotlin compiles against typically carries none of its own:
See expect/actual declarations for how the two sides otherwise relate.
No separate documentation file to pack
The generated shim ships as source (see Publishing Kotlin to C#), so there is no lib/<tfm>/*.xml documentation file in the package: turn on <GenerateDocumentationFile>true</GenerateDocumentationFile> in the consuming project and these entries show up in its own IntelliSense. A malformed comment (an unresolvable cref, a partial <param> set, mismatched tags) would already have failed the library's own build before the package was published, so nothing here can reach a consumer broken. This mapping mints no handle and changes no ABI: it costs nothing at the crossing, only at compile time.