You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd argue in general converting between different sizes of integers is a much less core part of the language than the early placement of this section suggests - we may want to move it later (where we can also rely on more knowledge such as of traits). I don't think it's required for any of the exercises done before we could reasonably introduce Into/From and friends.
I think we should be default recommending Into/From and TryInto/TryFrom instead of as. In general I think as should only be used where it's strictly required, and if there's a more specific conversion mechanism we should prefer that - we shouldn't train in reaching for as as a default.
When we're talking about how as can cause bits to be re-interpreted, I'd recommend we throw in a link to a source on bit representation. I've had novices who only know JS/Python before (so have never encountered signed vs unsigned types) be (reasonably) confused about how to predict/interpret -1_i8 as u8 and 255_u8 as i8. We talk about how truncation keeps bytes, but without knowing what that byte representation is (i.e. what two's complement is) it can be hard to interpret. I think this can be handled with a simple one-sentence explanation and a link.
The text was updated successfully, but these errors were encountered:
Very early on in the course, we introduce
as
casting: https://rust-exercises.com/100-exercises/02_basic_calculator/10_as_castingA few thoughts on this:
Into
/From
and friends.Into
/From
andTryInto
/TryFrom
instead ofas
. In general I thinkas
should only be used where it's strictly required, and if there's a more specific conversion mechanism we should prefer that - we shouldn't train in reaching foras
as a default.as
can cause bits to be re-interpreted, I'd recommend we throw in a link to a source on bit representation. I've had novices who only know JS/Python before (so have never encountered signed vs unsigned types) be (reasonably) confused about how to predict/interpret-1_i8 as u8
and255_u8 as i8
. We talk about how truncation keeps bytes, but without knowing what that byte representation is (i.e. what two's complement is) it can be hard to interpret. I think this can be handled with a simple one-sentence explanation and a link.The text was updated successfully, but these errors were encountered: