`const fn` support

[nazar-pc]

I'm wondering if it would be possible to compress using zstd in const fn?

The main blocker I see for a lot of const code is that traits are not supported. Didn't check if it is used widely in this repo though.

[KillingSpark]

I don't think it's impossible but it's going to be very unergonomic to write and use. Iteration is also a pain in const code and implementing the matching algorithm without dynamic allocations sound like a nightmare to me.

[nazar-pc]

Yeah, loops are blocked on traits support because it uses iterators. Allocations are less of an issue if API takes pre-allocated buffer of sufficient size or does stack allocation (when the size can be known statically).

[KillingSpark]

Can I ask what the usecase would be? Embedding data in a binary? That usecase is probably better by something like this crate https://crates.io/crates/include-bytes-zstd

Running this as a proc macro allows the full features of rust. Technically this could now also use ruzstd as the encoder to drop the C binding dependency.

[nazar-pc]

I have a custom target for which apps are written with a public API. Recursive metadata is generated with proc macros and end up included in a static` to become accessible later, including by inspecting ELF file. The metadata compresses relatively well, so I wanted to apply this compression at compile time without involving post-processing steps on produced binary.

I don't have a file to include or explicitly spelled out bytes, it is all recursive constants from different crates that eventually build up to the final static variable, so include-bytes-zstd is not applicable here unfortunately.

[KillingSpark]

Well if you're already collecting the metadata in a proc-macro why not use the normal compression in that proc-macro crate? That doesn't need a const fn if I'm not mistaken.

[nazar-pc]

The proc macro is actually of derive kind. As mentioned earlier, it need to do processing recursively. It basically generates a trait impl with const METADATA in it, then pulls these from all fields of a higher-level struct and so on until the final one. So I don't have the bytes readily available for proc macro to consume on its level. This is why macro actually generates const fn functions that process all this metadata at compile time by the compiler itself.

[KillingSpark]

I see. That's definitely an interesting problem but I'm afraid that's not a usecase this crate will support in the near future.