There’s some ongoing committee reflector discussion of additional optional capabilities – including this proposal:
This seems like a great project for C++Now Library in a Week that someone could implement on top of the current beman.optional. I think, as usual, this might reignite the discussion about how that should be done – new repo, in the existing repo? My $.02 is it should be done in the existing repo with an option that the feature can be removed by a build setting if desired – although I’d be fine with it just always being there.
I will of course read the fine paper before criticising too heavily, but I do know that trying to change the signature of value_or broke some existing code when I tried. So I’d want strong evidence of non-breaking for any changes. Optional is unfortunately fairly delicate.
I haven’t touched it recently since it was not going to be feasible at that point for 26, but I think the right answer is some free functions in this space for nullable or maybe kinds that would include raw pointers and would use the common reference type machinery from ranges to compute the return type, as well as the constructs/converts from temporary checks.
P1255 had some work towards this in the most recent version.
To be clear, the paper proposes pure additions and doesn’t attempt to change the existing methods. And to make it easy for you it’s literally just this:
emplate<class ... Args> constexpr T value_or_construct( Args &&... args ) const &;
template<class ... Args> constexpr T value_or_construct( Args &&... args ) &&;
template<class U, class ... Args>
constexpr T value_or_construct (initializer_list <U> il, Args&&... args>) const &;
template<class U, class ... Args>
constexpr T value_or_construct (initializer_list <U> il, Args&&... args>) &&;
template <class F> constexpr T value_or_else (F&& f) const &;
template <class F> constexpr T value_or_else (F&& f) &&
Some of this comes from jealousy of expected which got a couple other monadics since people made a case for them as the paper ran through the committee.
If you haven’t seen it already, have a search on the lib-ext reflector for Nico’s post with optional or_else.
I have to sit down with Corentin and hash this out, but I want all of these, but also for a plain T*.
Anything dereferenceable and contextually boolean, really. Steal the Maybe monad to go along side the List monad we stole for ranges. Excuse me, “borrowed”.
I have a nice number on hold for trees and traversable, as well.
Fair, but those other ones wouldn’t really prevent these being added by a volunteer at the conference – under some sort of experimental or feature test mode. In any case we can discuss more in aspen
– under some sort of experimental or feature test mode. In any case we can discuss more in aspen