News for hackers. Stuff that matters.
Re:Safety: A comparaison between Rust, C++ and Go by roca on Saturday July 30, 2022 @07:22AM (#32285947)
A function returning a value that depends on the lifetime of the function's parameter is not crazy at all. Every class getter method that returns a reference to a member of the class does this.
Re:Safety: A comparaison between Rust, C++ and Go by benreesman on Saturday July 30, 2022 @07:36AM (#32286018)
Sure. But returning the address of a stack-allocated object is (usually) broken.

There isn't a right and wrong here: sometimes you want to opt in to the check for that, sometimes you want to opt out of it.

Sometimes I actually do want to fuck with addresses on the stack in weird, potentially architecture-dependent ways, it's rare but it happens.

I happen to think that Rust's linear/affine typing is by far the most usable low/zero-cost memory management model that anyone has demonstrated at scale and a real achievement in practical computer science, but it comes at a pretty serious cost in `Box`-this and `Arc`-that and `Rc`-other-thing and generally the borrow-checker being a PITA about some stuff we're used to doing.

Rust is very cool and I use it, but the "using C/C++ is fucking strangers without protection"-vibe got old years ago.

Re:Safety: A comparaison between Rust, C++ and Go by tialaramex on Saturday July 30, 2022 @08:13AM (#32286188)
> returning the address of a stack-allocated object is (usually) broken.

What matters is the lifetime, where the object lives is a rule of thumb for guessing lifetime that results from C++ trauma.

Re:Safety: A comparaison between Rust, C++ and Go by ncmncm on Saturday July 30, 2022 @07:21PM (#32291378)
Hint: getters are code smell.

Getters that return references are code stink.