`Tracking`: F# Hints
Note This is a "meta" issue for tracking purposes since GitHub does not support special types of issues.
Supersedes #10289.
We'll be introducing a feature called F# hints. It is inspired by C# inline hints but will do more! The feature is going to be built on top of the dedicated Roslyn API.
This will supersede the experimental CodeLens feature that is current present in Visual Studio. The CodeLens brand in F# is planned to do the same as in other languages, i.e. show references, test coverage and so on (details here).
The plan is to gradually add different hints and make them configurable. Here is the proposed roadmap:
- https://github.com/dotnet/fsharp/issues/14158 (experimental)
- https://github.com/dotnet/fsharp/issues/14174 (experimental)
- Remove CodeLens in its current form: #14256
- #14259
- #14447
- Move out of the experimental mode to the preview mode
- #14385
- #14448
- #14382
- #14379
- #14260
- #14268
- #15157
- Move out of the preview mode
- #15131
- Implement signature hints
- Implement pipeline hints
Bugs:
- #14269
- #14393
- #14400
- #14401
- #14378
- #14459
- #14460
- #14885
- #15138
- #15576
- #15994
Can hints themselves have tooltips? This here looks like an empty one:

It would be nice to reuse type annotation tooltips with all the good stuff like clickable references:

(Sorry if this is not the place for a Hints discussion)
Looks like a function needs to be passed in https://github.com/dotnet/roslyn/blob/315c2e149ba7889b0937d872274c33fcbfe9af5f/src/Tools/ExternalAccess/FSharp/InlineHints/FSharpInlineHint.cs
Also I've noticed that GetInlineHintsAsync is invoked twice after one keystroke. Is it a Roslyn thing?
I think it's a great idea, we should make hints interactive if we can.
Sorry if this is not the place for a Hints discussion
This IS a place for hints discussion :)
Can hints themselves have tooltips?
I think so. As long the information doesn't aggressively jump on the user, it's only helpful.
Also I've noticed that GetInlineHintsAsync is invoked twice after one keystroke. Is it a Roslyn thing?
On the one hand, it sounds suspicious, on the other hand, I don't have an idea what in our code can trigger this, we have a very thin layer now. I will investigate.
This is probably bug on Roslyn side, but hints won't go away when you release Alt+F1, unlike in C# editor.
This is probably bug on Roslyn side, but hints won't go away when you release Alt+F1, unlike in C# editor.
No, it's not implemented yet. Tracked in https://github.com/dotnet/fsharp/issues/14260
It would be nice if a Numerics.BigInteger would be shown as bigint instead.
Not sure if there are any other similar types.
Is there already some sort of mapper to simplify names? In that case I could maybe have a go at it.
@raymens so, that's an interesting thing and it also applies to the tooltips. You get the full type name there unless you have specified in the opens. Take a look:
https://github.com/dotnet/fsharp/assets/5451366/64ddec02-85d6-4bd1-8e26-7bfbc8733663
This somewhat makes sense to me. Also this means that probably in many cases you'd have the short types there. WDYT?
That said, the tooltips for the hints themselves show the short type anyway:
This is inconsistent and worth fixing.
Now, as for the mechanics of that, I think this is not a big deal and basically just depends on what info you take from the symbol:
I think his point is that BigInteger should behave like Int32 does, where we don't use the .NET name but the F# one.
According to https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/basic-types, bigint is an abbreviation, but the type itself does not count as a basic F# type.
Oh, that thing. Well so the docs above pretty much answers the question :)
I am on a fence then. We can technically hardcode this conversion in the code but, given that this seems to be the only thing of that nature - and it's not very common I guess - not sure if it's worth it.
Thanks for the detailed explanation.
I was indeed mostly referring to the (to us highly used) bigint abbreviation.
Maybe the solution is to consider bigint a basic type instead... considering it's the only one apparently. However I'm going off-topic and there's probably reasons why that's the case.
Well, that's because it's arguably not that basic :)
I think, yeah, just mapping this type to its short form would be sufficient. I would be up for having it. Feel free to jump on this, or we can create a ticket and someone will eventually pick it up.