Item — HN Reader

> So the issue is clearly not solved.

You can use --sanitize=address to get this today, or use the Vmem-based temp allocator (which is only in the 0.7.4 prerelease and only for 64 bit POSIX) if you're curious how it feels and works in practice.

> I can see multiple issues with this:

There is a constant trade-off, and being as safe as possible is obviously great, but there is also the question of performance.

The context matters though, it's a C-like language, an evolution of C. So it doesn't try to be a completely new language with new semantics, and that creates a lot of constraints.

The "safe-C" C-dialects usually add a lot of additional annotations that doesn't seem particularly palatable to most developers.

> Am I still misreading the title if I read it as "C3 solves the same issues that the borrow checker solves"?

Yes I am afraid you do. But that's my fault (since I suggested the title, even though I didn't write the article), and not yours.

1 comments

> You can use --sanitize=address to get this today

By the same argument you could say that C/C++ also solved memory safety then. Do you compile production code with `--sanitize=address`? Note that certain sanitizers can be unsafe to use in production due to e.g. reading some environment variables.

> or use the Vmem-based temp allocator (which is only in the 0.7.4 prerelease and only for 64 bit POSIX)

FYI it would be useful to pair claims of features with documentation that describes how they work, otherwise we may be just talking past each other. Seeing "vmem" mentioned this seems like it is just going to leak virtual memory address space.

> There is a constant trade-off, and being as safe as possible is obviously great, but there is also the question of performance.

You're changing argument. You can claim that C3 does not aim to solve memory safety for these reasons, _and they can be understandable_, but then don't go and claim you solved memory safety anyway because that's plain false.

> Yes I am afraid you do. But that's my fault (since I suggested the title, even though I didn't write the article), and not yours.

Some more argumentation would be nice. How am I misreading the title? If I'm misreading it then there should be another way of reading it that's more obvious and make sense. I have yet to see a reasonable way of reading it where the mention of the borrow checker makes sense.

> You can claim that C3 does not aim to solve memory safety for these reasons, _and they can be understandable_,

This seems to be where we speak past each other. What the blog post talks is how C3 handles the problem of memory lifetimes for temporary data, which is a major lack of ergonomics in C (and arguably also C-likes, such as Zig).

The title refers to how C3 does this is in userland without having to add any of the common solutions, such GC, ARC, RAII. Recently a superset of C called "Cake" added ownership annotations exactly to solve such problems.

C3 doesn't have anything like Rust memory safety. Nor is the blog post about memory safety, but on memory lifetimes.

> The title refers to how C3 does this is in userland without having to add any of the common solutions, such GC, ARC, RAII.

No, the title does not mention any of those. Instead it mentions "borrow checking" and that solves a completely different problem that C3 does not even attempt to tackle.