F# Generic Inlining With Member Constraints

by Marc Sigrist 13. July 2012 16:05

In this post, we are going to create a Converter class who converts values to strings. The conversion rules are speciļ¬ed by passing the name of a culture to the class’ constructor. The culture name can contain just the language (as ISO 639-1 alpha-2 code, e. g. “en”) or the language and region (as ISO 3166 code, e. g. “US”) combined with hyphen, e. g. “en-US”. An empty culture name “” specifies the invariant culture, which falls back to “en”.

The class has only one conversion method ToString, who is generic. It takes a single parameter, which is the value to be converted. The parameter’s type is inferred to have a member constraint, who restricts the type (at compile time) to have an instance member with the signature
ToString: IFormatProvider -> string. The parameter’s member is invoked with a member constraint invocation expression.

open System
open System.Globalization
type Converter(cultureName:string) =
    /// The culture used by this converter.
    member val Culture = CultureInfo.GetCultureInfo cultureName

    /// Converts value to a string, based on the specified culture.
    member inline self.ToString value =
        (^T: (member ToString: IFormatProvider -> string) 
        value, self.Culture)
// Test
let germanConverter = Converter "de"
let nrString = germanConverter.ToString 1234.643  // "1234,643"
let dtString = germanConverter.ToString <| 
               DateTime(2003, 11, 25, 17, 38, 47) // "25.11.2003 17:38:47"

Edit (Oct 15, 2012)

 The converter's culture is now exposed via a public property, based on F# 3.0 auto property syntax. (The Culture's value is evaluated only once, during class construction time.) Previously, the culture was a private field, and the example could not compile in a regular source file, due to access rule violation. Strangely, it did compile in a scripting file; this is an example where the scripting compiler (wrongly) does not behave in the exact same way as the regular compiler.

This is a blog post in the “Brief tip” category. It is meant as a starting point for further investigation, not as a complete copy/paste solution to a specific concern you may have.

Declaring class constructors in F# 2.0, also considering singletons

by Marc Sigrist 19. October 2010 23:53

In F#, class constructors can be declared in several different ways. To declare a non-static class, one usually defines a primary constructor, plus zero or more additional constructors. To declare a static class, one usually defines a module.

Using a Primary Constructor

In F#, it is possible to create a thread-safe singleton with just three lines of code:

/// A public thread-safe singleton class in F#,
/// using a private primary constructor.
type Singleton private() =
    static let instance = Singleton()
    static member Instance = instance
