-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Signature info gets incomprehensible in presence of extension methods, generics and tuples #33609
Comments
One idea would be to calculate some metrics that determines complexity of signature with substituted generic parameters. If the metric is greater than some threshold introduce aliases for repeated types. Something like: t ::= (DocumentId DocumentId, ImmutableArray<LineChange> Deltas) ImmutableArray<TResult> ImmutableArray<t>.SelectAsArray<t, TResult, TArg>(Func<t, TArg, TResult> map, TArg arg) |
@cartermp It seems that F# would have similar issue. Is there some technique you're using to simplify signature info for complex types? |
We already do this for anonmous types. Seems like it might make sense to just expand this out to tuples int he same manner all the time. Maybe for the simplest tuples we wouldn't have to. But it seems like it would be generally necessary the moment you get any complexity. |
@tmat we wrap docs, but we can also get some explody-looking tooltips as well 😢 We do extract the concrete type in tooltips: But it's not 100% consistent: So I'd say it needs "PM work", but as the first screenshot shows, the tooltip can still be rather large. |
@CyrusNajmabadi You fixed this issue in #56025, so it should be closed now |
SGTM! :) |
The displayed signature of
SelectAsArray
extension method is:It's really hard to parse this when choosing between overloads of the method. We should think about better visualization of complex signatures.
The method itself is conceptually simple - it takes a lamda and applies it to elements of immutable array, but this is completely lost in the signature info. The problem is most apparent when tuples are substituted to generic parameters of Funcs.
The text was updated successfully, but these errors were encountered: