Hi. I'm not really super smart about this stuff, but there are a few things I'm confused on, that I think I might be able to understand. So from the blog:
> Type-specific allocation turns every "use after free" bug into a logical bug > but no memory corruption can happen. But memory corruption did happen. dangling was what got corrupted. dangling.x turned from 3 to 4 without warning. That could be severly bad if you say for instance had something like dangling.accountbalance or dangling.secondsuntilexplosion. Am I missing something? I thought that was what was most evil about memory corruption: when there's a pointer to freed memory that gets reallocated so no segmentation fault, but the underlying data got unpredictably changed. > # error: cannot capture an owned 'label' as it is consumed in 'createUI' Wouldn't the "owned" proc be what consumed label, and the error would be "cannot transfer ownership to createUI, as it is consumed by anonymousclosure345781?" I suppose that's quibbling over details, but I thought "capture" and "take ownership" were pretty much the same. > iso and trn are 2 new types as opposed to my owned type Aren't you going to add immutable to the type system, making owned immutable and owned mutable? Because trn maps to owned and immutable , and ref is owned and mutable as far as I can tell. And iso is just weird, so I dunno. Seems to me there are two independent problems here. First, how to determine when there are no more ways to access some object so it can be deallocated. Second, how to mutate an object with multiple pre-emptive threads that could be reading from it, or trying to mutate it themselves. Since the second problem can be easily solved with mutex locks, I really hope you succeed on the first. I do so love moving data, and garbage collection can be horrible to debug when the code that triggered the error during collection finished and returned a long time ago. It's just really nice to know exactly what the program's current state is, which garbage collection makes very unclear.