// This would be the equivalent code in C#:
public class Singleton{ 
    static readonly Singleton instance = new Singleton(); 
    Singleton() {} 
    public static Singleton Instance {get { return instance;}} 

In the above F# example, private() defines an empty primary constructor. Using a primary constructor is the recommended practice for non-static classes in F#. According to the F# 2.0 Language Specification, section 8.6.4., any additional constructors must call the primary constructor (either directly or indirectly), as in the following example:

Using a Primary Constructor and an Additional Constructor

/// A public Person class in F#,
/// using a public primary constructor
/// and an additional public constructor.
type Person(name: string, guid) =
    new(name, guid) = Person(name, Guid.Parse(guid))
    member x.Guid = guid
    member x.Name = name
// This would be the equivalent code in C#:
public class Person{
     readonly string name;
     readonly Guid guid;
     public Person(string name, Guid guid){
          this.name = name;
          this.guid = guid;
     public Person(string name, string guid):
          this(name, Guid.Parse(guid)){
     public Guid Guid {get {return guid;}}
     public string Name {get {return name;}}

Using Only "Additional" Constructors

It is also possible to define classes in F# with only "additional" constructors, but no primary constructor. However, the available syntax for the rest of the class is quite restricted. Primary constructors should only be avoided when there is a very compelling reason to do so, e.g., to simplify automatic code generation. The following, modified Singleton example shows some of the difficulties you may face when avoiding a primary constructor:

/// This type is intended for private use within Singleton2 only.
type private SyncRoot = private new() = {}
/// A singleton with no primary constructor.
type Singleton2 =
     // As we cannot use implicit ("let"-bound) fields, we have to
     // use explicit ("val"-bound) fields. However, explicit fields
     // who are static must also be default-initialized, mutable, and private.
     static val mutable private instance: Singleton2
     private new() = {}
     // As we cannot rely on the inherent thread safety of non-mutable
     // let-bound fields, we have to apply a lock.
static member Instance = lock typeof<SyncRoot> (fun() -> if Unchecked.compare Singleton2.instance Unchecked.defaultof<Singleton2> = 0
then Singleton2.instance <- Singleton2()) Singleton2.instance

Using no Constructor at all

What happens if you define a class in F# without using any constructors at all? As opposed to C#, F# will not generate a default public parameterless instance constructor for you in the background. Your F# class simply cannot be instantiated. Oddly enough, while the compiler forbids the declaration of static fields via let bindings in this scenario (whose usage would seem to make sense), it does not complain if you define instance properties/methods/val bindings (who are useless, because they can never be accessed). This leaves you with only static properties/methods/val fields, which is quite restrictive. Furthermore, even if you decide to define such a "type with only static accessibility", it will not appear as a "static class" to its users. For these reasons, it is best to never define classes without constructors in F#. If you need what in C# we call a static class, you better define a module in F#:

Declaring a Static Class

/// A module (static class) defined in F#. Type-level let bindings are public by default,
/// but can also be internal or private. This is opposed to type (non-static class)
/// definitions, where type-level let bindings are always inherently private.
module PersonFactory =
     let CreatePerson(name, guid: Guid) = new (name, guid)
// This would be the equivalent code in C#:
public static class PersonFactory{
     public static Person CreatePerson(string name, Guid guid){
         return new Person(name, guid);

However, using modules in F# 2.0 has a certain disadvantage: Method overloading is not possible. If you need method overloading in a static class, there is no other way than declaring a non-static type with just a private parameterless constructor, or no constructor at all:

/// A class with overloaded members in F#.
type PersonFactory2 =
     static member CreatePerson(name, guid: Guid) = Person(name, guid)
     static member CreatePerson(name, guid: string) = Person(name, guid)
// This would be the equivalent code in C#:
public class PersonFactory2{
     public static Person CreatePerson(string name, Guid guid){
          return new Person(name, guid);
     public static Person CreatePerson(string name, string guid){
          return new Person(name, guid);

No Static Constructor Method in F#

There is no separate static constructor method in F#. In order to run "static constructor code" in F#, you first need to declare a primary constructor. A primary constructor is actually an instance constructor (it can have a non-public access modifier and can take arguments). However, if and only if a primary constructor exists, any type-level static let and do-bound code implicitly becomes "static constructor code".

/// Running "static constructor code" in F#.
type SomeType() =
     static let instanceCount = ref 0
     static do printfn "Type created at %A" DateTime.Now
     do printfn "Instance created at %A" DateTime.Now
     do incr instanceCount
     static member InstanceCount = !instanceCount
// This would be comparable code in C#:
public class SomeType{
     static SomeType(){
              string.Format("Type created at {0:G}", DateTime.Now));
     public SomeType(){
              string.Format("Instance created at {0:G}", DateTime.Now));
     public static int InstanceCount {get; private set;}

In this blog post, I have covered the basics of declaring F# constructor code for class types and modules. Much more could be said with regards to type construction in F#. For instance, I did not cover structures, records, object expressions, calling base class constructors, and the details of read-only fields versus mutable fields versus reference value fields. Further information can be found in the F# specification, F# Language Reference, F# documentation, or in one of the few outstanding books available, such as Programming F#.

Tags: , ,


Simulating multiple inheritance in C#

by Marc Sigrist 18. February 2010 23:15

It is possible to simulate multiple inheritance in C#, in a limited way, by applying extension methods to interfaces. An example is shown below. Note that this works only for method implementation inheritance, but not for properties or any other kinds of base members.

The C# team originally considered including extension properties in C# 4.0, but then dropped the feature. The reason apparently was that including extension properties would logically imply including indexed extension properties as well, which C#, by design, does not support. However, accessing (but not defining) indexed properties will be introduced in C# 4.0, in order to make it easier to work with COM interop. Another reason might be that extension properties in C# 4.0 would cause conceptual confusion with the already-existing feature of attached properties in WPF. Interestingly, F# does offer extension properties, but it cannot be used (yet?) as code-behind language for WPF XAML files.

You probably will not use this approach in order to „simulate multiple inheritance“ very often. However, the capacity to add extension methods to interfaces, as such, is a powerful feature. It allows to cleanly separate categories of standard behaviors from their owners.

 using System;

// This test shows how to simulate multiple inheritance in C#.

// Requires .Net Framework 3.5 as target framework.

namespace Test {

    interface IBase1 { }


    static class Base1Implementation {

        internal static void Base1Method(this IBase1 base1) {

            Console.WriteLine("Base1Method called.");




    interface IBase2 { }


    static class Base2Implementation {

        internal static void Base2Method(this IBase2 base2) {

            Console.WriteLine("Base2Method called.");




    class Derived: IBase1, IBase2 { }


    static class Program {

        static void Main() {

            var derived = new Derived();

            derived.Base1Method(); // Writes "Base1Method called."

            derived.Base2Method(); // Writes "Base2Method called."