# \[Pre-RFC\] Implicit number type widening

**URL:** <https://internals.rust-lang.org/t/pre-rfc-implicit-number-type-widening/10432>\
**Category:** Uncategorized\
**Created:** [June 19, 2019, 8:12pm UTC](https://internals.rust-lang.org/t/pre-rfc-implicit-number-type-widening/10432 "2019-06-19T20:12:01Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![felix.s](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/felix.s/32/8073_2.png) [@felix.s](https://internals.rust-lang.org/u/felix.s)\
**Post date:** [June 20, 2019, 5:27pm UTC](https://internals.rust-lang.org/t/pre-rfc-implicit-number-type-widening/10432/13 "2019-06-20T17:27:05Z")

</div>

> [@djc](#):
>
> The way I would describe it in high-level terms is that I would see this happening only “at the top level”, when assigning an rvalue into an lvalue of a particular type (I’m mostly thinking of struct fields and return values here). I think that would mitigate your concerns about inferencing and the intermediate value wrapping issues?

That might still be a correctness hazard. Right now, with `struct Foo(i32);` and `x`, `y`, `z`: `u8`, code like `Foo(x * (y + z))` is a type error, which can prompt the programmer to explicitly convert `x`, `y` and `z` to `i32` so that the calculation is performed over `i32` and returns the expected result. With implicit widening of the 'top-level' `x * (y + z)` expression it will compile instead, perform the computation over `u8` and potentially trigger incorrect wrapping or panicking.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-implicit-number-type-widening/10432)._