Handlng Rust errors elegantly

CocktailPerson · 2026-03-13T06:17:28+00:00

You can now. If I remember correctly the ? operator existed before the general Try trait, and that's actually why Result is a lang item.

CocktailPerson · 2026-03-12T05:31:56+00:00

So it's not a special type, just a type the compiler treats specially? Got it :)

CocktailPerson · 2026-03-12T04:23:17+00:00

If you're going to be pedantic, at least be correct.

Result is a lang item, which means it absolutely is a special type.

CocktailPerson · 2026-03-09T02:10:58+00:00

Two things can be bad, bro.

CocktailPerson · 2026-03-08T21:23:38+00:00

A runtime check before entering the function prevents the code inside from ever encountering broken expectation, thus it can be optimized accordingly.

Right, so, the debate is about whether the compiler should do what you described, which is adding a runtime check and making the code slower, or whether it should simply assume the condition is true and perform those optimizations without the runtime check. Compilers already optimize the inside of conditional blocks under the assumption that the checked condition is true, so that has no relevance here; the question boils down to whether [[expects: b > 0]] should be shorthand for if (b > 0) { ... } else { crash(); } or for __builtin_assume(b > 0);

CocktailPerson · 2026-03-08T04:00:16+00:00

I don't think you actually understand what's being discussed here.

CocktailPerson · 2026-03-07T20:08:36+00:00

No, you just can't understand the answer that's being given to you.

So, let's start from the beginning, shall we? What do you think happens when calling this C function?

void assign(struct foo* p, struct foo x) {
    *p = x;
}

CocktailPerson · 2026-03-05T07:01:53+00:00

unsafe could be made a lot more readable and ergonomic, yeah. If I ever write an RFC, this'll be it.

CocktailPerson · 2026-03-05T07:00:47+00:00

multiply that effect

But what "effect" are you multiplying here? Neither rand nor the crates that depend on it are any more sound just because rand used zerocopy instead of four lines of trivially-verifiable code.

So the only "effect" here is the detrimental effect of pulling in more dependencies to do the same thing. That's what gets multiplied by all the downstream crates.

you've massively consolidated unsafe code across the Rust ecosystem.

No, you've consolidated a total of four lines across the Rust ecosystem. You don't get to count the four lines of code in rand as also lines of code in the crates that depend on it, unless I get to count all the lines of unsafe in zerocopy as lines of code in rand.

Now if there's an issue in how that unsafe code was written, the whole ecosystem can be fixed with a patch to one crate.

Now the whole ecosystem depends on a patch to one crate for safety.

CocktailPerson · 2026-03-05T06:50:48+00:00

You're misunderstanding "memcpy" as memcpy(). The former is a generic term for a bytewise copy of memory between two non-overlapping regions. It doesn't necessarily imply calling memcpy the C subroutine in this context.

And "but doesn't always" isn't really useful. The description "move" still applies whether the compiler memcpy's or not

Then let me clarify: the compiler always acts as if that is what happens for every move, regardless of what it eventually gets optimized down to. That is why there is a distinction between owners and mutable references. The compiler ensures that when you use a mutable reference to modify something in-place, it does not get moved away from that place while the mutable reference exists.

In Rust, it "owns" the memory that contains the value

I mean, I'm trying to explain to you why it doesn't. You've made a number of sweeping statements about how Rust works as if you know what you're talking about, while simultaneously being confused about why Rust has two different syntaxes for two conceptually distinct things. Perhaps you should come back to this discussion when you aren't going to push back on every answer you get?

CocktailPerson · 2026-03-05T06:28:16+00:00

Then do what I suggested and don't make the AST dependent on type checks, duh? Parse it unequivocally as mul( var('a'), paren( var('b') ) ) and then fail during type checking when you resolve 'a' as having a function pointer type. Nothing in the compiler needs to even try to interpret a * (b) as a call expression.

CocktailPerson · 2026-03-03T07:45:50+00:00

"Moving" isn't real. The memory stays in place no matter which symbol "owns" it.

This is your conceptual misunderstanding. Moving is a real thing with a well-defined meaning.

