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.

=====

One thing you may get pushback on is not a problem with your proposal but
rather a serious problem with previously accepted proposals:
https://godbolt.org/z/o8z8aj
Influential Committee members hold (or at least, previously held) the silly
idea that *most library constructors should be non-explicit*. This means
that for example it's possible to construct a std::string from {'a', 'b'},
or even from {"a", "b"} if you don't mind undefined behavior at runtime.
;) So almost all constructors in the STL are non-explicit these days.
Meanwhile, you're over here trying to exploit the *actually sensible*
position that non-explicit constructors should be used only for product
types like `pair`, so that if someone writes {"a", "b"}, it ought to be
obvious to the reader that they intend a pair of strings (and not, say, a
single string with UB at runtime).
These positions don't play well together. If the Committee is bent on
making it dangerous to use braced initializers — if {"a", "b"} can have UB
— then we shouldn't also encourage programmers to use *more* braced
initializers. Vice versa, if you want to encourage programmers to use more
braced initializers — if {"a", "b"} should be understood as a pair of
strings — then it might help to look for ways to make them *safer* to use.
And maybe we should hold off on the mass adoption of {} until the safety
problem is on its way to being fixed.

This is isomorphic to the situation with T(x)–style explicit conversions
and how they can sometimes secretly hide reinterpret-casts. We have a nice
syntax, but it feels slightly irresponsible to promote its use as long as
it has this kind of pitfall.
https://quuxplusone.github.io/blog/2020/01/22/expression-list-in-functional-cast/

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.

–Arthur