4 ms·
> * First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a lit
by JoshTriplett 6y ago
> * First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.
With my Rust language team hat on: we'd love to have native support for bitfields. I'd invite folks who are interested in that to propose a language MCP ("major change proposal"), which I'd expect to be approved, and then collaborate on a spec for them.
- djmips 6y agoJosh are you able to answer my top-level comment about fixed point numbers?
- JoshTriplett 6y agoSure, done.
- Ericson2314 6y agoI probably said this many places before, but I rather leapfrog C and get {u,i}N for all n and #[repr(bitpacked)].
- JoshTriplett 6y agoThere are two separate problems that'd need solving to handle bitfields: 1) Having uN and possibly iN types, for general-purpose use. 2) Placing such types at specific offsets within a struct. C only handles the second of those: you can have an N-bit type, but when you extract it it comes out as the wider type you constrain it from. So, `unsigned field:5;` will get read as an `unsigned`, not a `u5`. Rust could handle both, if appropriate sized types exist. (Const generics might be nice here, to parameterize on the type width.) (1) alone won't solve the problem, without some way to define how those types are packed into the struct.