Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
type A = int -> int
Hover A. You'll just see the full name, not the actual definition that helps you.
Also see screenshot.
Created attachment 12295 [details]
This also applies to type aliases:
type Id = string
Hovering just gives the full name of Id.
How annoying, must be upstream breaking changes in FCS, as nothings changed elsewhere.
Actually maybe these are entirely new cases that dont have an implementation.
What should be shown for:
type Id = string
Created attachment 12296 [details]
Just like the others.
What should be shown? Well, perhaps:
type Id = string
Full name: Qvi.Id
And for the lambda:
type F = string -> unit
Type Alias / Function
Full Name: Qvi.F
afaik type alias don't have any special tips shown in VS, saying that we dont mirror that behaviour for tips in VS anymore now that the tooltips have been overhauled.
Well, to me it's a regression for XS, which used to show them to me... Don't you agree that it's very useful? Especially if you name your functions with type names to make the APIs easier to understand.
For this reason I don't reccomend using type alias, it leaves you guessing to the real identity of the type.
Not if everything speaks in terms of the type alias and you have factory methods that can create the type alias anew. This is the case when using a library, but not when constructing the library, which is my case.
Besides that, it's a way to safeguard against API changes; as long as I, the consumer of the library return this type alias, and especially if I do so with the library-supplied functions, I can be sure that my code is correct even when the underlying library undergoes changes.
Finally, I believe even Don himself has commented on that he should have used more type alias in the F# compiler to keep track of the string-value/contents easier.
So they absolutely have their use-cases. Just look at how easy and nice WebPart is to use from Suave to see that.
I think it comes down to personal choice and the power of tools. I noticed that type alias were not represented well in VS when I first started learning F# in 2010 the the experience was pretty awful. The tooltips in XS have been carefully redeveloped to try and improve the experience, nothing has changed in the 5.9 line of code for quite some time, so anything you are seeing is from changes in new versions of FCS.
Its possible that this is not an issue in the XS6.x line as there has been a lot of changes there.
Created attachment 14180 [details]
Type alias tooltip
Created attachment 14181 [details]
lambda type tooltip
These issues are fixed in 6.0