CODEWITHSUNDEEP
genericsf#type-inference
Grzegorz Sławecki
Grzegorz Sławecki

Reputation: 1797

Type inference on ToString() vs string operator

Note: This question is somewhat related to my previous one, but it actually touches the issue from different perspective

Consider following snippet:

let toStr a = a.ToString()
let strOp a = string a

let intToStr = 5 |> toStr
let floatToStr = 5.0 |> toStr

let intStrOp = 5 |> strOp
let floatStrOp = 5.0 |> strOp //type inference error

While the strOp function uses what appears to be more elegant solution, and is able to convert a unit value to string as well, it seems not to be truly generic since it's type gets constrained during it's first usage (even the type inferred is obj -> string, not 'a -> string)

Why doesn't string operator work in such a generic way? Or am I doing something wrong?

Upvotes: 3

Views: 180

Answers (1)

Tomas Petricek
Tomas Petricek

Reputation: 243041

The difference is that string uses static member constraints (see the definition) while ToString is an ordinary method available on any object and so the compiler treats the ToString invocation as generic code that does not constrain the instance type in any way.

Static constraints and (non-static) generics work in different ways when they are used in (otherwise unconstrained) let-bound function:

  • For generic code, the compiler propagates the genericity and makes the let-bound function you wrote generic too.

  • For static member constraints, the compiler specializes the code based on the first use. As mentioned in the comments, you can avoid this by using inline, which allows static member-based genericity to propagate in the same way as ordinal generic code.

I think the only reason why the string function uses statically resolved type constraints is that it allows it to specialize as ordinary ToString call for primitive types, but still handle null values in custom way for objects - toStr null throws an exception but strOp null returns an empty string!

Upvotes: 4

Related Questions