Date: Thu, 29 Oct 2020 10:11:10 -0400
On Thu, Oct 29, 2020 at 9:51 AM Barry Revzin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> 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.
The point of a Tony Table is to contrast how you did things before vs.
how you do things now. The contrast should demonstrate visually that
the feature in question provides a meaningful improvement in code
quality and clarity over the ways one had to do it before.
Which I would say is kind of the problem in using a Tony Table here at
all because to me, the feature doesn't actually improve code quality
or clarity. The use of a naked braced-init-list in a generic function
call like that does not immediately trigger in my mind the purpose of
that list or what it means. Being forced to use the typename *does*
make it clear exactly what is going on and why.
I'm not saying that all such uses are inscrutable. But when you're
looking at a generic function call whose other arguments are
themselves computed through complex interactions of `auto`-deduced
variables and expressions, it's fairly easy for the meaning of that
braced-init-list to not be apparent.
And I'd rather err on the side of "make it explicit" than to trust
programmers to not obfuscate the meaning of generic calls of this
type.
<std-proposals_at_[hidden]> wrote:
>
>
>
> 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.
The point of a Tony Table is to contrast how you did things before vs.
how you do things now. The contrast should demonstrate visually that
the feature in question provides a meaningful improvement in code
quality and clarity over the ways one had to do it before.
Which I would say is kind of the problem in using a Tony Table here at
all because to me, the feature doesn't actually improve code quality
or clarity. The use of a naked braced-init-list in a generic function
call like that does not immediately trigger in my mind the purpose of
that list or what it means. Being forced to use the typename *does*
make it clear exactly what is going on and why.
I'm not saying that all such uses are inscrutable. But when you're
looking at a generic function call whose other arguments are
themselves computed through complex interactions of `auto`-deduced
variables and expressions, it's fairly easy for the meaning of that
braced-init-list to not be apparent.
And I'd rather err on the side of "make it explicit" than to trust
programmers to not obfuscate the meaning of generic calls of this
type.
Received on 2020-10-29 09:11:24