Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hex-literal: v1.0 tracker #814

Open
2 of 4 tasks
newpavlov opened this issue Oct 20, 2022 · 2 comments
Open
2 of 4 tasks

hex-literal: v1.0 tracker #814

newpavlov opened this issue Oct 20, 2022 · 2 comments

Comments

@newpavlov
Copy link
Member

newpavlov commented Oct 20, 2022

hex-literal is quite stable, with v0.3.0 being release over two years ago. So I think we can start to consider v1.0 release.

Potential changes:

  • Bump MSRV to 1.56 and edition to 2021 (Done in v0.4)
  • Decide whether we want to forbid comments inside literals or not, as described here (Done in v0.4)
  • Use MSRV-dependent dependency version resolution rust-lang/cargo#9930. It will allow us to bump hex-literal edition without breaking downstream builds and maybe incorporate new language features.
  • Wait for stabilization of generic_const_exprs and adt_const_params? It would allow us to write:
fn decode<const DATA: &'static [u8]>() -> [u8; decode_len(DATA)] { ... }
@Nugine
Copy link
Contributor

Nugine commented Feb 21, 2023

It's possible to implement hex! macro with const evaluation. See const_str::hex!.

@newpavlov
Copy link
Member Author

newpavlov commented Feb 21, 2023

Yeah, it works on Nightly and the code does not look too bad.

But this approach has the following disadvantages:

  1. hex::<"abcdef">() is... not great. Introducing a wrapper macro partially solves the issue, but ideally we would use const arguments. Unfortunately, it's highly unlikely that they will be added to the language. :(
  2. Error diagnostics are much worse. We can not even panic with message which includes encountered invalid character. With macros we potentially can point the exact place which triggers an error.

UPD: Migration to CTFE is done in #816.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants