Date: Thu, 29 Oct 2020 15:56:50 +0100
Hi,
Il 29/10/20 15:11, Jason McKesson via Std-Proposals ha scritto:
>> 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.
I've amended it now, hoping to make it more clear.
> 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.
Then you can make it explicit, I'm certainly not removing that
possibility. This sounds a lot like deducing the type of variables via
`auto` doesn't remove the possibility of just spelling out the type.
Given that there are legitimate use cases for initializer lists, why
forbidding them in some contexts and allowing them in others, based on a
totally "arbitrary" choice (*)?
(*) in the sense that they work for e.g. push_back(), but that wasn't a
design decision of push_back(), and don't work for erase(), and that
wasn't a design decision of erase() either!
Thank you,
Il 29/10/20 15:11, Jason McKesson via Std-Proposals ha scritto:
>> 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.
I've amended it now, hoping to make it more clear.
> 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.
Then you can make it explicit, I'm certainly not removing that
possibility. This sounds a lot like deducing the type of variables via
`auto` doesn't remove the possibility of just spelling out the type.
Given that there are legitimate use cases for initializer lists, why
forbidding them in some contexts and allowing them in others, based on a
totally "arbitrary" choice (*)?
(*) in the sense that they work for e.g. push_back(), but that wasn't a
design decision of push_back(), and don't work for erase(), and that
wasn't a design decision of erase() either!
Thank you,
-- 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
Received on 2020-10-29 09:56:57