Narrowing conversion

Posted Jul 22, 2021 0:08 UTC (Thu) by roc (subscriber, #30627)
In reply to: Narrowing conversion by tialaramex
Parent article: The Sequoia seq_file vulnerability

"as" is one of Rust's warts. You shouldn't have the same syntax for both lossy and non-lossy conversions.

Narrowing conversion

Posted Jul 22, 2021 0:41 UTC (Thu) by Gaelan (guest, #145108) [Link] (5 responses)

For non-lossy conversions, there's the alternate syntax u64::from(some_u32), but it's still not great.

Narrowing conversion

Posted Jul 22, 2021 1:21 UTC (Thu) by roc (subscriber, #30627) [Link] (3 responses)

From and TryFrom let you express infallible and fallible scalar conversions. There probably should be a third trait+method to explicitly request a truncating/sign-modifying conversion. But "as" for scalar conversions is a footgun.

I'm not sure what the best way to proceed from here is. One option would be to introduce that trait+method for truncating conversions, and deprecate or ban lossy "as" scalar conversions in a future edition. But obviously a lot of existing code would be affected.

Narrowing conversion

Posted Jul 23, 2021 0:47 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> But obviously a lot of existing code would be affected.

Isn't it something Rust editions are supposed to cover?

Narrowing conversion

Posted Jul 23, 2021 7:50 UTC (Fri) by Fowl (subscriber, #65667) [Link] (1 responses)

The code still would want to be upgraded to a newer edition at some point.

Narrowing conversion

Posted Jul 23, 2021 9:54 UTC (Fri) by khim (subscriber, #9252) [Link]

Not really. In Rust, unlike in C++, editions are supposed to coexist. You can write one crate in Rust 2015, another in Rust 2018, and third in Rust 2021.

Sure, if you are actively developing your code then you would probably want to upgrade it, but there are no pressure to do that ASAP.

Narrowing conversion

Posted Jul 23, 2021 16:40 UTC (Fri) by jezuch (subscriber, #52988) [Link]

I guess it's "not great" by design, like the new-style casts in C++ are ugly by design to discourage casting in general.

FWIW, AFAICT Rust doesn't have implicit *widening* conversion either. Turns out, it too often turns into a footgun.

Narrowing conversion

Posted Jul 22, 2021 8:30 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> You shouldn't have the same syntax for both lossy and non-lossy conversions.

If it is (clearly) changing the length of the storage field - as in between int32 and int64, why not? Only an extreme novice would think that you could stuff an int64 into an int32 and not run at least the risk of truncation. Okay if it's not obvious the target is an int32 then it's a more fuzzy issue.

Cheers,
Wol

Narrowing conversion

Posted Jul 22, 2021 9:53 UTC (Thu) by atnot (subscriber, #124910) [Link]

I think just deferring to experience isn't very useful here. Adding explicit conversions quickly becomes muscle memory that isn't given the thought it should be given. You might just not consider whether it is lossy or not in that moment. Since languages should make it easier to do the right thing than the wrong thing, requiring different mechanisms for lossy and lossless conversions would give a crucial opportunity to think about how it should really be handled.

Narrowing conversion

Posted Jul 22, 2021 11:56 UTC (Thu) by roc (subscriber, #30627) [Link]

When you read "foobar as u32" it's not obvious whether that is (potentially) lossy or not. OK, with rust-analyzer I just have to hover "foobar" to see what type it is, but it would be so simple to just require different syntax for lossy vs non-lossy conversions.