Live data from Hacker News

Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

github.com

51–60 of 174 posts

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#51
post #43

This borrow checker runs at runtime, which I find not as interesting. Everything starts to look a lot like std::unique_ptr which I think is mostly unneeded as it ads pointer indirection. Could someone explain to me when one would use this? Is it for educational purposes perhaps?

Hey, I am the author of this, I made this mostly for the purpose of experimenting and playing around and trying out things rather than actually using this for production projects. Making a proper compile time checker is pretty complicated(possibly impossible) without actually getting into the compiler, this just intends emulate that behavior to some extent and have a similar interface. "educational purposes" -> well…

> pretty complicated(possibly impossible)

Rust does it at compile time, so why cant C++? to me this detail completely kills the usefulness of this project

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#52

This borrow checker runs at runtime, which I find not as interesting. Everything starts to look a lot like std::unique_ptr which I think is mostly unneeded as it ads pointer indirection. Could someone explain to me when one would use this? Is it for educational purposes perhaps?

Rust does "borrow checking at runtime" with RefCell .

right, but RefCell is optional. if you dont use that, you get checking at compile time.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#53
post #34
post #27

Earlier quoted context omitted.

Syntax, Schmyntax... I learned too many languages over the years and can't remember every syntax from the top of my head, but does it really matter?

Yeah it matters given how the whole argument falls on advanced aspects of the type system and templates. How can you speak with authority about a language you clearly aren't using day to day? I have never once missed the distance of an optional . The practical use of optional is that you know where T is going to be constructed and can reason about the memory layout. Using it as an alternative to T* has never even occ…

> The ideal of bundling a presence flag and a pointer together (which would be the default underlying representation unless it was specialised to hold a T* internally) is gross and inefficient

That's a defect in C++ rather than some principled objection though. Rust's Option isn't specialized, the Guaranteed Niche Optimisation kicks in exactly the same for &T as for most C-style enumerations, OwnedFd, NonZeroU8 or indeed my BalancedI8, this is one of those places where an engineer can see how to design the core language properly to deliver the same performance despite better ergonomics for everybody, not add a special hack.

In practice since C++ can't do that, the likely C++ 26 std::optional will be a specialization which just has a pointer inside it. This may mean lots of awkward word smithing to require that implementation or they may just trust that all the implementers will Do The Right Thing™, as with the Niebloids.

I try not to "speak with authority" about C++ because I don't think anybody has the necessary understanding to do so, including the people who wrote the ISO document, the compiler engineers, and Bjarne himself.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#54

What's the point of adding Option , Result and Rc/Arc when std::optional, std::expected and std::shared_ptr exist?

