RFC: Proposal for bit data (Ver 2)

[engstad]

After having addressed most of the issues, here's the updated RFC.

[steveklabnik]

s/to //

[eddyb]

Is there a need to add keywords and syntax to Rust instead of building on top of the existing syntax?
This seems like it could be prototypable as a syntax extension, at least with methods for accessors.

[engstad]

@eddyb This was discussed before, but the short version is that no - a syntax extension is not possible.

What people have done instead is to run their own parser/external tool to just do the job, and that is not quite where you want to be (if you are supposed to be a systems language).

[bgamari]

@engstad I'm not sure I see why a syntax extension would not be possible here. Why can the error checking not be done in a syntax extension? Likewise, what prevents a type defined by a bitdata! syntax extension from using another bit-data type? Finally, the syntactic overhead of a syntax extension is merely the bitdata!( prefix and a closing paren; this could be made even more pleasing if syntax extension syntax can be made to accept blocks.

We've implemented similar functionality to that proposed here in the Zinc project. This involved a syntax extension and while we only handle the single constructor case (and adopt a rather different syntax than typical Rust) I believe this approach could be easily adapted.

[bgamari]

For the record, the first iteration of this RFC was #205.

[Ericson2314]

Wouldn't it be better enhance enum and struct than add a new type of data (and keyword). odd-sized numerical types and mod types (like Ada) are fairly similar and could probably be implemented together.

Option<Type_With_Bits> could also be optimized if the discriminants aren't exhaustive. Integer (of the right size) casts to Option<Type_With_Bits> would correspondingly be safe no-ops.

[engstad]

@bgamari Yes, I checked the ioregs!() functionality. While it is an impressive syntax extension, it still doesn't cover match, which I feel is essential for clean operation on bit-data. In addition, having to use .set_xxx() and xxx() methods is tedious and unnecessary.

@Ericson2314 I think it is quite important to differentiate bit-data and byte-data, simply because with bit-data you don't have to consider alignment and endianess. Having said that, yes our struct construct can also be improved. I will probably follow up with an RFC that improves our handling of byte-data, where for example this would be possible:

bitdata StreamInfo {
    SI { 
         num_elements: u12, 
         stream_index: u4, 
         stride: u8, 
         format: u8, 
         typ: u8, 
         offset:  u8, 
         size: u8, 
         flags: u8 
    }
}
struct Mesh {
    num_indexes : u32,
    num_streams: u32,
    total_stream_size: u32,
    #[align(16)] indexes: [u16, ..num_indexes],
    #[align(16)] stream_info: [StreamInfo, ..num_streams],
    #[align(16)] stream_data: [u8, ..total_stream_size]
}

[bgamari]

engstad [email protected] writes:

@bgamari Yes, I checked the ioregs!() functionality. While it is an
impressive syntax extension, it still doesn't cover match, which I
feel is very essential for clean operation on bit-data. In addition,
having to use .set_xxx() and xxx() methods is tedious and unnecessary.

I agree that the lack of pattern matching is a bit unfortunate. I
wonder, however, whether it would be possible to generalize pattern
matching a bit, allowing this and similar use-cases to be implemented
without adding a whole new data type declaration to the language.

I believe there was some resistance in the past to allowing arbitrary
computation to take place during a pattern match, but this would
certainly be one way to acheive what you want.

As far as accessors goes, I agree that they are a bit onerous in the
your case. In the case of a register interface requiring explicit
accesses makes sense due to the potential side-effects that they may
trigger.

[zwarich]

Any proposal for bit data should have more details about the low-level representation of the bit data in memory, as it is important that the layout matches specific formats that are defined outside of Rust code. In this today's triage meeting we decided to postpone this RFC. I opened a tracking issue as #346.