Idea #1 on integrating RC with GC

[Adam D. Ruppe]

On Wednesday, 5 February 2014 at 19:48:58 UTC, Namespace wrote:
> Hm, you're right. Would have been nice if the nice syntax could 
> be retained, instead of further unsightly library solution.

The thing is most slices don't need anything special - they are 
inspected, but not stored. Since they aren't stored, the 
allocation isn't this function's problem.

Yesterday, I wrote a post with a function int average(int[] 
numbers) as an illustration here. numbers might be on the stack, 
the Gc heap, or a refcounted array, and none of that matters. 
Average just looks at it. As long as there isn't something like 
another thread that frees the memory in the middle of average's 
execution, it will be fine. (And if there is a magic thread 
freeing things willy nilly, now that's a real WTF!)


This is why the borrowed idea (implemented by escape analysis in 
my mind, i think that would work and get us most the benefits 
without all of Rust's complexity) is nice: with a borrowed 
pointer, you explicitly know freeing it isn't your problem. You 
don't have to count or carry a refcount, you don't have to run 
the gc, you don't have to call free. You can take a lightweight 
slice and use it with confidence... as long as it doesn't escape 
the scope and thus accidentally stick around after the function 
returns.