The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this?
I assume you mean the first post of the PR? I'd assume it's simply outdated (or might not have been true to begin with). See https://github.com/rust-lang/rust/pull/124032#issuecomment-2181789935 for the perf run with this PR, it's showing quite a bit of regression.
Did I get it right? The crate lets you directly input data into a typst document from an arbitrary struct?
Well, typst provides those means in itself, this crate just makes it easier to fulfill the necessary trait.
Also out of scope of OP, is typst in anyway capable of typesetting music notation?
I don't really think so. Music notation is also pretty specific, so I'd look into specialized software for that (although it might be theres a latex package, those things are everywhere ^^).
It's absolutely awesome. For my use case, it already surpasses latex, but I'm pretty sure that for other usecases there will be a point where latex offers more, at least due to ecosystem support. I for sure made the switch (wrote some personal docs in typst as well), and I'd suggest anybody at least looks into switching, it's so much better :)
From a dev perspective, it's also great that this is useable as a lib, instead of having to muck with an external binary (or rather full external latex installation).
A reference IS Copy, by the simple fact that it is a primitive value on the stack.
This seems a bit misleading, noting that unique/mutable references aren't Copy. Shared references are Copy because it's sound to have that, and it's a huge QOL improvement over the alternative.
In fact, isn’t this not true just by the fact that references work for Strings and Strings size can’t be known at compile time?
I don't understand this. Shared references to String are Copy, too. This doesn't have to do anything with sizes. Rather, it's implemented in the compiler, because it's sound to have it and a huge QoL improvement over the alternative... just the same reason why e.g. usize is Copy, really.
is it dereferenced specifically because is Boxed on the heap?
No, it's not really related to the heap. Box implements DerefMut, which is in-depth explained here.
I don't know, I was just surprised by the short timeframe.
Non-tutorial suggestion: I've you're stuck, put a demonstration of your problem on the rust playground, post it here with the question. People in rustland are generally very willing to help out, and the playground is a very helpfull tool for that.
Note that when you change num to take &self instead, this works out (you also need to mark foo as mutable, of course).
I’m sure everyone’s thought about it already but hasn’t done enough so far.
Note though that the rust foundation has established a security initiative (see e.g. here), which does include the supply chain via crates.io.
2 was good, thanks. 4 needs a tad more thought imho, returning an impl T does have its place, because it makes changing the return type of the function a non-breaking change.
Seems to be missing mlua at least: https://github.com/mlua-rs/mlua