Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 174 posts

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

#41

Post by frutiger »

blegr wrote: post #37
nly wrote: post #34

Earlier quoted context omitted.

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 practical use of optional is that you know where T is going to be constructed and can reason about the memory layout. The practical use for me is making interfaces safer. Where I saw colleagues use pointers as optionals, end up mis-tracking what can be null and what can't, only checking it inconsistently, and triggering UB, I now have a clear distinction between optional and non-optional arguments/returns with…

> Most of the time, I want to pass/return a reference

Surprised to hear that you want to return a reference so frequently.

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

#42

Post by masklinn »

formerly_proven wrote: post #36
masklinn wrote: post #20

Earlier quoted context omitted.

> and operator* / operator-> throw std::bad_optional_access if it’s empty. Of course not, they’re literally `noexcept`, what they do is UB if empty. value() will throw.

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

C++ APIs follow the principle of most astonishement.

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

#43

Post by jmax01 »

macgyverismo wrote: post #2

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 kinda, I had some free time and had an interesting idea perhaps

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

#45

Post by mathstuf »

frutiger wrote: post #41
blegr wrote: post #37

Earlier quoted context omitted.

> The practical use of optional is that you know where T is going to be constructed and can reason about the memory layout. The practical use for me is making interfaces safer. Where I saw colleagues use pointers as optionals, end up mis-tracking what can be null and what can't, only checking it inconsistently, and triggering UB, I now have a clear distinction between optional and non-optional arguments/returns with…

> Most of the time, I want to pass/return a reference Surprised to hear that you want to return a reference so frequently.

These kinds of discussions remind me that not everyone codes in the same domain where the same patterns dominate. I think everyone would do well to avoid "but I don't need it, so it seems unnecessary" kinds of arguments and instead have the imagination that others may code in different domains where different patterns dominate.

Me? References get returned all the time because you want to access some state store's vector of things without copying the vector just to ask "are any of the elements X?" or adding a new method for every `std::algorithm` method for each member you might want to use it on.

The benefit of `optional` over `T*` in an API is that the former communicates "you have write access to this thing which may not exist" whereas the second needs documentation for whether `nullptr` is a thing and whether the caller needs to `delete` it (or was it `delete[]` this time?).

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

#47

Post by kaashif »

nly wrote: post #33
harry8 wrote: post #28

Earlier quoted context omitted.

In 2 sentences this comment encapsulates everything wrong with C++ culture that has caused so many terrible errors becoming standardized forever over the years. Sometimes being nice really pays off.

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 is possible to have an optional with no runtime check, no undefined behaviour, and guaranteed handling of both cases by checking at compile time. This is what Rust offers.

Undefined behaviour being easy to invoke absolutely does matter for real world code.

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

#48

Post by [deleted] »

nly wrote: post #33
harry8 wrote: post #28

Earlier quoted context omitted.

In 2 sentences this comment encapsulates everything wrong with C++ culture that has caused so many terrible errors becoming standardized forever over the years. Sometimes being nice really pays off.

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…

[deleted]

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

#50

Post by steveklabnik »

formerly_proven wrote: post #36
masklinn wrote: post #20

Earlier quoted context omitted.

> and operator* / operator-> throw std::bad_optional_access if it’s empty. Of course not, they’re literally `noexcept`, what they do is UB if empty. value() will throw.

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 need to be dealt with, and there’s always the possibility that being an odd API here makes that overall move harder not easier. And C++ is regularly criticized for being inconsistent. Do you deepen those criticisms just so that one tiny corner of an API is better?

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

Post reply on HN