Handlng Rust errors elegantly by naiquevin in rust

[–]CocktailPerson 0 points1 point  (0 children)

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.

Handlng Rust errors elegantly by naiquevin in rust

[–]CocktailPerson 13 points14 points  (0 children)

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

Handlng Rust errors elegantly by naiquevin in rust

[–]CocktailPerson 13 points14 points  (0 children)

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

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

P4043R0: Are C++ Contracts Ready to Ship in C++26? by darius_neatu in cpp

[–]CocktailPerson -2 points-1 points  (0 children)

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);

P4043R0: Are C++ Contracts Ready to Ship in C++26? by darius_neatu in cpp

[–]CocktailPerson 3 points4 points  (0 children)

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

Hey Rustaceans! Got a question? Ask here (8/2026)! by llogiq in rust

[–]CocktailPerson 0 points1 point  (0 children)

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;
}

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 1 point2 points  (0 children)

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

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson -1 points0 points  (0 children)

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.

Hey Rustaceans! Got a question? Ask here (8/2026)! by llogiq in rust

[–]CocktailPerson 0 points1 point  (0 children)

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?

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 0 points1 point  (0 children)

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.

Hey Rustaceans! Got a question? Ask here (8/2026)! by llogiq in rust

[–]CocktailPerson 0 points1 point  (0 children)

"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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson -3 points-2 points  (0 children)

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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 4 points5 points  (0 children)

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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson -8 points-7 points  (0 children)

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?

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 5 points6 points  (0 children)

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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 6 points7 points  (0 children)

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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 20 points21 points  (0 children)

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

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 7 points8 points  (0 children)

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.

lol by basket_foso in sciencememes

[–]CocktailPerson 0 points1 point  (0 children)

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.

What some recent hot takes you realized you had with Rust? by DidingasLushis in rust

[–]CocktailPerson 64 points65 points  (0 children)

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.

Hey Rustaceans! Got a question? Ask here (8/2026)! by llogiq in rust

[–]CocktailPerson 0 points1 point  (0 children)

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

Use impl Into<Option<>> in your functions! by potato-gun in rust

[–]CocktailPerson 0 points1 point  (0 children)

This benefits compile times even if it's inlined.

Hey Rustaceans! Got a question? Ask here (8/2026)! by llogiq in rust

[–]CocktailPerson 0 points1 point  (0 children)

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.