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:
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).
leak whatever resource the destructor is supposed to free (this is what I did).
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.
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.
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.
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.
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.
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.
It does kind of depends on the game. Super Mario Odyssey, Braid, and the original Portal had short maintenance windows, little use of networking, and very strict latency and throughput requirements. World of Warcraft, Minecraft, and Farmville are networking-centric application with fairly loose input latency requirements* and a very long maintenance window. The latter group have more in common with this forum than they do with the former group.
* A more accurate way to say it would be that they have simple enough graphics and control schemes that achieving acceptable performance on the front-end is trivial.
Safety isn't about security. It's about preventing crashes and undefined behavior; things that everyone in the gaming community hates, both developers and gamers.
Rust has panic!() and type-system-level knowledge of "divergence", with the specific mindset that stopping the program in a controlled way is better than just letting it go off the rails. Which, in the context of an application that deals with untrusted data in a non-life-critical context, is true. An out-of-bounds array access upon loading a web page in Firefox is very, very bad, and it's way better to just stop the tab than allow the guest web page to overwrite the stack pointer and jump you into a pile of shell code. Rust makes token gestures to help you continue making forward progress, but it's really designed to "let it crash" before things get out of hand.
There are other, potential, gains from this; not invoking UB means that diagnostics can be better, and failure types are more predictable and easier to test for, but Rust has long-standing bugs and misfeatures on libcore/option.rs:355:21 related to its diagnostic output, so you know that isn't where the priority lies.
Whether an application is designed for leisure or for business doesn't actually affect whether it has to act as a sandbox or not. A real-time data science simulation isn't all that different from a game of SimCity; anyone who cheats at it is only cheating themselves. A game of Mafia isn't too far off from a big shared workflow tracking database. If someone asked whether to use Jai or Rust, I'd almost exclusively make the call on whether it has to take arbitrary data from people who don't already have privileged access.
This has been covered before. [SOLVED] What is Safety? Safety is a subset of security; safety is not adequate for providing a secure environment. Anyway, this is getting off-topic. I responded to clear up the confusion caused by claiming that Rust is a hard sell for game developers because it enforces security features. Which it does not.
the items that have since been resolved.
