RFC: bit fields and bit matching #29
Conversation
| 0b00 => ..., | ||
| 0b01 => ..., | ||
| 0b02 => ..., | ||
| 0b03 => ... |
There was a problem hiding this comment.
2 and 3 are not valid binary digits. This would have to be 0b10 and 0b11.
| ```rust | ||
| let mut val: u32 = ...; | ||
| let bits1 = val[4..5]; // equivalent to bits = (val >> 4) & 3 | ||
| let bits2 = val[0,4..5]; // equivalent to bits = ((val >> 4) & 3) | (val & 1) |
There was a problem hiding this comment.
The previous line is fine, but this might be a bit too magical. It’s not obvious that , means |
There was a problem hiding this comment.
Still, it would be useful to extract non-continuous bits. Maybe using | instead of , is a better option?
|
I think that it's not necessary to change the language in this way to support this. For bit access, it seems to me that a macro would work. For matching, add a special case to the language so that matching an expression that, after trivial constant propagation/move elimination, is (expr & const), (expr % const), (expr << const), (expr >> const) or a combination of those (and possibly others) is considered exhaustive when all the possible output values are specified. It's also possible to handle matching with integers of any bit-size, but that doesn't quite handle modulus and shifts and so on without adding those too in the typesystem, which seems worse. |
|
I'm going to vote against this RFC. While I love the idea of bitstring matching, @LeoTestard's awesome rustlex demonstrates it's possible to build a complex pattern matching macro. I don't really see any disadvantages of it being done externally, so I feel this should be done as an external project. |
|
I think something along these lines is necessary for systems programming. I don't really care if it is part of the language or a syntax extension, as long as it is nice. I would rather have this done well in the language than done awkwardly with a syntax extension. Given that this is a fairly core feature for our core audience, I don't see the attraction of having it outside the language if there is any reason not to. |
|
|
||
| ```rust | ||
| let mut val: u32 = ...; | ||
| let bits1 = val[4..5]; // equivalent to bits = (val >> 4) & 3 |
There was a problem hiding this comment.
Could you explain this syntax please? Its not clear to me from the examples.
There was a problem hiding this comment.
Consider 123u[32..63]. Would such access compile only on some platforms other than 32-bit?
There was a problem hiding this comment.
I think it should be limited to strictly sized types, e.g. 123u[32..62] wouldn't work, you must use 123u64[32..62].
|
I think it is essential to be refer to groups of bits (not just single bits; its not clear to me if that is possible here) and to name them. Both things are possible in C++. I think there is too much potential for errors without. There is some good discussion on this reddit thread on what is necessary to have safe and portable bitfields - http://www.reddit.com/r/rust/comments/244yz6/bitfields_in_rust/ |
|
|
||
| # Detailed design | ||
|
|
||
| The first part of this RFC is defenition of a bit access for integer types. For the sake of simplicity, only unsigned integer types (uint, u8, u16, u32, u64) are supported. |
There was a problem hiding this comment.
only fixed width unsigned integer types (u8, u16, u32, u64)
|
over the years i'd done a lot of low level work packing vertex and color formats, building DMA tags and so on.. I'd always been perfectly happy with C/C++ on this front without bitfields (always feared them for portability issues,and just used shifts/masks and abstractions of those). Its a long way from the issues that drove me to Rust.. and I can think of many other things i'd rather have added to the language today. Ints in the generic type params (like C++) would extend what you can do with generic code, eg shift/mask values in constants. (eg, have a smartpointer which is a compressed pointer with a shift value for acessing aligned objects within an arena, ). Better generic type inference (equiv of C++ decltype, even auto return type) would help. HKT. If rust could get something that improves on struct inheritance (generalized delegation of fields and component methods? .. maybe on tuples? .. and coercions ?) ... that would be great too. Even array sugar foo[i,j] would be preferable to dedicated bitfields .. if you get improved [] overloading maybe that type of array sugar could be of use for bitfield access? some people want slice syntax, maybe that would work. |
|
I've been playing around using Rust with several binary network protocols. Pattern matching on bits would be incredibly useful. I've experienced no easier parsing of binary wire protocols than when I've used OCaml's bitstring pattern matching syntax extension (based on Erlang's bitstring matching). Pure bliss. If this can be accomplished using macros, great (I still haven't explored Rust's macro system so I'm not sure). But given the interest in Rust from embedded and systems programmers, I would think this would be a great addition to the core language. Bitfields would be great, too, particularly for the embedded programmers. |
|
Does the recent |
|
No. Bit fields/bit matching are very unrelated to bitflags. On Tue, May 6, 2014 at 6:24 PM, Ben Striegel notifications@git.luolix.topwrote:
|
|
I haven't read this in detail yet but I think rust-lang/rust#12642 might be related. |
|
Thank you for the RFC. Current policy is to not have bitfields in the language itself and use syntax extensions. We currently have a Closing. |
|
To elaborate on @brson's comment: If |
No more git dependencies there! Closes rust-lang#29
No description provided.