Date: Wed, 7 Jul 2021 10:01:27 +0100
How about proposing the elvis operator instead?
On Tue, Jul 6, 2021 at 9:12 PM Roberto Romani via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
On Tue, Jul 6, 2021 at 9:12 PM Roberto Romani via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2021-07-07 04:01:41