Back to Questions
1.2k
views6
comments
Odd problem with generic methods
f#compiler

I encountered a somewhat strange issue with generic methods of a class. The following code works fine

1
2
3
4
5
6

type GenericTest() =
    member s.DrunkVision (x:'a) = x, x
   
let gt = GenericTest()
printfn "%A" (gt.DrunkVision 1)
printfn "%A" (gt.DrunkVision 1.0)

However, if I add a new method within the class definition that uses a particular reification of DrunkVision, it breaks:

1
2
3
4
5
6
7

type GenericTest() =
    member s.DrunkVision (x:'a) = x, x
    member s.DoubleDrunkVision () = s.DrunkVision 1.0
   
let gt = GenericTest()
printfn "%A" (gt.DrunkVision 1)
printfn "%A" (gt.DrunkVision 1.0)

Now the compiler complains that "This construct causes code to be less generic than indicated by the type annotations. The type variable 'a has been constrained to be type 'float'." and consequently reject the call of DrunkVision with an int. What's happening?

.

I don't have a reference for this, but I think I remember reading that <i>members<i> cannot be more generic than their class -- or some such limitation. If you use a let bound function you'll be fine: <code lang=fsharp> type GenericTest() = let dv x = x,x member s.DrunkVision x = dv x member s.DoubleDrunkVision () = dv 1.0 let gt = GenericTest() printfn "%A" (gt.DrunkVision 1) printfn "%A" (gt.DrunkVision 1.0) </code> I'd be nice if someone references which part of the spec has this, and the reasoning for it.

By on 7/14/2009 4:06 PM ()

<quote> I don't have a reference for this, but I think I remember reading that <i>members<i> cannot be more generic than their class -- or some such limitation. </quote> I don't think that's it - I think in this case it's the "all members are implicitly let-rec" and the way let-rec'd type equations get solved. I think that adding a complete signature to the generic method, e.g. member s.DrunkVision<'a>(x:'a) : 'a*'a = x,x would solve it (a full signature will always be taken 'as given' and stop the recursiveness from seeing certain instantiations in method bodies and thus making things get fixed at a specific (less generic) type). But I haven't tried this on Beta1 to know for sure. All that said, on my current internal bits at work, this now 'just works' - offhand I don't recall the change for this, but I guess maybe sometime since Beta1 Don has gone and fixed something here that I've forgotten about. Perhaps he'll weigh in on this thread.

By on 7/14/2009 4:50 PM ()

Hmm ok. That makes more sense. Do you have any idea what I was talking about? I remember there being some sort of additional constraints for generics that stuck out... but I might have just dreamt that.

By on 7/15/2009 7:20 PM ()

Wow, I was way off here... closest phrasing I could find was this [link:cs.hubfs.net] -- that's just mentioning the design limit .NET has where constructors and properties can't be more generic than the class. Not sure why I thought this was relevant. Sorry!

By on 7/16/2009 2:06 PM ()

Yep, that does work! Thanks!

By on 7/15/2009 1:09 PM ()

What made me wonder is that I only seem to get in trouble when I use the generic method from within the class that defines it. The first example works fine.

Actually, let's see what happens if we put the output of the first example through Reflector:

1
2
3
4
5
6
7
8
9

[Serializable, CompilationMapping(SourceConstructFlags.ObjectType)]
public class GenericTest
{
    // Methods
    public Tuple<a, a> DrunkVision<a>(a x)
    {
        return new Tuple<a, a>(x, x);
    }
}

So this seems to spit out an actual generic method in the compiled assembly even though the class isn't generic. I wonder what changes if I want to call that same method from within the class.

By on 7/14/2009 4:20 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper