Probably a better picture somewhere for this:

I was dead set on the total elimination of null until yesterday when I tried to populate a vector in Rust from an iterator in reverse.

I still think null should be handled with caution instead of just implicitly assigning it to all variables, but now I'm more open to compromise.

Update: converting a VecDeque into a Vec is really fast apparently.

@lorentz disagreed, annihilate null.

There is always a more natural way, that is better than null, which is even declared as a miskate by its creator.

If you really want null in rust for enums and stuff, you can always go and add a None element for example, and in a lot of cases you could also just use Option.

@thebiochemic Without the very clever coincidence that VecDeque - a totally unrelated datastructure that isn't standard in STLs - is convertible to Vec, how do you suggest solving this issue?

@lorentz what do you mean by totally unrelatable? They are absolutely relatable. Vec is in principle a Linked List and a VecDeque (the Name kinda gives it away) is a Doubly Linked List.

Even if i would convert them by hand, i don't see, how i would need null.
You just need to keep in mind, that their elements neighbours are not denoted by <pointer/ref to elem> or null but rather something like Option where None is the final dummy element of either end of the structures. And since they own the elements, this is not very hard to implement yourself (as an execise obviously).

@thebiochemic Obviously I could also just keep inserting elements to the vector at index 0 for a total of n² moved memory in n memmove calls, or I could push them and then reverse the vector for n moved memory in n/2 memmoves. The gist of the problem is that populating a vector from the back should require zero memmoves if the number of items is known in advance.

@lorentz ah okay, if you copy around the memory directly, that is a slightly different story true. But isnt that considered unsafe, if the type changes?
What about using a VecDeque from the very beginning, and avoiding it alltogether? Since they behave similar it should essentially be a drop in replacement (apart from changing push to push_back)