[feature request] Allow &mut [u8] and Box<[u8]> arguments

[magistau]

Since the buffer for arguments is allocated by the library and written to by Typst once without any further expectations, it should be fine to mutate it from within the plugin.

[astrale-sharp]

Do you have a purpose in mind this will help you with?

[magistau]

Initially I wanted to pass an array of integers from Typst to Rust and thought that it is possible without any allocations by possibly reversing the order of bytes in each 8-chunk (if the endianness is different) and transmuting &[u8] to &[u64], which is why I opened this issue, but while checking core::mem::transmute invariants I understood that this would be potentially unsound as &[u8] is a 1-aligned pointer which might not be 8-aligned pointer which is what &[u64] would need. Still, there might be other reasons to want mutability.

Actually, when I saw your reply, I gave the issue more thought and decided that the most correct type of arguments would be Box<[u8]>, since the function logically receives the ownership over its arguments.

[magistau]

Same logic actually applies for the return type — maybe use impl AsRef<[u8]> for that?

[arnaudgolfouse]

I agree that the input type Box[u8]> would make sense. But the way the protocol works is by writing all the arguments into a single buffer: although we do own the buffer, we don't own the individual portions for each argument. So I believe the best we could do is &mut [u8].

As for the return type, I'm not yet sure. I assumed for most usecases it would not be able to reuse the inputs and thus it would be Vec<u8>.
Actually I would say that if someone really needs to reuse the input slice for the result, they are probably better off using the protocol directly (without the macros).

I'll try looking into the input parameters though (when I have the time ^^')

[magistau]

although we do own the buffer, we don't own the individual portions for each argument

Why not? If you own the entire buffer, you can split the ownership between several chunks. See Vec::split_off for example.

UPD: I was wrong, Vec::split_off simply reallocates the "tail". Still, I don't see why splitting ownership between chunks is not possible.

[arnaudgolfouse]

Oh indeed, it is can be done using Vec::split_off. But that runs the risk of reallocation for each new argument, which I'm really not at ease with. Doing this without overhead is, I believe, impossible (allocators do not typically support such 'splitting' of allocations).