On Tue, Oct 27, 2020 at 2:34 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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/
>
>
Looks great to me.


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

That's absolutely a Tony Table. He's showing something that you might think
would work but doesn't... and now works and does the expecting thing. Sure,
he could also show the workaround you have to write today, but not having
that does not make this not a Tony Table.

On that note, the paper proposes a feature-test macro. What's the
motivation for a feature-test macro? Like, I'm not going to write:
#ifdef __cpp_cool_new_thing
fill(v, point{3, 4});
#else
fill(v, {3, 4});
#endif

If I have to support both compiler versions, I would just write the first
thing. Is there a reason to need the macro here?

Barry