My gamedever wishlist for Rust


#62

The problem with a write-only slice is that overwriting an existing value forces one of these three things to happen, even if the feature is built-in to the language:

  1. disallow write-only slices of Drop-implementing data (this cannot be done directly in Rust’s type system, but only allowing Copy data is probably close enough).
  2. leak whatever resource the destructor is supposed to free (this is what I did).
  3. violate the write-only contract (this is what @llogiq wom does, and I should probably tell him that his lint will have to implement 1 or 2 to be sound).

This problem does not exist if no overwriting happens (namely, the write-only reference is to uninitialized data, and must be written exactly once), but that would have to be a true linear type.


Edit: Added support for iteration to that demo. Maybe I should put this on GitHub…


#63

Couple of ideas

  • implemented Deref and Index (no need for set_at anymore)
  • made IntoIterator impl more generic
  • added macro to encapsulate unsafe unwrapping of Wom so you can access members of structs

#64

Please note that the data should not stay write-only forever – I think the basic pattern is to take a slice of memory, borrow it and give a write-only pointer to it to either the caller or a callback and do something else with the memory once you’re done.

Also using a Copy bound is probably out of the question because Copy and Clone aren’t available for arrays larger than 32 elements.


#66

Not sound. The Deref impl for T might read from the internal T. The only reason WomIter is sound is that I know iter::Slice doesn’t read from the referenced memory.

Same problem. The only reason the slice WomIter is sound is because it doesn’t actually read from the array.

I … think that actually is sound.

I uploaded it to GitHub.

Even included your macro!

https://github.com/notriddle/rust-wom


#67

Ah, you’re right. Sorry about that. I initially tried Index for just Wom<[T]> but got a little carried away I guess (which then lead the way to Deref and the IntoIterator expansion).

Also, is allowing it to be instantiable sound? If you have x: &mut Wom<T>, then you could do *x = Wom::new(other_t), which would read from it, right? At least I think it would if T has a destructor, I don’t know if it would if it doesn’t.


#68

You’re right; if it has a destructor, assigning like that will cause it to run. It won’t otherwise read from it.


#69

The fold would only work properly as long as none of the values are below zero (like unsigned integers). The initial value would probably just have be MIN instead.


#70

Have you looked at acacia, or are you looking for something more specialized?


#71

3 years later, how are things looking? I wiki’d your post so if you’d like you could :white_check_mark: the items that have since been resolved.


#72

Would be interested to know how things have evolved as well. Just got into playing around with rust and would like to know what existing tech is already available for real-time applications/ games. And how it has evolved.


#73

Where is that Wiki at?


#74

I think it’s a reference to community wiki. The initial post is editable now.


#75

You can also use entr if you are on linux.


#76

Marked android issues as solved.

Not sure, but I would say that mint crate has solved the issue of compatibility between math crates (or being independent from them).

Both libraries have evolved since this post, but “has a very bad API” is a vague statement so I’m not sure if this can be marked as solved.


#77

5 posts were split to a new topic: Cgmath looking for new maintainers