<p dir="auto">As part of <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="3999709" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/2137" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/2137/hovercard" href="https://github.com/rust-lang/rust/issues/2137">#2137</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1025571" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/456" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/456/hovercard" href="https://github.com/rust-lang/rust/issues/456">#456</a> we have added the crate version to every exported symbol, but not quite in the correct way.</p>
<p dir="auto">Right now the final part of the path used for the symbol ends with <code class="notranslate">"V" + vers</code>, which gets passed through the mangler. The original design called for <code class="notranslate">@vers</code> but the <code class="notranslate">@</code> isn't a valid symbol on all platforms (I think?) so gets mangled to <code class="notranslate">_sbox_</code>, which is a bizarre way to indicate the version.</p>
<p dir="auto">Mangling also makes any dots in the version go away so a version "0.2" symbol will end with "V02".</p>
<p dir="auto">There is some additional discussion <a href="https://mail.mozilla.org/pipermail/rust-dev/2010-December/000164.html" rel="nofollow">here</a> about how this is supposed to work that I haven't read.</p>
<h3 dir="auto">Status as of 2020-04-18</h3>
<p dir="auto">We intend to stabilize the saturating-float-casts behavior for <code class="notranslate">as</code>, and have stabilized unsafe library functions that handle the previous behavior. See <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="602353172" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/71269" data-hovercard-type="pull_request" data-hovercard-url="/rust-lang/rust/pull/71269/hovercard" href="https://github.com/rust-lang/rust/pull/71269">#71269</a> for the latest discussion on that stabilization process.</p>
<h3 dir="auto">Status as of 2018-11-05</h3>
<p dir="auto">A flag has been implemented in the compiler, <code class="notranslate">-Zsaturating-float-casts</code>, which will cause all float to integer casts have "saturating" behavior where if it's out of bounds it's clamped to the nearest bound. A <a href="https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231" rel="nofollow">call for benchmarking</a> of this change went out awhile ago. Results, while positive in many projects, are <a href="https://github.com/rust-lang/rust/issues/10184#issuecomment-429663706" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/10184/hovercard">quite negative for some projects</a> and indicates that we're not done here.</p>
<p dir="auto">The next steps are figuring out how to recover performance for these cases:</p>
<ul dir="auto">
<li>One option is to take today's <code class="notranslate">as</code> cast behavior (which is UB in some cases) and add <code class="notranslate">unsafe</code> functions for the relevant types and such.</li>
<li>Another is to wait for LLVM to add a <code class="notranslate">freeze</code> concept which means that we get a garbage bit pattern, but it's at least not UB</li>
<li>Another is to implement casts via inline assembly in LLVM IR, as the current codegen is not heavily optimized.</li>
</ul>
<h2 dir="auto">Old status</h2>
<p dir="auto"><strong>UPDATE (by <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/nikomatsakis/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/nikomatsakis">@nikomatsakis</a>):</strong> After much discussion, we've got <a href="https://github.com/rust-lang/rust/issues/10184#issuecomment-302198137" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/10184/hovercard">the rudiments of a plan</a> for how to address this problem. But we need some help with actually investigating the performance impact and working out the final details!</p>
<hr>
<p dir="auto"><strong>ORIGINAL ISSUE FOLLOWS:</strong></p>
<blockquote>
<p dir="auto">If the value cannot fit in ty2, the results are undefined.</p>
</blockquote>
<div class="highlight highlight-source-rust notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="1.04E+17 as u8"><pre class="notranslate"><span class="pl-c1">1.04E+17</span> <span class="pl-k">as</span> <span class="pl-smi">u8</span><span class="pl-kos"></span></pre></div>