F# unable to correctly resolve non-generic type when generic type exists with the same name - by SteveH_UK

Status : 


Sign in
to vote
ID 482934 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 8/14/2009 1:23:01 AM
Access Restriction Public


I was trying to create a type alias for System.Action (void -> void) to represent the F# function type (unit -> unit) but F# complained that System.Action was missing a type parameter, i.e. Action<'a> ('a -> void/unit).  In the end, I had to create my own delegate: "type VoidAction = delegate of unit -> unit".

(Visual Studio 2008 with F# May 2009 CTP)
Sign in to post a comment.
Posted by SteveH_UK on 8/26/2009 at 12:53 AM
Thanks, that works.
Posted by Microsoft on 8/21/2009 at 1:35 PM
Hi Steve -

This is actually a combination of By Design, Fixed and an outstanding suggestion we're tracking for a future release.

In .Net3.5, the different versions of Action with different generic arrities are defined in different assemblies. Action<T> is defined mscorlib, but Action, Action<T,U>, Action<T,U,V>, etc. are defined in System.Core.dll.

The F# interactive does not reference System.Core.dll by default, so some of these are not found in the default F# interactive experience. You can reference System.Core.dll from the F# Interactive with #r "System.Core.dll". We expect to add System.Core.dll to the set of automatic references in a future release of the F# Interactive.

In .Net4.0, all the Action overloads are being moved into mscorlib, using Type Forwarders, which will solve this particular issue for the VS2010 F# Interactive.

Luke Hoban
F# Program Manager
Posted by Microsoft on 8/19/2009 at 2:57 AM
Thanks for your response. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by SteveH_UK on 8/17/2009 at 10:56 PM
Apologies, the behaviour is slightly more complex than I thought. The first resolution works, but subsequent resolutions follow the pattern of previous resolutions. So, once Action is found to have a single type argument, other forms do not work.

The following examples are in the FSI interpreter with no previous history:

Example 1:

type A = System.Action<int>;;
type B = System.Action;;

Example 2:

type A = System.Action<int>;;
type B = System.Action<int,int;;

Both result in error FS0033.

See attached
Posted by Microsoft on 8/17/2009 at 12:07 AM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided. Could you please provide us with a demo project that can be used to reproduce this issue? or please provide snapshots about this issue.

Thank you,