std::optional is a poor shadow of Option. It's what happens when C++ programmers who've seen a Maybe type in a window (years ago by the way, this isn't inspired by Rust, it was just stuck in the standardization process until C++ 17) but are starved of proper types and basic features like pattern matching try to imitate what they saw. As a result for example std::optional doesn't exist, because to a C++ programmer it…

std optional is based on boost optional which was written in 2003 before any sort of lambdas made monadic operations usable.

The main concern with that component was ensuring we can allocate stack storage for an object that may or may not be initialized.

The reference is easily achievable by using T* so is of minimal value, but also poses some more semantic problems since a reference is not copyable while an optional is.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#55
post #51
post #43

Earlier quoted context omitted.

Hey, I am the author of this, I made this mostly for the purpose of experimenting and playing around and trying out things rather than actually using this for production projects. Making a proper compile time checker is pretty complicated(possibly impossible) without actually getting into the compiler, this just intends emulate that behavior to some extent and have a similar interface. "educational purposes" -> well…

> pretty complicated(possibly impossible) Rust does it at compile time, so why cant C++? to me this detail completely kills the usefulness of this project

C++ cannot because it does not have the necessary information present in its syntax. It’s really that simple. C++ could add such syntax, but outside of what Circle is doing, I’m not aware of any real proposal to add it.

Also, Google (more specifically, the Chrome folks) tried to make it work via templates, but found that it was not possible. There’s a limit to template magic, even.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#56
post #51
post #43

Earlier quoted context omitted.

Hey, I am the author of this, I made this mostly for the purpose of experimenting and playing around and trying out things rather than actually using this for production projects. Making a proper compile time checker is pretty complicated(possibly impossible) without actually getting into the compiler, this just intends emulate that behavior to some extent and have a similar interface. "educational purposes" -> well…

> pretty complicated(possibly impossible) Rust does it at compile time, so why cant C++? to me this detail completely kills the usefulness of this project

Well thats how the current C++ compilers/standard is. There is a limit to what a header/library can do

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#57
post #38

Earlier quoted context omitted.

The Option type seems to have various standard Rust methods like expect() implemented that I don't believe std::optional has. I haven't checked recent C++ standards, but I don't believe you can use partial classes/extensions in C++ like some other OO languages to add these methods to a native type. Many helper functions commonly used in Rust also only seem to exist in C++23, which not ever project can be compiled und…

> The Option type seems to have various standard Rust methods like expect() Isn't that value()?

pub fn expect(self, msg: &str) -> T

So that says it's a method (its first parameter is the type itself, but named self rather than as a normal parameter so we can use method syntax instead of calling the function Option::expect) but it also takes an immutable reference to a string slice.

That second parameter, msg, is the text for a diagnostic if/ when you're wrong.

So, in a sense it's like value() but the diagnostic text means, when I was wrong...

  let goose = found.expect("Our goose finder should always find a goose");
... I get a diagnostic saying that the problem is with "Our goose finder should always find a goose". Huh. I think we know where to start trouble shooting.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#58
post #47
post #33

Earlier quoted context omitted.

Sorry, but I just get sick of people pontificating about the academics of type systems and monadics. Bored me to death. std::optional is an extremely useful and welcome addition to C++ that improves code quality, is easy to understand, and has easy to reason about code generation. No doubt there is something that could be demonstrated in Rust with Option that is compelling, but I'd rather people showed that so a basi…

The people criticizing std::optional are doing a very poor job. Here's the big issue: unchecked access to std::optional with operator* has undefined behavior when there's no value. This is unforgivably bad design since you can enforce exhaustive checking at compile time, but C++ isn't going in that direction. std::optional offers value() for checked access too, but that checks at runtime and throws an exception. It i…

can you show me how rust does this? I'm genuinely curious. I've made a toy example to show how c++ checks for undefined behavior at compile time, I am unaware of rust being able to do the same without runtime costs (however small they may be, this is a toy example after all) https://godbolt.org/z/cT9bqz8z7

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#59

Earlier quoted context omitted.

Step 1 of API design: Always make the easiest and shortest way the wrong way.

They were really in a pickle here. It’s easy to be snarky, but both options (no pun intended) have downsides. In short, do you choose consistency by default, or safety by default? This feels like an easy choice in isolation, but at the time this was being developed (and arguably even now), there’s no definitive plan to holistically move C++ code to being safe by default. So whenever that happens, a ton of things will…

> If I’m honest with myself, I probably would have made the same choices they did in this situation.

Some of the more modern proposals (std::optional is quite old) actually make an explicit appeal to WG21 not to choose consistency at the price of safety because it just needlessly makes the language worse. "But we made the language worse before" is more like a plea for help than an excuse.

Barry Revzin did this in his "do expressions" which are an attempt to kludge compound expressions into C++ which really wants them to be compound statements instead. For consistency, all the obvious mistakes you'll make in do expressions could introduce UB like they would in equivalent C++ core features, but Barry argues they should be Ill-Formed instead - resulting in your mistakes not compiling rather than having undefined behaviour.

Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20

#60
post #38

Earlier quoted context omitted.

> The Option type seems to have various standard Rust methods like expect() Isn't that value()?

pub fn expect(self, msg: &str) -> T So that says it's a method (its first parameter is the type itself, but named self rather than as a normal parameter so we can use method syntax instead of calling the function Option::expect) but it also takes an immutable reference to a string slice. That second parameter, msg, is the text for a diagnostic if/ when you're wrong. So, in a sense it's like value() but the diagnostic…

Are there no stack traces? Wouldn’t that point you to where to start trouble shooting?
Post reply on HN