Visual Studio and .NET Framework Home
F# unable to correctly resolve non-generic type when generic type exists with the same name
8/14/2009 1:23:01 AM
User(s) can reproduce this bug
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)
.NET Framework 3.5 SP1
Windows Server 2008
Operating System Language
Steps to Reproduce
Install F# May 2009 CTP.
let test () = System.Console.WriteLine("Test")
type VoidAction = System.Action
let run () =
[[indent]] let (dlg:VoidAction) = new VoidAction(test)
[[indent]] dlg.Invoke ()
do run ()
Compile error System.Action missing type parameters
Correctly compile and run
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 8/26/2009 at 12:53 AM
Thanks, that works.
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.
F# Program Manager
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.
Visual Studio Product Team
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:
type A = System.Action<int>;;
type B = System.Action;;
type A = System.Action<int>;;
type B = System.Action<int,int;;
Both result in error FS0033.
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.
to post a workaround.
Please enter a workaround.
© 2014 Microsoft