Make bits() method const #170

New issue

Closed

opened 2019-01-15 04:51:05 -06:00 by raphaelcohn · 5 comments

raphaelcohn commented 2019-01-15 04:51:05 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

Now that simple const functions are stable in Rust, it'd be useful to make the bits() method const. I've just added a wrapper around the .bits field to do this for a particular use case (assigned a bit-or of flags to another constant that needs to be of the underlying type) - but it'd be nice if the bitflags macro could do it.

Now that simple const functions are stable in Rust, it'd be useful to make the `bits()` method const. I've just added a wrapper around the `.bits` field to do this for a particular use case (assigned a bit-or of flags to another constant that needs to be of the underlying type) - but it'd be nice if the bitflags macro could do it.

KodrAus commented 2019-01-16 17:28:14 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

Hi @raphaelcohn 👋

Sounds good to me! There are probably plenty of other methods on generated bitflags types that could be made const too.

Since it's only recently stabilized (in 1.31.0?), I think we should support const functions where available only on newer compilers. There are a few approaches to doing this, using explicit crate features like uuid does, or by detecting the compiler version using a build.rs script like serde does. Personally, I'd lean towards the build.rs approach for this case.

If anyone would like to have a go at this but isn't quite sure where to start I'll be happy to help out! Just leave a comment.

Hi @raphaelcohn :wave: Sounds good to me! There are probably plenty of other methods on generated bitflags types that could be made `const` too. Since it's only recently stabilized (in `1.31.0`?), I think we should support `const` functions where available only on newer compilers. There are a few approaches to doing this, using explicit crate features like [`uuid` does](https://github.com/uuid-rs/uuid/blob/469d378c77aea2a4f2fcfcc9af72410205ae8815/Cargo.toml#L89), or by detecting the compiler version using a `build.rs` script like [`serde` does](https://github.com/serde-rs/serde/blob/a8a54c05681168d09dbdbb4212c31a142c3cdae4/serde/build.rs#L17-L21). Personally, I'd lean towards the `build.rs` approach for this case. If anyone would like to have a go at this but isn't quite sure where to start I'll be happy to help out! Just leave a comment.

raphaelcohn commented 2019-01-17 06:42:19 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

@KodrAus - I'd probably slightly favour a build.rs approach and compiler version detection. It's a slight shame it's not possible to directly use the #cfg system for detecting the rust compiler version, or (for other problems, not this one) rely on a minimum version in Cargo.toml...

@KodrAus - I'd probably slightly favour a `build.rs` approach and compiler version detection. It's a slight shame it's not possible to directly use the `#cfg` system for detecting the rust compiler version, or (for other problems, not this one) rely on a minimum version in Cargo.toml...

kinggoesgaming commented 2019-01-17 16:02:00 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

It's a slight shame it's not possible to directly use the #cfg system for detecting the rust compiler version, or (for other problems, not this one) rely on a minimum version in Cargo.toml

I believe a RFC is open that allows querying for features

> It's a slight shame it's not possible to directly use the #cfg system for detecting the rust compiler version, or (for other problems, not this one) rely on a minimum version in Cargo.toml I believe a RFC is open that allows querying for features

kungfukennyg commented 2019-04-06 16:49:25 -05:00 (Migrated from github.com)

• Copy link
• Copy Markdown

I'd love to try this issue out. Looking over the Serde script now, but I would love any more input you have @KodrAus.

Edit: I see there is an open PR for this issue actually.

I'd love to try this issue out. Looking over the Serde script now, but I would love any more input you have @KodrAus. Edit: I see there is an open PR for this issue actually.

KodrAus commented 2019-05-03 18:47:15 -05:00 (Migrated from github.com)

• Copy link
• Copy Markdown

This is now supported in 1.0.5 when building on newer compilers.

This is now supported in `1.0.5` when building on newer compilers.

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#170

No description provided.