Add custom primitive / Copy types?

[Droggelbecher]

Thank you for this great project :)

I'd love to add some custom Copy and/or primitive types to rune that should also be exchangeable efficiently with rust.
Two main examples would be:

• f32, u32: These are used a lot in my code for GPU-related things so it would be nice if I were not forced to convert them back and forth to larger types for exchange with rune. I tried to follow the f64 code, but ultimately I cant implement Named for f32 without forking due to the orphan rule. Is there a recommended way of doing this?

• Small coordinate vectors such as a pair of x/y coordinates. I used to do this with a custom type but it was significantly slower than a plain pair of ints. I suspect that its due user types being allocated and refcounted, is there a way to work around this limitation? (so I can have a coordinate type that is fast but also supports custom operations such as addition in rune)?

[udoprog]

It's an interesting suggestion. I have been thinking about something along the lines of supporting copy types.

There are broadly two approaches that are possible:

• We only support Copy types which can fit into an existing Inline Value. Coercing to and from these types would be handed a raw bit pattern and would have to validate that it matches the expected value (and possibly alignment if we take references) wherever it is accessed. This would however limit these copy types to be at most 64 bits wide.
• We change how the Rune memory model works to allow for variably sized allocations. This is currently handled by the (badly named) Stack type. The hurdle here would be that we need to also keep track of the metadata for these allocations so they can be cleanly deallocated if necessary and so that access to the stored data can be checked and managed correctly by the virtual machine.

I would definitely be interested in seeing some work on this, while I like option 2 it is by far the biggest rework. And how to track metadata is still an open question.

[Droggelbecher]

I think at this point neither is worth the hassle for me, I can work with u64s and pairs of ints for coordinates
fine, its a minor inconvenience, was just curious whether I miss an obvious way :)