Thank you very much for your inputs.

I agree that it will be better to have the default value as last parameter, but with the parameter pack it is not possible.

About the callable parameters: it is an interesting idea, I think if the default parameter is callable also the other should be callable, it should be consistent. The main problem is avoid to have something over engineered.


> > > And you also claim that it is not useful to provide any special library support for
> > > v = p1 ? p1[42] : defaultValue;
> > > nor for
> > > v = p1 ? *p1 : computeDefaultValue();
I do not claim that it is not useful to provide a library to support the above cases, I just think that a std::coalesce function is enough useful to justify its existence also if it does not support the above cases. But again let's think if it is possible to support them without having something overengineered.

Also in another thread there is mentioned the idea of lazy load of the default value, the callable parameter may cover also the need of the lazy loads.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Marcin Jaczewski via Std-Proposals
Sent: Tuesday 6 July 2021 00:39
To: std-proposals <std-proposals_at_[hidden]>
Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Subject: Re: [std-proposals] Function proposal: generic value_or

wt., 6 lip 2021 o 00:06 Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> napisał(a):
>
> On Mon, Jul 5, 2021 at 5:53 PM Marcin Jaczewski via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > pon., 5 lip 2021 o 23:28 Arthur O'Dwyer via Std-Proposals
> > <std-proposals_at_[hidden]> napisał(a):
> > >
> > > On Mon, Jul 5, 2021 at 4:34 PM Roberto Romani via Std-Proposals <std-proposals_at_[hidden]> wrote:
> > >>
> > >> If the word “value” in the name of the function may create confusion then the function may be called “coalesce”.
> > >>
> > >>
> > >>
> > >> The goal is to have a function that makes cleaner and less error
> > >> prone things like v = p1 ? *p1 : p2 ? *p2 : defaultValue;
> > >
> > >
> > > So basically, you claim that
> > > v = p1 ? *p1 : p2 ? *p2 : defaultValue; is too confusing for
> > > the reader to understand at a glance, and you think the reader
> > > would prefer to see
> >
> > Where are clams of "confusing" in that quote (aside of name `value`)?
> > Roberto said that it makes code cleaner and this is true as you do
> > not repeat the same values.
> > and even could reduce complexity further:
> > ```
> > auto p1 = foo();
> > auto p2 = bar();
> > return p1 ? *p1 : p2 ? *p1 : defualtValue; ``` vs ``` return
> > std::coalesce(foo(), bar(), defaultValue); //I would prefer default
> > on last place but it could be hard to define ```
> >
> > > v = std::coalesce(defaultValue, p1, p2); .
> > > And you also claim that it is not useful to provide any special library support for
> > > v = p1 ? p1[42] : defaultValue; nor for
> > > v = p1 ? *p1 : computeDefaultValue(); .
> >
> > Yes this is true, `p1[42]` could be too specific but
> > `computeDefaultValue` be probably useful I could push even further
> > to allow to every argument will be callable,
>
> OK, so how do you tell the difference between a pointer-like type that
> just so happens to be invokable and an invokable type that just so
> happens to be pointer-like? Or even worse, what if the default value
> just so happens to be callable?
>

You can't or at least will be hard to predict every case what it is, this is why I used diffrent name for this case: `coalesce_func` where every argument is expected to be callable and then result is check.
This could require some helper functions that could "escape" value or labla like:

```
std::coalesce_func([&]{ return p1; }, computeDefaultValue); ``` probably I would like more a

```
std::coalesce_func(std::deferred(p1), computeDefaultValue); ```

`std::coalesce` require only `bool()` and `*` `std::coalesce_func` require callable that return value have `bool()` and `*`

I personally think that last default value should be last and simply do not have requirement for `*` But if this is problematic then Roberto version simply puts it on front and has different requirements for the rest of arguments.


> I don't know if this feature is worth the added complexity. Especially
> since it's not exactly easy to use with member functions or cases
> where you need arguments.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals