-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Add SymbolDisplayGenericsOptions.IncludeArity as an alternative to SymbolDisplayGenericsOptions.IncludeTypeParameters #73051
Comments
@ericstj I'm not quite getting the use case. CAn you flesh out the example more, including where generics are used today, and why the actual type argument values are a problem? |
Here are two cases: It's actually non-breaking to change the name of a type parameter, however we'd like to make that an optional rule that folks can enable. To do this we'd like to have a symbol representation that omits the generic parameter names, but still represents the arity. That way we can create a key that represents the API without including non-essential information (parameter names). It's a similar scenario to the format of |
I'd probably prefer emitting as |
I'm not picky on the precise format here. It just needs to represent the number of generic parameters and not their names. |
I bring it up because compiler has UseArityForGenericTypes as an internal option currently. |
Maybe we can just use GetDocumentationCommentId. That does format like we'd want. I might give it a try and see if its' reasonable. |
One downside I see for swapping to different methods for this is that we call it a lot. So much that I've been thinking about adding a cache for these strings. It would be nice if ISymbol would cache some of these. Maybe we should wrap all the ISymbol interfaces and add caching for the methods/properties we call the most. |
Looks like GetDocumentationCommentId isn't sufficient as this omits return value. I think exposing UseArityForGenericTypes would work for us. |
Ok I tested out using |
in cases like this, where you're making a domain-specific key, our recommendation usually becomes: figure out what your domain needs, and extract out of the symbols. We're unlikely to add a feature (like for methods) that nothing else uses. We end up just chasing how the feature works, as opposed to some facility intrinsic to what the language is modeling. |
I was able to make this work by combining the DocId with the DocID of the type/return-value for members. This gives me what I need. |
Actually, I see there's a SymbolDisplayParts API, that might be a better way to handle this. I'll experiment with that. |
And with the SymbolDisplayParts, you can see which are TypeParameter symbols. And you could elide those or transform them into anything you want. |
Exactly, that's what I'm doing. 👍 I'll close this as I think I have what I need. |
Background and Motivation
Today the only value for SymbolDisplayGenericsOptions that shows the number of type parameters is
IncludeTypeParameters
which includes all the parameter names.Parameter names are not strictly speaking part of the surface area. Derived types can use different parameter names, and changing the generic parameter name is not breaking.
APICompat uses SymbolDisplayGenericsOptions when producing a comparison key for API. PublicApiAnalyzer does as well. As a result both of these tools prohibit changing the name of a generic parameter.
Proposed API
Usage Examples
Expected output:
Alternative Designs
Some alternate API for rendering a symbol - like fetching a DocID or using SyntaxGenerator.
Risks
The text was updated successfully, but these errors were encountered: