I have an app that ultimately renders pdfs via typst. I’m starting to write tests for the output, exporting the documents to png instead and then applying something like https://github.com/kornelski/dssim or so.
(If anyone has experience with that, I’d take any hint I get ;))
This parting shot sounds pretty dire
a bug in safe code can easily cause unsound behavior in your unsafe code if you’re not careful.
That’s definitely not how it should be. Fortunately, I think I disagree with that, since miri points to the “real” buggy code:
unsafe { inner.as_ref() }
As opposed to the article, I’d argue this code is not correct, since it did not account for alignment, which it must (I mean, by standard use of the word unsound this is unsound, since it can be called from safe code introducing UB). Or am I wrong? Is the fundamental value proposition of rust moot?
Note that this is not only a cli and a (closed source) web editor, but also a library. So it’s possible to embed a full typesetting library in your project, which is awesome. It’s probably not on par with TeX yet, but you can already do an awful lot with it. Scripting it is really much, much easier than, say, LaTeX.
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.
Wow, they’re sort-of-targeting edition 2024. I did not expect this, holding my breath ;)
While funny, this also highlights part of why I like rust’s error handling story so much: You can really just read the happy path and understand what’s going on. The error handling takes up minimal space, yet with one glance you can see that errors are all handled (bubbled up in this case). The usual caveats still apply, of course ;)
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.
Enums/Structs first, but those 2 are mixed, and any impl for them will be directly after the definition of the type itsef. Free functions last.
Hmm, right. I think it still might be warranted in niche cases, but trying to think of such a case made it pretty protracted in my head… maybe when functions can also be called for side effects, and the into conversion is costly and the caller might not care about the return value?
Note that when you change num to take &self instead, this works out (you also need to mark foo as mutable, of course).
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.
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).