Add SymbolDisplayGenericsOptions.IncludeArity as an alternative to SymbolDisplayGenericsOptions.IncludeTypeParameters

[ericstj]

Add SymbolDisplayGenericsOptions.IncludeArity as an alternative to SymbolDisplayGenericsOptions.IncludeTypeParameters

[CyrusNajmabadi]

I bring it up because compiler has UseArityForGenericTypes as an internal option currently.

[CyrusNajmabadi]

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.

[ericstj]

Exactly, that's what I'm doing. 👍 I'll close this as I think I have what I need.

[CyrusNajmabadi]

@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?

[ericstj]

Here are two cases:
https://github.com/dotnet/sdk/blob/26854d4fe75c45af1c17e696d98ca4c8b509f170/src/Compatibility/ApiCompat/Microsoft.DotNet.ApiCompatibility/Comparing/SymbolEqualityComparer.cs#L40
https://github.com/dotnet/roslyn-analyzers/blob/b07c100bfc66013a8444172d00cfa04c9ceb5a97/src/PublicApiAnalyzers/Core/Analyzers/DeclarePublicApiAnalyzer.cs#L74

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 typeof and the docID syntax - which both omit the generic parameter names. If there's an existing API we should be using here I can also investigate changing how we produce the key string.

[CyrusNajmabadi]

I'd probably prefer emitting as List`1. So something about wanting emitting the rarity instead.

[ericstj]

I'm not picky on the precise format here. It just needs to represent the number of generic parameters and not their names.

[ericstj]

Maybe we can just use GetDocumentationCommentId. That does format like we'd want. I might give it a try and see if its' reasonable.

[ericstj]

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.

[ericstj]

Looks like GetDocumentationCommentId isn't sufficient as this omits return value. I think exposing UseArityForGenericTypes would work for us.

[ericstj]

Ok I tested out using UseArityForGenericTypes by setting through reflection. This worked well for classes, but not methods. I would also like a similar setting for methods.

[ericstj]

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.

[ericstj]

Actually, I see there's a SymbolDisplayParts API, that might be a better way to handle this. I'll experiment with that.

[CyrusNajmabadi]

And with the SymbolDisplayParts, you can see which are TypeParameter symbols. And you could elide those or transform them into anything you want.