"Bill why do you hate optional<T&> so much?" Bill:
-
@malwareminigun Playing on compiler explorer with GCC trunk, consider
https://compiler-explorer.com/z/hTb9dT8zqWhen you disable the lines returning ptr, and instead enable the lines returning optRef, the assemly is the same for me.
And I tried to prevent the optimizer from being too smart with some random number generation.
What am I missing?
@asperamanca -O3 is not “debug perf” ; inlining + Scalar Replacement of Aggregates can remove the runtime costs but not the debug perf, compiler throughput, and debug UX costs.
-
@asperamanca -O3 is not “debug perf” ; inlining + Scalar Replacement of Aggregates can remove the runtime costs but not the debug perf, compiler throughput, and debug UX costs.
@malwareminigun Ah, I missed that detail.
Well, that's a tradeoff to consider, of course. -
Everyone quick hide me from @thephd
@malwareminigun It's a good change!
-
@malwareminigun It's a good change!
@thephd I'm surprised you would say that
-
R relay@relay.infosec.exchange shared this topic
-
@thephd I'm surprised you would say that
@malwareminigun Optional references was never a dogma about replacing pointers. It was moreso a tool for generic improvements and code safety (at the cost of simplicity and debuggability). You can't trap every pointer dereference in C or C++, but you can absolutely trap optional failures; it was only ever meant to be an additional tool in the toolbox.
Hopefully we can get
variant<T&, ...>andexpected<T&, ...>to play ball in the same way, so we just have a functional ecosystem where I can choose between "blow my leg off" (raw union, raw pointer, error-code-and-out-param) and "set me up nicely and keep it lean & clean" (optional/variant/expected references). -
@malwareminigun Optional references was never a dogma about replacing pointers. It was moreso a tool for generic improvements and code safety (at the cost of simplicity and debuggability). You can't trap every pointer dereference in C or C++, but you can absolutely trap optional failures; it was only ever meant to be an additional tool in the toolbox.
Hopefully we can get
variant<T&, ...>andexpected<T&, ...>to play ball in the same way, so we just have a functional ecosystem where I can choose between "blow my leg off" (raw union, raw pointer, error-code-and-out-param) and "set me up nicely and keep it lean & clean" (optional/variant/expected references).@thephd Pretty sure a lot of the folks who wanted optional<T&> were dogmatic about replacing pointers
. Of course with standardization rarely does everyone want something for the same reason.Kinda reminds me of what happened with string_view. Google wants it because they see 1% of fleet-wide CPU for Google being spent in strlen, so they want no brakes. Microsoft wants it because they're pushing GSL and want to shut down memory safety issues so they wanted it to bounds check.
Not sure how I feel about variant and expected. (Note that variant models a discriminated union and the core language forbids reference members of unions https://eel.is/c++draft/class.union#general-4 )
-
@thephd Pretty sure a lot of the folks who wanted optional<T&> were dogmatic about replacing pointers
. Of course with standardization rarely does everyone want something for the same reason.Kinda reminds me of what happened with string_view. Google wants it because they see 1% of fleet-wide CPU for Google being spent in strlen, so they want no brakes. Microsoft wants it because they're pushing GSL and want to shut down memory safety issues so they wanted it to bounds check.
Not sure how I feel about variant and expected. (Note that variant models a discriminated union and the core language forbids reference members of unions https://eel.is/c++draft/class.union#general-4 )
@malwareminigun @thephd IIRC google saw advantage from string_view over std::string const&.
And it's not like they don't like their bounds check, they want to change the layout of std::vector in libc++ to be T* + 2x size_t, because it makes `size()` calls faster, and they do bounds checking on every `operator[]` call.
-
@malwareminigun @thephd IIRC google saw advantage from string_view over std::string const&.
And it's not like they don't like their bounds check, they want to change the layout of std::vector in libc++ to be T* + 2x size_t, because it makes `size()` calls faster, and they do bounds checking on every `operator[]` call.
@horenmar I mean I think that shows that Google isn’t a hive mind
-
Everyone quick hide me from @thephd
@malwareminigun @thephd
Technically my fault.
@thephd just conclusively demonstrated that all other answers for optional<T&> were even worse. -
@malwareminigun Optional references was never a dogma about replacing pointers. It was moreso a tool for generic improvements and code safety (at the cost of simplicity and debuggability). You can't trap every pointer dereference in C or C++, but you can absolutely trap optional failures; it was only ever meant to be an additional tool in the toolbox.
Hopefully we can get
variant<T&, ...>andexpected<T&, ...>to play ball in the same way, so we just have a functional ecosystem where I can choose between "blow my leg off" (raw union, raw pointer, error-code-and-out-param) and "set me up nicely and keep it lean & clean" (optional/variant/expected references).@thephd @malwareminigun
And deref on optional<T&> has a _hardened_ precondition. -
@malwareminigun Optional references was never a dogma about replacing pointers. It was moreso a tool for generic improvements and code safety (at the cost of simplicity and debuggability). You can't trap every pointer dereference in C or C++, but you can absolutely trap optional failures; it was only ever meant to be an additional tool in the toolbox.
Hopefully we can get
variant<T&, ...>andexpected<T&, ...>to play ball in the same way, so we just have a functional ecosystem where I can choose between "blow my leg off" (raw union, raw pointer, error-code-and-out-param) and "set me up nicely and keep it lean & clean" (optional/variant/expected references).@thephd @malwareminigun
Placeholder for now:
https://github.com/bemanproject/expected -
@thephd @malwareminigun
And deref on optional<T&> has a _hardened_ precondition.@Sdowney Not sure how meaningful that is because nullptr* is checked by the operating system / hardware on every platform that matters. nullptr isn't a problem, only wild pointers
(Yes I know that isn't technically true for PMFs/PMDs always but those are not used too often)
-
@thephd Pretty sure a lot of the folks who wanted optional<T&> were dogmatic about replacing pointers
. Of course with standardization rarely does everyone want something for the same reason.Kinda reminds me of what happened with string_view. Google wants it because they see 1% of fleet-wide CPU for Google being spent in strlen, so they want no brakes. Microsoft wants it because they're pushing GSL and want to shut down memory safety issues so they wanted it to bounds check.
Not sure how I feel about variant and expected. (Note that variant models a discriminated union and the core language forbids reference members of unions https://eel.is/c++draft/class.union#general-4 )
The variant is the reference type for the iterator for the heterogeneous collection that is std::tuple.
This works, really, but fails because tuple can hold a reference.
-
The variant is the reference type for the iterator for the heterogeneous collection that is std::tuple.
This works, really, but fails because tuple can hold a reference.
@Sdowney I'm not sure how useful such an iterator is, particularly given that variant and tuple probably want different answers on the rebind vs. assign-through question. (tuple must be assign-through for std::tie/std::forward_as_tuple et al. to work. But @thephd showed us that variant probably wants rebind instead?)
I know it's encouraging to think of optional<T> as variant<monostate, T> but assignment is one place I can't mentally make them agree
