Building in Const Context

[Anders429]

Ideally, the construction of a WordFilter could be done in a const context (see Constant Evaluation for details on what can be considered a const expression). This would be much simpler to use than the current method of code generation within build scripts, and would allow for much clearer code on the user-end.

There are a number of things blocking construction as a constant expression. These will be enumerated here as they are discovered:

• Trait bounds on const fn parameters (const_fn_trait_bound).
• Mutable references in const fns (const_mut_refs).
• Heap allocations in const fns (const_heap).
• Constant trait implementations (const_trait_impl).

Implementation of WordFilter building in const contexts would involve the following:

• Move the logic within word_filter_codegen::WordFilterGenerator to a new struct word_filter::WordFilterBuilder.
• Builder should output the actual PDA inside the WordFilter. Logic within WordFilter should be able to remain the same.
• Make all internal PDA structs and modules private, as they are only currently public for the sake of the code generation.
• Migrate the word_filter_codegen PDA structs into the word_filter crate.
• Remove the Visibility enum, as it will no longer be needed.
• Deprecate the word_filter_codegen crate.

Implementation will be done on the const_expr branch. A working implementation will likely not be possible for a while, at least until the above blockers are solved via unstable features.

[Anders429]

Completely forgot about this, but there's also the whole issue of self-referencing and const generics within the actual WordFilter<'a, N>. Without the const generic N, we have to use a slice instead of an array, which makes self-referencing a nightmare. That was why the conversion to static-only happened in the first place.

That doesn't mean all is lost, however. But it does mean that N would have to specified to the build() method, which is frustrating and less intuitive.