Exclude a specific extension from documentation

[a-docc-user]

Feature Name

Exclude a specific extension from documentation

Description

I would like to conformances to e.g. CustomDebugStringConvertible not show up in documentation because my package uses those conformances a lot and they generate noise.

Motivation

see above

Importance

A description of the importance of this change.

Does this feature unlock entirely new use-cases? Or is it possible to achieve the same functionality with existing functionality and this change would improve the user experience?

Alternatives Considered

[d-ronnqvist]

Hi. Thank you for this issue and the other 3 recent enhancement requests issues.

Please try and follow the "enhancement request" issue format. The questions in the "new issue" form exist to guide people to report use-case focused enhancements that provide input to discussions about both possible implementations and about prioritization.

For example, my understanding of this described use-case is that a reader of the documentation would like to know what API is unique to a given symbol and what API is available for that symbol because it conforms to various protocols.

For that use-case there are some things the documentation author can do with existing functionality to achieve some of those goals. For example, the documentation author could curate key API into "topic sections" of related functionality which has the benefit of both grouping related API and of listing these symbols above the uncurated API for that symbol.

With some more examples of symbols with different amounts of conformances it would be interesting to discuss how the presentation of API from conformances could be updated to make the documentation easier to read. There's a tradeoff here between reducing noise and between surfacing all the API that's available for a symbol in some way or another.

For example, I would find it harder to read the Array documentation if it didn't list API like enumerated() (from the Sequence protocol), reversed() (from the BidirectionalCollection protocol), isEmpty (from the Collection protocol), or append() (from the RangeReplaceableCollection protocol).

A good understanding of the broader use-case is necessary to know that the proposed solution solves that use-case well or to know if there are alternatives that solve that use-case better.

[a-docc-user]

I mean I want to delete this

how can i do this