Why is automatic generalization sometimes inferring overly specific types?
<p>Some function usages don't compile when one side of an operator has a known type and the other doesn't. One example is with units of measure:</p>

<pre><code>let inline multiplyWithFive x = 5. * x

type [&lt;Measure&gt;] myUnit
let test = multiplyWithFive 3.&lt;myUnit&gt; // Compiler error
</code></pre>

<p><code>5. * 3.&lt;myUnit&gt;</code> is clearly a valid expression, so this is surprising, especially considering that <code>inline</code> functions generalize maximally in other cases:</p>

<pre><code>let inline multiply a b = a * b
let test = multiply 5. 3.&lt;myUnit&gt; // Valid
</code></pre>

<p>This isn't limited to units of measure though. Say, I make a type that supports asymmetric multiplication with a float. It's incompatible with the <code>multiplyWithFive</code> function, which arbitrarily infers its parameter as <code>float</code>:</p>

<pre><code>type BoxFloat =
    { Value : float }

    static member inline (*) (lhs : float, rhs : BoxFloat) =
        { Value = lhs * rhs.Value }

let boxThree = { Value = 3. }

let test2 = multiplyWithFive boxThree // Compiler error
</code></pre>

<p>Again, <code>5. * boxThree</code> is a valid expression. But the automatic generalization doesn't seem to acknowledge that.</p>

<p>I can "fix" the first case with unit-of-measure-aware type annotations, but this restricts the underlying type for no apparent reason. If I actually need a more general function, I don't know how to stop the compiler from making up restrictions. If I explicitly name a generic parameter, it just refuses to keep it generic:</p>

<pre><code>// Warning: This construct causes code to be less generic than indicated...
let inline multiplyWithFive (x : 'T) = 5. * x 
</code></pre>

<p>What can I do about this? Is there some way to say that I do want the more generic version?</p>