# Casting integers when bit-twiddling

**URL:** <https://internals.rust-lang.org/t/casting-integers-when-bit-twiddling/7752>\
**Category:** language design\
**Created:** [June 18, 2018, 8:17pm UTC](https://internals.rust-lang.org/t/casting-integers-when-bit-twiddling/7752 "2018-06-18T20:17:03Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![leonardo](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/leonardo/32/1344_2.png) [@leonardo](https://internals.rust-lang.org/u/leonardo)\
**Post date:** [June 18, 2018, 8:44pm UTC](https://internals.rust-lang.org/t/casting-integers-when-bit-twiddling/7752/2 "2018-06-18T20:44:36Z")

</div>

This problem deserves a good general solution that's useful in other situations. See this post of mine, it's also about value range analysis and an integration of it with the into():

> [@Better integral matching](https://internals.rust-lang.org/t/better-integral-matching/7751):
>
> In the pipeline since some time there is a nice “Exhaustive integer matching” PR (that does something I assumed was done by the first Rust 1.0 I used): It’s the first step to put the correctness of Rust pattern matching code in line with the level of correctness and reliability you expect from the rest of Rust code. Now you don’t need a catch-all clause in integral-only match expressions, allowing code like: #![feature(exclusive\_range\_pattern)] fn foo1(x: u8) { match x { 0 .…

---

_[View the full topic](https://internals.rust-lang.org/t/casting-integers-when-bit-twiddling/7752)._
