<div class="highlight highlight-source-rust notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="fn main() {
    let x : f32 = 1.0;
    let y = x / 10; //error: the trait `core::ops::Div&lt;_&gt;` is not implemented for the type `f32`
}"><pre class="notranslate"><span class="pl-k">fn</span> <span class="pl-en">main</span><span class="pl-kos">(</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
    <span class="pl-k">let</span> x <span class="pl-kos">:</span> <span class="pl-smi">f32</span> = <span class="pl-c1">1.0</span><span class="pl-kos">;</span>
    <span class="pl-k">let</span> y = x / <span class="pl-c1">10</span><span class="pl-kos">;</span> <span class="pl-c">//error: the trait `core::ops::Div&lt;_&gt;` is not implemented for the type `f32`</span>
<span class="pl-kos">}</span></pre></div>
<p dir="auto">The error message is confusing because it reads as though you cannot divide <code class="notranslate">f32</code>s at all when the real issue is that you can't divide a <code class="notranslate">f32</code> by any other numeric type. The error message should at least say something about the different numeric types involved. Ideally it would suggest changing <code class="notranslate">10</code> to <code class="notranslate">10.0</code> or casting the term.</p>
<p dir="auto">spawned off of <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="70468933" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/24728" data-hovercard-type="pull_request" data-hovercard-url="/rust-lang/rust/pull/24728/hovercard?comment_id=95911488&amp;comment_type=issue_comment" href="https://github.com/rust-lang/rust/pull/24728#issuecomment-95911488">#24728 (comment)</a></p>
<p dir="auto">In an example like:</p>
<div class="highlight highlight-source-rust notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="fn main() {
    let vs = vec![1, 2, 3, 4];

    for v in &amp;vs {
        match v {
            1 =&gt; {}
            _ =&gt; {}
        }
    }
}"><pre class="notranslate"><span class="pl-k">fn</span> <span class="pl-en">main</span><span class="pl-kos">(</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
    <span class="pl-k">let</span> vs = <span class="pl-en">vec</span><span class="pl-en">!</span><span class="pl-kos">[</span><span class="pl-c1">1</span>, <span class="pl-c1">2</span>, <span class="pl-c1">3</span>, <span class="pl-c1">4</span><span class="pl-kos">]</span><span class="pl-kos">;</span>

    <span class="pl-k">for</span> v <span class="pl-k">in</span> <span class="pl-c1">&amp;</span>vs <span class="pl-kos">{</span>
        <span class="pl-k">match</span> v <span class="pl-kos">{</span>
            <span class="pl-c1">1</span> =&gt; <span class="pl-kos">{</span><span class="pl-kos">}</span>
            _ =&gt; <span class="pl-kos">{</span><span class="pl-kos">}</span>
        <span class="pl-kos">}</span>
    <span class="pl-kos">}</span>
<span class="pl-kos">}</span></pre></div>
<p dir="auto">which yields the error message:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="&lt;anon&gt;:4:5: 9:6 error: type mismatch resolving  \ (linebreak solely for presentation here)
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == _`:
 expected &amp;-ptr,
    found integral variable [E0271]
&lt;anon&gt;:4     for v in &amp;vs {
&lt;anon&gt;:5         match v {
&lt;anon&gt;:6             1 =&gt; {}
&lt;anon&gt;:7             _ =&gt; {}
&lt;anon&gt;:8         }
&lt;anon&gt;:9     }"><pre class="notranslate"><code class="notranslate">&lt;anon&gt;:4:5: 9:6 error: type mismatch resolving  \ (linebreak solely for presentation here)
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == _`:
 expected &amp;-ptr,
    found integral variable [E0271]
&lt;anon&gt;:4     for v in &amp;vs {
&lt;anon&gt;:5         match v {
&lt;anon&gt;:6             1 =&gt; {}
&lt;anon&gt;:7             _ =&gt; {}
&lt;anon&gt;:8         }
&lt;anon&gt;:9     }
</code></pre></div>
<p dir="auto">i find it frustrating that the first line prints the integral type variable as just <code class="notranslate">_</code>.</p>
<p dir="auto">It is not a completely unconstrained type; it must be some kind of integer.</p>
<p dir="auto">(It is true that one should be able to figure this out from the third line.  But I think we can still do better on the first line itself.)</p>
<p dir="auto">I am thinking something like this could suffice:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="error: type mismatch resolving   \
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == iN`"><pre class="notranslate"><code class="notranslate">error: type mismatch resolving   \
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == iN`
</code></pre></div>
<p dir="auto">Another slightly more verbose option (but less prone to misinterpretation when e.g. unsigned integers are involved, or when the user has <em>defined</em> a type named <code class="notranslate">iN</code>) would be:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="error: type mismatch resolving   \
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == &lt;int type&gt;`"><pre class="notranslate"><code class="notranslate">error: type mismatch resolving   \
 `&lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item == &lt;int type&gt;`
</code></pre></div>
<p dir="auto">Yet another option, which is both succinct but will not collide with user definitions (at least not today):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="error: type mismatch resolving   \
 `int? == &lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item`"><pre class="notranslate"><code class="notranslate">error: type mismatch resolving   \
 `int? == &lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item`
</code></pre></div>
<p dir="auto">and likewise one would imagine for the <code class="notranslate">FloatVar</code> case</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="error: type mismatch resolving   \
 `float? == &lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item`"><pre class="notranslate"><code class="notranslate">error: type mismatch resolving   \
 `float? == &lt;core::slice::Iter&lt;'_, _&gt; as core::iter::Iterator&gt;::Item`
</code></pre></div>
<p dir="auto">I forced the <code class="notranslate">int?</code> and <code class="notranslate">float?</code> to be on the left-hand side to ensure that they did not get mistaken for a question mark ending the error message itself.  (I did consider <code class="notranslate">?int</code> and <code class="notranslate">?float</code> but I worry a little that those would get confused with the generalization marker <code class="notranslate">?Sized</code> ... maybe that is a small price to pay...)</p>