I'm trying to make our object/relational mapping library work with F#. The use of this library involves deriving "persistent" classes from the library base classes, decorating them with certain attributes and accessing certain base class functionality.

The persistent classes can have members (field/property combinations) that reference other persistent classes. For the persistence mechanism it's important that on instantiation of the class, the fields are set to standard values - in the case of references to other classes, the expected default value is null.

I read a bunch of threads on the hub about using null values. I briefly tried using option values instead of null, but at the very least this would require changes to our library - the generic Option<T> is simply not recognized as being a persistable type. Next I tried this suggestion:

1

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

This doesn't seem to work (and the compiler complains about the deprecated inline IL anyway). I have a class like this:

1
2
3
4

type Blah(session:Session) = 
    inherit XPObject(session) as base
    
    let mutable artist : Artist = mynull

This gives me this warning: "warning FS0064: This construct causes code to be less generic than indicated by the type annotations. The type variable 'a has been constrained to be type 'Artist'." Then, when I add an additional line:

1

   let mutable album: Album = mynull

... it starts giving me "Error 3 This expression has type Artist but is here used with type Album", quite obviously. I have tried assigning (mynull :> Artist) and (mynull :> Album), but that just makes type inference go wrong in some other way. Perhaps there's a way to annotate this in such a way that it works? It seems weird that mynull is explicitly generic, but type inference can't deal with it automatically.

What other way is there for me to use? I've seen several comments by Don about a request for an attribute that would allow annotating a class to say "I want to be able to use null with this". I'm not entirely clear why this would be a class-based annotation (as opposed to an annotation on the variable), but in any case this sounds really useful for interop scenarios like mine. Are there any news about this feature?

Thanks

Oliver