Comments on: Oddities in F#/C# interaction

by: Oliver Sturm

Sat, 17 May 2008 14:19:27 +0000

Thanks, that might be a good idea - can’t try right now - since I’ve already found another workaround that involved putting int(v) to the function instead of v on its own. For certain other reasons (I want to do CodeRush templates for this, and there are certain type translation algorithm not in place yet for F#) I couldn’t use that workaround. Having the type constraint in the place you’re suggesting will probably solve the problem for me.

I hope you guys are taking these things up as bugs though - so far I haven’t heard anybody saying "it works exactly as expected and here’s why"!

Thanks for all your help, Brian - sounds like you’ve really dug in by now - in the F# session at the MVP summit you came over just a little bit nervous and I understood it was due to a certain lack of experience at that point

by: BrianMcNamara

Sat, 17 May 2008 13:21:48 +0000

Sorry, I haven’t been able to log into the hub lately to reply.
In your overload example, you have a setter with "set(v)", but "v" is unconstrained. If you constrain it to be "int" (rather than ‘a), then it will work: "set(v:int)". That should explain why it’s happening, too.
This is a case where hovering over the variable name with the mouse in Visual Studio to see the type helps a lot.

by: Oliver Sturm

Sat, 17 May 2008 12:07:51 +0000

Brian, if you’re reading these comments - do you have any thoughts on the original "resolve overload conflict problem"? I’m not getting any feedback on hubFS, should I report this somewhere else? What’s the right place to go for that?

by: Oliver Sturm

Sat, 17 May 2008 12:02:38 +0000

Okay, I think I solved this latest problem. I changed the helper function to this signature:

member public x.SetPropertyValueFS(propertyName, (oldVal: ‘a byref), (newVal: ‘a)) =

That makes it compile correctly - haven’t tested functionality yet. And the "byref" keyword is another thing I haven’t found documented anywhere… I just guessed from the error message that there could be such a keyword.

by: Oliver Sturm

Sat, 17 May 2008 10:32:17 +0000

Hi Brian,

Thanks for the info with the &var style parameter passing - haven’t seen than anywhere before! I tried it in a simple test and it works, but I’m still having problems in my precise use case - with a member like this:

member public x.Age
with get() = x.age
and set(v) = x.SetPropertyValueFS("Age", &x.age, v) |> ignore

I’m getting a weird error: "Error 3 Type constraint mismatch. The type ‘b byref is not compatibile with type ‘a ref. The type ‘’b byref’ is not compatible with the type ‘’a ref’."

For the second problem though - yes, I can see where that problem comes from with curried parameter lists (if you accept that capturing the protected method isn’t allowed). Your suggestion solves my problem, so thanks for that! I still don’t understand what makes that particular call so problematic, since the same thing works in simple tests I did…

by: Brian McNamara

Sat, 17 May 2008 03:20:39 +0000

I think if you don’t curry the arguments
member public x.SetPropertyValueFS(propertyName, oldVal, newVal) =
then it will work. When they’re curried, this effectively makes the .NET method take one argument and return a lambda or the rest of the arguments, and that lambda is capturing a call to a protected method. For reasons that are still unclear to me, that’s not allowed. But you can work around it simply by making the method take parameters "(like, this)" rather than "like this".

by: Brian McNamara

Sat, 17 May 2008 02:45:18 +0000

FYI, you can pass ‘by ref’ using the prefix ‘&’ operator on a mutable:

#light

open System.Collections.Generic

let mutable x = 1
let d = new Dictionary()
d.Add("foo", 42)
if d.TryGetValue("foo", &x) then
printfn "x = %d" x