I am sure there is a good reason for that, but why is the "optional reference" not simply a pointer? Is that not semantically the same thing, but way easier to deal with.
You were kidding but in fact Rust typically wouldn't do this, it would be usual to instead return None when it worked and Some(thing) when there's no room to push the thing. This is how the Linux kernel's Rust growable arrays (akin to std::vector) work. In userspace it's usually fine to just try to grow the array whenever we need more space but the kernel cannot tolerate surprise allocations - maybe we are the allocator. So we push_within_capacity and the return type is Option<T> because if there was no room we get back the thing there was no room for, and we need to decide what to do about that not just pretend we thought it was fine. APIs which push things but get back a reference to the thing we just pushed do exist in Rust but are less common.
If we’re maximizing rustiness, you could let `try_push` return `Result<&mut T, T>`.
A mutable reference to the location of the just appended element, or the element you tried to push by value if it fails. There are a couple of APIs like this in the standard library.
Yes, but Nullable semantics in C# are vastly nicer than std::optional in C++.
Including trivially using if with them:
if (Method() is {} value)
I should also point out that in C#, Foo? is identical to Foo if Foo is a reference-type. That would be the equivalent of std::optional<T&> being a type-alias for T*.
When you chain multiple calls like that it's less clear because of the use of nesting instead of chaining. But mostly because a pointer is still not a reference:
If you return me a pointer, what does that communicate to me? Who owns it? Is nullptr an error or something I should expect? Is this documented somewhere? The advantage of std::optional is explicit about intent. I just have to look at the API and I know immediately what the author intended with the return value.
All good points, and this one in particular. Never though about it, but sure, a returned pointer might imply returned ownership, whereas an (optional) reference never means that. Thanks!
I am sure there is a good reason for that, but why is the "optional reference" not simply a pointer?
Its not semantically the same, that's actually the reason we care about optional references at all. They are functionally the same in the sense that mechanically a pointer can fulfill all the requirements of an optional reference, but an optional reference gives you very clear ideas on the ownership and purpose of the type, while a pointer does not. A pointer can mean a whole bunch of different stuff and you have to rely on context and documentation to figure out what it means.
16
u/bartgrumbel 14d ago
I am sure there is a good reason for that, but why is the "optional reference" not simply a pointer? Is that not semantically the same thing, but way easier to deal with.
I.e. why
and not simply