Suggestion: lookup table construction with const fn

[arucil]

Currently lookup tables are contructed with macros, where keys and values are almost literals. With constant functions, one can use a rich set of builtin constant expressions during the construction of lookup tables. For example,

const A: &str = "aaa";
const B: &str = "bbb";
const TABLE: Map<&'static str, i32> = phf_map(&[
  (A, 1 * 3 * 5),
  (B, [1,2,3,4].len() as i32),
]);

[pickfire]

But I wonder if there is any way to manually construct the table, I saw a place where we have a use case to build a two way Map, I wonder if it could be done without duplicating all the stuff.

pub(crate) struct NamedColorMap {
    name_to_rgba: HashMap<&'static str, [u8; 4]>,
    rgba_to_name: HashMap<[u8; 4], &'static str>,
}

[abonander]

This is theoretically possible, however constifying the map generator code isn't trivial. Have a look. A glance there's a lot of code here that depends on non-const APIs:

• random number generation (albeit using a PRNG with a fixed seed which can be constified)
• dynamic allocation with vec![], but with theoretically fixed upper bounds that could be replaced by arrays.
• iteration (but could be replaced by looping with incrementing indices, which are allowed in const)
• invocations of the PhfHash trait (via phf_shared::hash)
• sorting (which requires a trait or closure but could be constified)

It's the trait-based hashing that would be the most difficult to replace right now because we don't have const trait fns. Constifying this would probably require hand-monomorphized code and a different constructor function for each possible key type (deduplicated with macros, sure, but that's suboptimal).

[abonander]

rust-lang/rfcs#2632 would likely allow this, assuming some trait impls get constified as well.

[ImUrX]

I dont think that a similar RFC is gonna ever come out and be merged in within a year. Maybe #242 is a good step on just making it work with the current hacks that Rust permits.