-
Notifications
You must be signed in to change notification settings - Fork 124
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
Typealiased type are not reflected properly in the documentation #718
Comments
Hi @d-ronnqvist, Any idea if this is a user error or something that should be fixed ? Thanks, |
One could argue that this is the correct behavior because the type alias isn't its own symbol, and any extension you add to the aliased symbol are also available on the aliased type. In other words; in source code you can still call That leaves the question of what should be displayed on the page for the type alias. Currently the alias doesn't display any members of the type that it is an alias of. We could choose to duplicate all the members from the aliased type but I'm not sure that would be better. For example, say that a developer defines an alias for readability public struct Record {
public typealias Identifier = Int
} IMO the most important information on the |
I do understand your point of view, and I agree that a typealias is not a real type. However, when you can extend a typealias, I believe this code should be included in the typealias documentation. As suggested, I will post on the forum to gather input from other people. Thanks, |
I'm not sure whether to raise a separate issue or ask for help in the forums but I'm facing a similar problem where I cannot reference public symbols in extensions for typealiases of generic types (struct or class). In the scenario posted here I can't reference In my scenario I'm adding dependency injection namespaces via a generic and typealiases. From a code perspective the namespaces work as expected only exposing properties per specialised typealias. From a docs perspective I cannot reference these and they're all grouped under the single generic. I know I can replace the specialised types with concrete types to solve this but am looking to avoid that. |
Description
In the situation below the generated documentation is wrong because
Foo
should have theInitializers
andType Properties
in it's documentations and notGeneric
.Checklist
main
branch of this package.Expected Behavior
Foo should have the
Initializers
andType Properties
in the documentation.Actual behavior
Generic
display having theInitializers
andType Properties
in the documentation.Steps To Reproduce
Xcode Version 15.0 (15A240d)
Swift-DocC Version Information
swift-5.9-RELEASE
Swift Compiler Version Information
The text was updated successfully, but these errors were encountered: