News for hackers. Stuff that matters.
Re:T* makes for a poor optional<T&> by masklinn on Monday December 13, 2021 @04:54PM (#29545170)
> You can use `.value()`

Which is bad at every level if resolution: it’s more verbose to do “the right thing” (obviously), it’s more expensive to do “the right thing” (because if you’ve properly checked you’re paying the check twice and praying the compiler can remove the redundant check), and it’s incompatible with other pointers to do “the right thing” (because pointers use ! And *).

So .value() it mostly worthless, if it’s being used it’s an assertion with overhead which can take down your program.

> all the people who wanted it for the purposes of eschewing exceptions, the crowd who wanted `std::optional` the most, would be getting the verbose code.

And nothing of value would be lost (except for it not behaving as a “standard pointer” anymore).

Re:T* makes for a poor optional<T&> by kllrnohj on Monday December 13, 2021 @05:48PM (#29545704)
> it’s more expensive to do “the right thing” (because if you’ve properly checked you’re paying the check twice and praying the compiler can remove the redundant check)

Eh that's hardly a solid complaint here. Since these are header-defined templates, it's all inlined. And any compiler will absolutely remove those redundant checks as a result. And an unchecked .value() would still be available if you really did object to that "overhead", so it doesn't violate any C++ principals here.

I do kinda think that operator-> & operator* as a result did the assertion, and value() bypassed it. But this would also be the opposite behavior of other std:: classes, like std::vector (operator[] being unchecked vs. at() being checked).

Re:T* makes for a poor optional<T&> by germandiago on Monday December 13, 2021 @06:37PM (#29546206)
I do not think it is. What does the language do on * dereferencing? Yes, it does not do a check. So if you do it now you have to remember two different rules, one rooted deep inside C and C++ minimal overhead philosophy. Now multiply by the number of types (unique_ptr, shared_ptr, optional and probably more) and remember the correct rule.

I do not think there is something bad with it. It does the same for the same syntax and you have a `.value()` checked access anyway.

Re:T* makes for a poor optional<T&> by junon on Monday December 13, 2021 @06:04PM (#29545887)
> praying the compiler can remove the redundant check

It can in pretty much every single case even on -O1.

Re:T* makes for a poor optional<T&> by kitkat_new on Monday December 13, 2021 @06:34PM (#29546188)
I somehow have my doubts if that check was made in entirely different parts of the program
Re:T* makes for a poor optional<T&> by junon on Monday December 13, 2021 @09:35PM (#29547523)
What do you mean?