Hi Guiseppe,

I would need to look it up, but I think, today iterator_traits are no longer required to be specialized for iterators. so you might need something like
decltype(*declval<Iterator>())
for the default (modulo const qualification and references) instead of the trait. But I a, sure Arthur (thanks to him btw) knows better.

It is nice to see others are also taking up "janitorial" work of cleaning up the standard.

regards
Peter

Sent from Peter Sommerlad's iPad
+41 79 432 23 32

> On 29 Oct 2020, at 03:18, Giuseppe D'Angelo via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> 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]> 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