Some comments:

  • If your F# function takes an option type argument, your C# code can pass null instead of None.
  • You can test all types for null by boxing them first.
  • If you really need to generate a null of any type, you could write a simple generic helper function in C#, or -- as long as F# continues to allow inline IL for user code -- use
    let mynull : 'a = (# "ldnull" : 'a #)
By on 4/1/2008 1:25 AM ()

Correction: One shouldn't use null with value types, so the following is safer:

let mynull : 'a when 'a : not struct = (# "ldnull" : 'a #);;

By on 4/1/2008 1:49 AM ()

The design rational is that null values are dangerous (or at least anonying) as there use will generally lead to a null reference exception at some point unless you are very careful. So F# actively discourages them, rather than banning them completely. The option type is a much better way to handle the presents or absence of a value.

Having said that F# should allow you to use null values for other language clients who may want that, the following should work:

1
2
3
4
type IToto = 
  abstract lolo: int -> int

let toto() = ((null:obj):?>IToto)

But it looks like the code generation is a bit buggy at the moment, when I decompile to C# I see:

1
2
3
4
5
public static IToto toto()
{
    int num1 = 0.GetHashCode;
    return null;
}

So just use the inline IL that Stephan suggests for the moment.

By on 4/1/2008 1:57 AM ()

Thanks all for the prompt replies! Agreed that null values are downright dangerous. I've wanted a .NET language for years that let me add a is-never-null to the type system and force-feed that through the call graph. Within F#, I get the heebie-jeebies whenever I call into the framework, wondering if I'll get a null back, and playing within a bigger system, I get similarly wobbly wondering whether someone will pass me a null.

I'm glad to hear I was on the right track but simply running into a code generation issue. I will ponder what I want to do in my code.

While I suppose this might just spur on those who won't think, standard functions in the Option module for going to and from the null/not-null world might at least make these things consistent for everyone. I suspect the logic and the syntax get quite colorful when this conversation extends to nullables. After all, a nullable value type is good and righteous thing in C#. I would imagine something like

MyFavoriteFSharpFunction >> Option.to_nullable

would make for pretty sensible reading.

By on 4/1/2008 2:10 AM ()

You can extend the option module within your namespace using the following

1
2
3
4
5
module Option =
  let to_nullable x =
    match x with
    | Some v -> System.Nullable(v)
    | None -> System.Nullable()   
By on 4/1/2008 4:21 AM ()

What is the type declaration to indicate that a variable might contain null?

I've got a situation where I want to hold a value returned from a call to a .NET function that might return null. Then later test against null -- but the test expression (value <> null) complains "A type parameter is missing a constraint 'when 'a : null"

NOTE: I know that I could wrap it inside a Some, but that adds extra clutter that I'd rather avoid -- by the time I've returned value to caller it won't be null; I'm just marking this local variable so that I can work with an incoming .NET object, which is inherently nullable.

EDIT: I got it to work by using Stephan's "mynull" definition; e.g. (value <> mynull). However, I'd still like a way to mark the variable type itself, rather than using such a work-around.

By on 4/3/2008 12:21 PM ()

The simplest approach to achieve what you want is "box value <> null".

By on 4/3/2008 12:38 PM ()

perfect -- thanks Stephan

By on 4/3/2008 9:15 PM ()

Hi,
you can also use the following trick to get a default value ("null" or 0 in case of integers, etc.) in F#:

1
let a:ISomething = (Array.zero_create 1).[0];;

If you need to initialize a class field to a default value, you can also use following:

1
2
3
[<DefaultValue>]
type SomeClass =
  val mutable sth : ISth
By on 4/1/2008 2:09 AM ()
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