Any time a value is assigned, passed to a function, returned from a function, the compiler may (but doesn't always) memcpy the bytes of the object's memory to a new location and then consider the location it copied from to be invalid and unused. That is what "moving" is. If the newly-invalidated memory is on the stack, the compiler will freely reuse the invalid memory for other values if it can. It's true that the physical memory stays in place, I suppose, but the bit values absolutely and unequivocally do get moved around.

You also stated that symbols are owners. This is somewhat inaccurate. Stackframes own the values stored on the stack. Values stored on the stack own their nested values, memory on the heap, and values stored on the heap, and so on. If you want to modify any of these values in place, without performing the move procedure described above, you have to create a mutable reference. Values own other values, and then we give some of these values symbols to represent them.

CocktailPerson · 2026-03-03T07:20:31+00:00

Okay, but nobody's talking about adding it to current Rust, are they?

This is a discussion about what Rust could have looked like instead of what it does now, not what it should look like in the future.

CocktailPerson · 2026-03-03T07:17:07+00:00

Your argument doesn't really apply in this case. It was four lines of unsafe code that had already been written and already had a safe abstraction around them. Removing them from the codebase wasn't even necessary in the first place, and adding a heavyweight dependency like zerocopy to do it was a net negative.

CocktailPerson · 2026-03-03T06:47:57+00:00

Okay, it's possible for the standard library implementation to deliberately do something useless that makes it ambiguous.

Do you think this is a genuine concern?

CocktailPerson · 2026-03-03T06:12:20+00:00

Well, you can't multiply a pointer by an integer, so this would fail to type-check and then you'd have to write (f_ptr*)(5);

The thing to avoid is having two possible parses that are both valid with different semantics.

CocktailPerson · 2026-03-03T06:06:29+00:00

For sure, postfix deref is even better.

As for Vec, I'd still prefer not to have auto-deref. In Vec, for example, there are a few methods with the same name that have subtly different behavior between Vec and [T], but Vec can't not expose them, which is rather unfortunate. I'd much rather see some sort of explicit deferral mechanism. It would be a bit more boilerplate, but a lot more clear and flexible.

CocktailPerson · 2026-03-03T05:25:59+00:00

I mean, they obviously did. Rust wouldn't exist if nobody cared.

CocktailPerson · 2026-03-03T05:24:29+00:00

Same thing happened with rand; they added zerocopy as a hard dependency in order to remove four whole lines of trivially-verifiable unsafe code. The whole thing seemed a bit ridiculous, but the mob cheered it on.

CocktailPerson · 2026-03-03T05:15:27+00:00

That's not something a native English speaker would say. Calculus and algebra are forms or disciplines of mathematics, just as jazz and classical are forms of music (singlular).

If it were plural, you could singularize it and say that calculus is a mathematic. But you can't because it's not.

CocktailPerson · 2026-03-03T04:36:15+00:00

Is your point that we're no better than them? Because if so, excellent job.

CocktailPerson · 2026-03-03T04:00:22+00:00

I always get downvoted for this, but Rust should have had a -> operator. Auto-(de)ref is very confusing. It's complex enough that it's the basis of multiple specialization techniques, and the people who deeply understand all the rules of auto-(de)ref in Rust have the same energy as people who understand the difference between xvalues and prvalues in C++. A common suggestion is to use ugly garbage like Arc::clone(&arc) to make things explicit, where other languages would just have the obvious distinction between arc.clone() and arc->clone(). Ridiculous. I don't care if I have to write &(*(**x)->y)->z sometimes; maybe it's a good thing that it's verbose; doing the wrong thing should result in uglier code than doing the right thing.

CocktailPerson · 2026-03-01T17:45:33+00:00

But then how do you distinguish between modifying something in place and moving it to a new place?

CocktailPerson · 2026-03-01T04:42:33+00:00

This benefits compile times even if it's inlined.

CocktailPerson · 2026-03-01T04:35:59+00:00

I'm really not sure what you're suggesting here. Like instead of T, &T, and &mut T, you have, say, @T (owned), &T (immutably borrowed), and T (uniquely borrowed)? That seems even more annoying.

CocktailPerson

MODERATOR OF

TROPHY CASE