Today I wanted to talk about two features that are quite important for multimedia decoding but are quite inconvenient in the current state.
First, macros. I know that macros in Rust are both very powerful and quite flexible but they are hard to use for data definition and I ranted about it before. The problem is that quite often you have tables with some internal structure that would benefit from macro substitutions: if you have a codebook constructed from entries following patterns like a, b, -a, -b
and a, b, a, -b, -a, b, -a, -b
it would be easier and less error-prone to represent them as e.g. FLIP2#(a, b)
and FLIP4#(a, b)
inside the data definition. The problem is that macro!
does not allow you to do that easily since it’s supposed to expand into valid statements (i.e. code or full data definitions). Of course you can work it around by making a set of macros to define the whole array and some bits inside it but that’s what makes it unwieldy. And that’s why I believe there should be another macro substitution mechanism, maybe named macro#
, that would work just on data but it’d be much easier to use in that particular case.
The second issue is assembly integration. Despite Rust being fast and such it’s still better to write small critical functions in assembly. And obviously it would be better if Cargo supported including assembler files into crate. You can point out there’s stdsimd
for using the power of SIMD without much hassle. I can point out that compiler-generated code is still far from being perfect even with intrinsics and assembly is still better; supporting querying SIMD capabilities via standard package is good though. And you can point out that there’s a special crate for supporting various files with various compilers/assemblers already. I’d say that it’s a bit too generic but at least it can serve as a base for what I need. Again, there’s more or less standard way to deal with assembly files so making a common standard is not hard.
And in the unlikely case somebody reads this and asks why I don’t form an RFC—from what I heard it involves proposing code as well and I don’t want to study the compiler nor waste days compiling it.
https://github.com/rust-lang/rust/issues/29722 is still far to get something in stable, so something like https://github.com/coder543/libasm exists.
Hopefully that will get us the same in stable as compiler_error happened to be an external crate until the same feature ended up in the std.