Repository navigation
I wonder if all the methods of the crate could be made const #24
Description
Activity
Hello and thank you for the kind words!
Indeed, I plan on making everything
constwhen support becomes stable.constin trait methods is still unstable and in flux. In the meantime, an alternative is to define astaticVec<ResistorColor>usingonce_cell::sync::Lazy.Reacted by Félix Fischer and Andrej MihajlovClosing as this requires some support that only exists in nightly and is unlikely to stabilize soon or even in its current form.
This is definitely a highly desirable feature which I will implement when support lands in stable.
Reacted by Félix FischerI plan on making everything
constwhen support becomes stable.Yay 🌈
In the meantime, an alternative is to define a
staticVec<ResistorColor>usingonce_cell::sync::Lazy.Ohh, I didn't know about that crate! Nor did I know about the RFC to include it in
std... that's really cool!My
lazykung-fu was last updated when I learned about thelazy_static!macro a good few years ago.Given how the process is trending towards
once_celland the extra features that API packs (like lazy values for local variables of functions!) I'm sure as heck gonna use that from now on ✨and thank you for the kind words!
Of course ^^ 🫶🏽
Reacted by stephaneyfxOn a related note. Just today I had to implement
clap::ValueEnumfor some of my enum types which requires to return a slice with all enum variants. Is it not possible to generate a method as a part of derive macro that simply puts all enum variants into a static slice, i.efn all_variants() -> &'static [Self] { &[Self::A, Self::B, ...etc...] }?Is it not possible to generate a method as a part of derive macro that simply puts all enum variants into a static slice [...]?
It is not possible without special-casing the macro as it supports nested types and relies on trait functions to instantiate values. The following solution seems simple enough (though it does pull in another crate):
use enum_iterator::Sequence; use once_cell::sync::Lazy; #[derive(Debug, PartialEq, Sequence)] pub enum Foo { A, B(bool), } pub fn all_foos() -> &'static [Foo] { static FOOS: Lazy<Vec<Foo>> = Lazy::new(|| enum_iterator::all().collect()); &**FOOS }
I see. Thanks for posting the example.
I have done similar today with
std::sync::Oncealthough it's unsafe but I assumeLazyuses some sort of internal mutex lock which is a bit of an overkill for that kind of task -- I mean in my case it's 10 enum variants inside of a slice without nested values.Obviously hardcoding is not difficult, it's just that as the types evolve and grow it becomes harder to keep track of things. So eventually I decided to plug in a
derive(clap::ValueEnum)for my enum and call it a day. I wanted to isolate my lib from clap but whatever... But I still useenum_iterator::Sequencefor other things such as computing things at runtime by walking over enum variants etc..You're welcome. Actually, I just remembered it's possible to achieve without an additional crate as the needed functionality was merged into
std:use enum_iterator::Sequence; use std::sync::OnceLock; #[derive(Debug, PartialEq, Sequence)] pub enum Foo { A, B(bool), } pub fn all_foos() -> &'static [Foo] { static FOOS: OnceLock<Vec<Foo>> = OnceLock::new(); &**FOOS.get_or_init(|| enum_iterator::all().collect()) }
If you only need this
&'static [Foo]forclap, the locking that happens under the hood likely does not matter. If this were in a tight loop, that could be a different story.Reacted by Andrej Mihajlov
Hellu. First of all, thanks for the crate. It's freaking awesome.
So I was doing some exercises at exercism.org, as practice, and there was an exercise that used this crate. I realized that most of the functions it requires don't (or almost don't) need any runtime information to be computed:
value_to_color_stringcan be solved with aconst Hashmap<u32, &str>colorsis basically aconst Vec<ResistorColor>So long story short, I realized that I couldn't make these things
constbecause, among other things,enum-iteratoritself's methods aren't const. So I came and tried to addconstness for the methods, thinking of submitting that as a PR, but I ran into a wall in the language that took me to rust-lang/rust#101900.I think the methods in the crate can't currently be made
const(since they are Trait methods after all?), but I could be wrong.Anywho. I'm 99% sure you've already delved into this, and that it's in some todo-list of your own. But perhaps it wasn't, and this helps somewhat.
Also this allows me to say thanks for the crate. It's a really cool crate. Thanks :D