Closed alice-i-cecile closed 7 months ago
Accepting a &str
instead gets rid of the error around the destructor of String
not being callable in const
contexts. The difficulties with mutable references and for_each
both seem feasible with a bit of ugly rewriting.
The primary remaining challenge is converting the string into something that represents its value that could be hashed. Currently we use bytes, but that's not the only option. str::as_bytes
appears to be const, so we may be in business!
However, for
is not allowed in const
methods on stable Rust: see https://github.com/rust-lang/rust/issues/87575. On the other hand, while
does work! Perhaps this can work, with sufficiently ugly code.
What problem does this solve?
I want to be able to efficiently store constants for the Ids computed from const strings.
This is great when working with hybrid code-data workflows, where you want to quickly spawn an object in a scripting-like way without having to recompute the hash. It also adds some level of typo-resistance, as the name only needs to be typed in a single location.
What solution would you like?
Add
const
toId::from_name
.How could this be implemented?
Unfortunately, it's not that simple.
Even when accepting only a
String
infrom_name
, addingconst
to the function below results in a number of compiler errors.[Optional] What alternatives have you considered?
Swapping to a global append-only store of Names <-> Ids would work, but require unsafe and be more technically complex. If this approach was chosen, we may want to swap to an atomically incrementing identifier scheme, rather than a hash-derived one.