Mark some functions in Instruction and public api as const.

[i509VCB]

Essentially introduce const where appropriate for the public types exposed by the api.

This request intentionally only targets some functions since we don't have stable &mut in const contexts along with a bunch of other const stuff that is still nightly.

I don't expect that iced will ever become 100% const, that's unreasonable to assume due to the fact iced needs liballoc around the crate. The reason for introducing const where appropriate would be some nice utility for libraries using iced downstream that don't need to use the decoder and instead just operate on already existing types such as Instruction so their functions could also be const.

[wtfsck]

Yes, many/most/all of those methods could be const. Want to send a PR and enable those you need (and maybe more?)

[wtfsck]

Didn't mean to close it.

[i509VCB]

Sure I could send a PR, probably won't be till Friday though.

[i509VCB]

Doing some work on this, some things that should unlock more parts of the library that can be made const for the future.

1. Lookup tables are static, not sure if that is intentional or if the lookup tables could be made const.
   • Notably this blocks const for Instruction::mnemonic.
2. MSRV upgrades will make more things const. Specifically 1.56 made mem::transmute const.
   • This is something for wtfsck to decide when to do.

And the stuff out of our control and for the language to languish in.

3. impl const for traits is not ready yet, this will allow quite a few things to be made const.
   • Namely all the impls of PartialEq, Eq, PartialOrd, Ord, Default, Into, etc and anything blocked by relying on those impls.
4. &mut in const contexts, nightly at the moment I believe, this would make many of the setter functions const.

[wtfsck]

Other Instruction methods that could be made const:

• new ctor
• setters, so far only the getters have been made const (EDIT: apparently not possible yet according to your post)

Also the with*() fns can't be made const yet as mentioned in your post above. But with const new and const setters it's possible to do it manually.

[wtfsck]

Lookup tables are static, not sure if that is intentional or if the lookup tables could be made const.

Many of them definitely can be made const, unless it results in slow compile time or bigger binary file size or something like that.

[wtfsck]

MSRV upgrades will make more things const. Specifically 1.56 made mem::transmute const

1.56.0 version is too recent, current version is 1.57.0. That will probably prevent too many from using the crate.

[i509VCB]

Other Instruction methods that could be made const:

• new ctor
• setters, so far only the getters have been made const (EDIT: apparently not possible yet according to your post)

Also the with*() fns can't be made const yet as mentioned in your post above. But with const new and const setters it's possible to do it manually.

Yep I can probably do some new constructors and just delegate Default to those. My first pull request was really for everything that is blindingly obvious that could be made const.

For &mut const, that is still nightly: rust-lang/rust#57349

[not-matthias]

Many of them definitely can be made const, unless it results in slow compile time or bigger binary file size or something like that.

I changed all the lookup tables locally to const and I didn't notice any problems. The compilation time took, instead of 24s, about 26s (so 2 seconds slower). The file size was also only 1kb smaller.

[i509VCB]

I've learned of the clippy::missing_const_for_fn lint. This could be useful for determining what could be made const.