You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Sources/docc/DocCDocumentation.docc/Documenting API with different language representations/documenting-api-with-different-language-representations.md
+67-6Lines changed: 67 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ When a symbol has different parameters or return values in different source lang
38
38
```objc
39
39
/// - Parameters:
40
40
/// - someValue: Some description of this parameter.
41
-
/// - error: On output, a pointer to an error object that describes why "doing somehting" failed, or `nil` if no error occurred.
41
+
/// - error: On output, a pointer to an error object that describes why "doing something" failed, or `nil` if no error occurred.
42
42
/// - Returns: `YES` if "doing something" was successful, `NO` if an error occurred.
Because the Swift representation of this method only has the "someValue" parameter and no return value, DocC hides the "error" parameter documentation and the return value documentation from the Swift version of this symbol's page.
54
54
55
+
@Row {
56
+
@Column {
57
+

58
+
}
59
+
@Column {
60
+

61
+
}
62
+
}
55
63
56
-
You don't need to document the Objective-C representation's "error" parameter or Objective-C specific return value for symbols defined in Swift.
57
-
DocC automatically adds a generic description for the "error" parameter and extends your return value documentation to describe the Objective-C specific return value behavior.
58
-
59
-
If you want to customize this documentation you can manually document the "error" parameter and return value.
64
+
You don't need to document the Objective-C representation's "error" parameter or the Objective-C specific return value for methods that correspond to throwing functions in Swift.
65
+
DocC automatically adds a generic description for the "error" parameter for the Objective-C version of that symbol's page.
66
+
If you want to customize this documentation you can manually document the "error" parameter.
60
67
Doing so won't change the Swift version of that symbol's page.
61
-
DocC will still hide the parameter and return value documentation that doesn't apply to each source language's version of that symbol's page.
68
+
69
+
When the Swift representation returns `Void`---which corresponds to a `BOOL` return value in Objective-C (like in the example above)---DocC adds a generic description of the `BOOL` return value to the Objective-C version of that symbol's page.
70
+
71
+
@Row {
72
+
@Column {
73
+

74
+
}
75
+
@Column {
76
+

77
+
}
78
+
}
79
+
80
+
When the Swift representation returns a value---which corresponds to a `nullable` return value in Objective-C---DocC extends your return value documentation, for the Objective-C version of that symbol's page, to describe that the methods returns `nil` if an error occurs unless your documentation already covers this behavior.
81
+
For example, consider this throwing function in Swift and its corresponding Objective-C interface:
82
+
83
+
**Swift definition**
84
+
85
+
```swift
86
+
/// - Parameters:
87
+
/// - someValue: Some description of this parameter.
88
+
/// - Returns: Some general description of this return value.
For the Swift representation, with one parameter and a non-optional return value,
100
+
DocC displays the "someValue" parameter documentation and return value documentation as-is.
101
+
For the Objective-C representation, with two parameters and a nullable return value,
102
+
DocC displays the "someValue" parameter documentation, generic "error" parameter documentation, and extends the return value documentation with a generic description about the Objective-C specific `nil` return value when the method encounters an error.
103
+
104
+
@Row {
105
+
@Column {
106
+

107
+
}
108
+
@Column {
109
+

110
+
}
111
+
}
112
+
113
+
> Tip:
114
+
> If you document the Objective-C specific `nil` return value for a method that corresponds to a throwing function in Swift,
115
+
> but don't provide more information to the reader than "On failure, this method returns `nil`",
116
+
> consider removing that written documentation to let DocC display its generic description about the Objective-C specific `nil` return value,
117
+
> only on the Objective-C version of that symbol's page.
118
+
119
+
The return value documentation you write displays on both the Swift and Objective-C versions of that symbol's page.
120
+
DocC won't add its generic `nil` return value description to the Objective-C page,
121
+
if your return value documentation already describes that the method returns `nil` when it fails or encounters an error,
122
+
but that Objective-C specific documentation you've written will display on the Swift version of that page where the symbol has a non-optional return type.
62
123
63
124
<!-- Copyright (c) 2024 Apple Inc and the Swift Project authors. All Rights Reserved. -->
0 commit comments