-
Notifications
You must be signed in to change notification settings - Fork 30
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
SUBTYPES abbreviation #47
Comments
Revisiting this issue, I am wondering about the utility of this abbreviation, as subtypes of a type is an essentially dynamic value that may change when new code is evaluated (eg a package is loaded). Eg if it ends up in statically generated documentation (by Documenter.jl) it can easily be inaccurate. Thoughts? I am thinking of just closing this issue. |
That's a fair point. Maybe it should filter by module somehow? |
That does seem like a reasonable approach, e.g. the printed out types are all subtypes of the documented type that are defined within the type's defining module or any of it's submodules and any external modules that further subtype it are not included. We could print out something to that effect as an admonition in the expanded abbreviation to warn readers. |
It may be useful to add a
SUBTYPES
abbreviation that expands to something likeThe text was updated successfully, but these errors were encountered: