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