Hello,

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]
> <mailto: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 :)

> 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.

Thanks for the insights.

Whether implicit list initialization should be used only for aggregates,
product types and containers (to fill them with contents via their
std::initializer_list constructors, *not* to select other constructors),
and not in other cases, is up for debate. At a first glance, I'd tend to
agree -- at least, that's how I tend to use it...

But if I have to, I'll say it out loud: I don't have any "secret agenda"
trying to settle this debate here and now. There are legitimate
non-niche use cases for implicit brace init, and all I want from this
proposal is to remove the annoyance from stdlib algorithms. I'll leave
the broader plans on "how and when are you supposed to use implicit list
initialization" to another audience and through other means (coding
policies, C++ core guidelines, linters, etc., before even going with a
proposal).


> 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...). The same
confirmation came for optional::value_or not being defaulted
(oversight). Also, what about exchange() then?


Thanks for your time and stay safe,

-- 
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts