@_nodoc attribute for hiding symbols from the symbol graph

[taylorswift]

@QuietMisdreavus

At least forceVisible needs to be special-cased, due to needing to override the underscored-symbols behavior. And forceHidden will need to be special-cased with the current implementation of @_exported import statements because arbitrary attributes cannot be read in the compiler when these are being processed.

i don’t know how the compiler parses attributes, but would it be possible to make “magic” cases like forceVisible and forceHidden be recognized by the compiler, while still allowing for a larger set of possible user-defined values?

@QuietMisdreavus

Including internal implementation details on the off chance that someone trying to figure out how to use a package gets interested in improving it just clutters the experience for the majority of people. If you would like to propose a design for integrating "public" documentation with "internal" documentation and making them distinct, please do so in a new thread. As it stands, i feel like that would be a larger change to the precedent of documentation tooling in general to slip into this discussion.

i think the underlying question here is whether a symbolgraph should be a single artifact containing “all of the information” about a module at a given time, or whether we should have different ‘flavors’ of symbolgraphs for different purposes. i can see two possible directions here:

1. symbolgraph is an archive: we generate a single (collection) of symbolgraphs per package revision (e.g. in a CI workflow), and then downstream tooling subsets parts of the archive “for contributors”, “for users”, etc.

2. symbolgraph is an interchange format: we generate symbolgraphs on-the-fly, with different contents depending on the intended usage. this is the workflow that @ethankusters proposed, where you would build separate symbolgraphs and then deploy the rendered output for different audiences.

i don’t know which of these is better, as there are pros and cons to both. but i don’t really see this as a “rights of the majority” dispute since the end product would probably be similar once post-processing happens.