On Wed, Oct 28, 2020 at 10:17 PM Giuseppe D'Angelo <
giuseppe.dangelo_at_[hidden]> wrote:

> Il 27/10/20 20:33, Arthur O'Dwyer ha scritto:
>
> On Tue, Oct 27, 2020 at 2:58 PM Giuseppe D'Angelo via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I'm now able to post a draft for my proposal to default some algorithms'
>> template type parameters, so that they become usable with
>> list-initialization. It's currently sitting here (waiting for a number):
>>
>> > https://www.kdab.com/~peppe/cpp_proposals/algorithm_list_init/
>>
>
> The Tony Tables should also show the code/"workaround" that *does* work
> today. Your proposal isn't letting me express anything that isn't already
> expressible, right? You're just proposing a new shorter syntax for what's
> already expressible? So you should show (on the left side of the Tony
> Table) a valid way to express it in C++20.
>
> Not just "today it's a syntax error, tomorrow it's not a syntax error."
> That's not a Tony Table.
>
> Fair enough ; I'll amend it :)
>
Since Barry gave some pushback here, I'll reinforce my position:
*This is a Tony Table—*

// Before Concepts and Ranges
template<class It, std::enable_if_t<nonstd::is_forward_iterator_v<It>>* =
0,
std::enable_if_t<nonstd::is_sortable_v<std::iterator_traits<It>::value_type>>*
= 0>
It my_partition(It first, It last);

// After Concepts and Ranges
template<std::forward_iterator It> requires
std::sortable<std::iter_value_t<It>>
It my_partition(It first, It last);

*This is not a Tony Table—*

// Before Concepts and Ranges
template<std::forward_iterator It> requires
std::sortable<std::iter_value_t<It>>
It my_partition(It first, It last);





*<source>:4:15: error: 'std::forward_iterator' has not been declared4 |
template<std::forward_iterator It> requires
std::sortable<std::iter_value_t<It>> | ^~~~~~~~~~~~~~~~<source>:4:36:
error: 'requires' does not name a type4 | template<std::forward_iterator
It> requires std::sortable<std::iter_value_t<It>> | ^~~~~~~~*

*Compiler returned: 1*

// After Concepts and Ranges
template<std::forward_iterator It> requires
std::sortable<std::iter_value_t<It>>
It my_partition(It first, It last);
*Compiler returned: 0*

=====

I think I'm on your side in this case: I'd rather permit the nice syntax,
> and then work on closing up the loopholes so that the nice syntax can be
> guaranteed always to mean the nice thing (and never the dangerous/UB
> thing). But (1) the Committee may disagree with this order of operations,
> and (2) in your particular case, the Committee has *actively worked to
> open these loopholes* in the fairly recent past and may not even *want*
> to close them.
>
> When you say "particular case", are you implying that the omission of the
> default template parameters for _algorithms_ has been deliberate? Insofar,
> I've just received actual confirmations of the opposite -- the omission has
> just been an oversight, or just legacy (for C++98 algorithms, where one
> didn't even have initializer lists...).
>
No, I meant...
There are two similar situations on my mind:
- Should people use T(x) to mean "convert x to T"? This syntax is really
pretty, when it does the right thing; but it doesn't always do the right
thing
<https://quuxplusone.github.io/blog/2020/01/22/expression-list-in-functional-cast/>.
We should close the loopholes that make it dangerous to use.
- Should people use {x,y} to mean "a product type with elements x and y"?
This syntax is really pretty, when it does the right thing; but it doesn't
always do the right thing
<https://quuxplusone.github.io/blog/2018/12/11/dont-inherit-from-std-types/#and-you-ll-see-that-you-now-get>.
We should close the loopholes that make it dangerous to use.

Set CART = "encourage people to use the feature in more situations."
Set HORSE = "close the loopholes that make the feature dangerous."

Should we do CART before having done HORSE?

In the case of T(x), I'm ambivalent. People are already doing CART anyway;
and influential people like Richard Smith have expressed mild interest in
HORSE, so I think it makes sense to focus our efforts on HORSE.
In your particular case of {x,y}, I'm also ambivalent. Influential people
like Nevin Liber (P1163
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1163r0.pdf>) have
expressed strong aversion to HORSE, so, to a first approximation, HORSE
will never happen. Also, people today are physically prevented from doing
CART. Your proposal proposes to permit people to do CART, knowing that
HORSE will never happen.
So there are (at least) two possible positions: Nicol's "I don't want CART
without HORSE" and my "well, we obviously can't get HORSE *before* CART, so
we might as well get CART and see if that helps the HORSE to follow."

When I put it all this way, my position seems stupid; seems like I *should*
be opposing this proposal. :)

–Arthur

>