The Git source code audit, viewed as a Rust programmer

Re:The Git source code audit, viewed as a Rust programmer by nextaccountic on Tuesday January 24, 2023 @12:48PM (#34507175)

Oh, u32 is generally fine exactly because 16 bits is so niche. But you still have a cast between u32 and usize (and .into() isn't that much better). Casts or conversions on each collection access makes code hard to read

So if your application can work with u32 everywhere (on either 32 bits or 64 bits platforms), you should use u32 and impl Index<u32> on your collection, to avoid the cast.

It's only if you need the less common use case of u32 on 32 bits platforms, u64 in 64 bits platforms that you should bother with usize

[ Parent | on HN ]

Re:The Git source code audit, viewed as a Rust programmer by phkahler on Tuesday January 24, 2023 @01:39PM (#34507973)

>> So if your application can work with u32 everywhere (on either 32 bits or 64 bits platforms), you should use u32 and impl Index<u32> on your collection, to avoid the cast.

This seems strange. Why does Rust not automatically use whatever size index you hand it?

[ Parent | on HN ]

Re:The Git source code audit, viewed as a Rust programmer by db48x on Tuesday January 24, 2023 @02:12PM (#34508546)

Ultimately it is because the Rust developers decided that there would be no implicit conversions. In a lot of cases implicit conversions are convenient, but many people feel that the complexity just isn’t worth it.

[ Parent | on HN ]

Re:The Git source code audit, viewed as a Rust programmer by Sharlin on Tuesday January 24, 2023 @03:30PM (#34509836)

It’s not out of the question that additional `Index` impls for other integer types could be added to the standard library at some point; the issue is discussed often enough. But it’s not trivial to do because some currently valid code could become ambiguous if impls are added, so some sort of a transition would be required.

[ Parent | on HN ]