Split bitflags macro and traits into 2.5 macros/traits #419

New issue

Open

opened 2024-08-13 13:29:47 -05:00 by rusty-snake · 2 comments

rusty-snake commented 2024-08-13 13:29:47 -05:00 (Migrated from github.com)

• Copy link
• Copy Markdown

This issue tries to outline a solution to some of the problems of bitflags. There is plenty room for discussion right now.

bitflag suffers from the fact that it hadn't a defined target group for a long time and got request from different directions with different requirements. This improved over the last releases and we now have largely consistent behaviour and a definition of the status quo. However this is still a compromise that does neither bring the one side full feature power nor the other.

The overall idea is to have more than one bitflags type (type here means macro/trait = API).

FFIFlagsWeak / FFIFlagsStrict

One major use of bitflags is for type-safe ffi types commonly found on C APIs.

• The most important aspect here is that we deal with foreign flags where the integer-type and the flag values have to be an explicit defined value. Comparable with #[repr(C)].
• For some APIs passing new (undefined) flags is a tolerated/required feature. While other APIs need to consider every other bit as dangerous. Hence the needs to be a weak and a strict variant.
• Strange flags (e.g. multi-bit, ...) might be part of the API and we can not forbid them. We do not necessarily need full support for such flags in the first place (e.g. from/to string) but we need to handle them gracefully w/o assuming magic.

RustFlags

The second use are sane, type-safe, well-defined, comfortable Rust-to-Rust APIs.

• The exact flag values and integer-type does not matter as long as they are stable for one compilation. Comparable with #[repr(Rust)].
  • This allows stuff like auto flags.
• We can be strict on strange flags.
• There is no need to expose the raw bits.
• We really only want a optimized and convenient struct { bool, bool, bool, bool, bool, bool, bool, bool }

This issue tries to outline a solution to some of the problems of bitflags. There is plenty room for discussion right now. bitflag suffers from the fact that it hadn't a defined target group for a long time and got request from different directions with different requirements. This improved over the last releases and we now have largely consistent behaviour and a definition of the status quo. However this is still a compromise that does neither bring the one side full feature power nor the other. The overall idea is to have more than one bitflags type (type here means macro/trait = API). ### `FFIFlagsWeak` / `FFIFlagsStrict` One major use of `bitflags` is for type-safe ffi types commonly found on C APIs. - The most important aspect here is that we deal with foreign flags where the integer-type and the flag values have to be an explicit defined value. Comparable with `#[repr(C)]`. - For some APIs passing new (undefined) flags is a tolerated/required feature. While other APIs need to consider every other bit as dangerous. Hence the needs to be a weak and a strict variant. - Strange flags (e.g. multi-bit, ...) might be part of the API and we can not forbid them. We do not necessarily need full support for such flags in the first place (e.g. from/to string) but we need to handle them gracefully w/o assuming magic. ### `RustFlags` The second use are sane, type-safe, well-defined, comfortable Rust-to-Rust APIs. - The exact flag values and integer-type does not matter as long as they are stable for one compilation. Comparable with `#[repr(Rust)]`. - This allows stuff like `auto` flags. - We can be strict on strange flags. - There is no need to expose the raw bits. - We really only want a optimized and convenient `struct { bool, bool, bool, bool, bool, bool, bool, bool }`

👍 1

KodrAus commented 2024-09-14 04:43:27 -05:00 (Migrated from github.com)

• Copy link
• Copy Markdown

The tension between these has definitely caused us trouble in the past, and we've largely started catering to the former group more than the latter these days. For the latter group, I've thought a proc-macro library that was fully strict might be a good fit. There are a few out there already, such as this one, but I'm not sure how far they go to deal with the oddities around multi-bit flags, which I think should be disallowed, like your example of basically producing a struct of bools.

The tension between these has definitely caused us trouble in the past, and we've largely started catering to the former group more than the latter these days. For the latter group, I've thought a proc-macro library that was fully strict might be a good fit. There are a few out there already, such as [this one](https://github.com/meithecatte/enumflags2), but I'm not sure how far they go to deal with the oddities around multi-bit flags, which I think should be disallowed, like your example of basically producing a struct of bools.

KodrAus commented 2024-09-14 04:45:57 -05:00 (Migrated from github.com)

• Copy link
• Copy Markdown

I think there's definitely room for a library that took the approach of if flags types were going to be a language feature in Rust, how would they work? and would love to see it get built.

I think there's definitely room for a library that took the approach of _if flags types were going to be a language feature in Rust, how would they work?_ and would love to see it get built.

👍 1

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

release/1.x

2.13.2

2.13.1

2.13.0

2.12.1

2.12.0

2.11.1

2.11.0

2.10.0

2.9.4

2.9.3

2.9.2

2.9.1

2.9.0

2.8.0

2.7.0

2.6.0

2.5.0

2.4.2

2.4.1

2.4.0

2.3.3

2.3.2

2.3.1

2.3.0

2.2.1

2.2.0

2.1.0

2.0.2

2.0.1

2.0.0

2.0.0-rc.3

2.0.0-rc.2

2.0.0-rc.1

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.1.0

1.0.5

1.0.4

1.0.3

1.0.2

1.0.1

1.0.0

0.9.1

0.9.0

0.8.2

0.8.1

0.8.0

0.7.1

0.7.0

0.6.0

Labels

Clear labels   

bug

  

good first issue

No labels

bug

good first issue

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-bitflags/bitflags#419

No description provided.