3 ms·
> I.e., the called function should not make any assumptions how the memory was allocated, what is its lifetime It needs to at least make the assumption that th
by the_mitsuhiko 9y ago
> I.e., the called function should not make any assumptions how the memory was allocated, what is its lifetime
It needs to at least make the assumption that the memory will not be invalidated while the function did not return. In the presence of multi threading that in itself might already be surprisingly hard to guarantee sometimes. Also typically functions make assumptions about the immutability of things in such cases which are often just not true.
- jstimpfle 9y agoProblems with multithreading and "perceived immutability" are two more things that can largely be ruled out with a clear dataflow architecture. For example, I try to not have "cycles" such that a function call overwrites a memory location that was a (pointer) argument to the caller. I don't think that should happen - where did the called function get the pointer from without the caller knowing? An architecture with global data tables instead of OOP helps here, because it has much lower need for pointer arguments of unclear origin. I also agree very much with your approach "handles instead of pointers" (if by handles you mean integer array indices). Indices for example trivially survive reallocation of a dynamically growable array.
- amarkov 9y agoSure, but isn't that the point for Rust? You can rule out huge classes of problems with a clear dataflow architecture - thus, the language should enforce one, rather than requiring programmers to hand-roll one correctly.
- jstimpfle 9y agoI've never used Rust, but my impressionn is it's quite constraining... The syntax alone turns me off.