"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

Posted Sep 29, 2025 22:28 UTC (Mon) by theodorvaryag (guest, #179596)
In reply to: "Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other," by daroc
Parent article: Comparing Rust to Carbon

>you're taking input as an &[u8], but output as a &mut [u8].

Yeah this is incidental to me scaffolding a hypothetical API while very tired (I have a newborn, 4 children besides, and I didn't sleep much last night)

You can represent it as a single &mut [u8] and fan-out the aliased pointers behind the "safe" API. You can do more or less whatever you need/want to do and put a safe wrapper around it, I was just hewing too closely to the C FFI rough sketch in the safe API wrapper.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

Posted Sep 30, 2025 13:04 UTC (Tue) by daroc (editor, #160859) [Link] (2 responses)

I think we all wish we could get more sleep sometimes; I hope your newborns are well.

But yes, if you use a single &mut [u8], I agree that there isn't a problem. So I do believe it should be possible to safely wrap this interface by using a type like this:

    enum Example<'a> {
        InPlace(&'a mut [u8]),
        OutOfPlace { from: &'a [u8], to: &'a [u8] },
    }

I can't speak for Carruth, obviously, but given my understanding of his talk, I think his response would be something like: "But the point is that introducing a Rust API like that involves doing extra work to reshape the API, which complicates a piece-by-piece rewrite from C++; with Carbon, a piece-by-piece rewrite can do the initial change of languages and the cleanup of the API as separate, more easily understood steps."

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

Posted Oct 7, 2025 8:53 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

Or you could reshape the API on the C++ side before you move code to Rust.

This is a pretty weak motivation for Carbon IMHO.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

Posted Oct 8, 2025 2:04 UTC (Wed) by smurf (subscriber, #17840) [Link]

> Or you could reshape the API on the C++ side

That was my first thought too. I mean, the caller of this thing knows whether it's the same buffer or not. In-place modification in general allows for different optimizations than knowing that two regions don't alias.

IMHO the more apt comparison isn't greenfield vs. brownfield but, quite plainly, a culture where the C[++] users see the new kid on the block as an opportunity to clean up their own act i.e. their own interfaces, thus improving the C side of the codebase as well … or not.

Since the "or not" side is already served perfectly well by simply continuing to use C, for some value of "perfectly well" anyway. I kindof doubt that Carbon will get much traction. Which is for the best really (again IMHO): I'd rather see one effort to replace C++ with something sane+safe actually succeed, long-term, than three such projects, all with somewhat-conflicting goals and all fighting for developer mindset, not to mention time.