On 3/21/21 10:16 AM, Jason McKesson wrote:
On Sun, Mar 21, 2021 at 1:08 AM Phil Bouchard <boost@fornux.com> wrote:

On 3/20/21 5:19 PM, Jason McKesson via Std-Proposals wrote:

On Sat, Mar 20, 2021 at 12:26 PM Phil Bouchard via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

On 3/20/21 12:13 PM, Ville Voutilainen wrote:

On Sat, 20 Mar 2021 at 17:54, Phil Bouchard via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

And that's why deduction probably shouldn't happen with class members
like that. It's not a matter of whether it's possible to specify in
the standard; it's a matter of whether it's a good idea to permit it.

And there are good arguments why it shouldn't be.

So it's better to be stricter than stuck down the road with an allowance you can't revert...

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3897.html

But my take is we should enable it for clarity because decltype(...) is quite ugly.

Did you read the paper and take note of all of the other reasons why
it's not a good idea? Like for example the fact that not only is
`decltype(...)` ugly, it's actually *semantically different* from the
expression "..." when used as a default member initializer.

Nobody's *forcing* anybody to use `decltype`. Not unless the
initialization expression is exceedingly complicated, and the one in
your example is decidedly not that. Avoiding typing `<int>` is not a
good reason to do this.

I'm not saying that there aren't places where using `auto` wouldn't be
justifiable. But you don't seem to be considering all of the other
problems that the feature creates.

According to the discussion, that feature could simply be limited as to not referring to the incomplete encompassing type, etc.

I would even go as far as mimicking Python here:
No, that's ridiculous. For a quick function definition, it can be more
reasonable to use `auto` parameters instead of an explicit template
header. The `auto` parameters are right there in the function
signature, a mere one line lower than the template header would have

By contrast, class members are *arbitrarily* far from where the
template header would go. How many template parameters a template
class has could only be determined by reading the *entire* class. I'm
not sure that's even parseable. But I am sure that it makes the class
a lot less usable and comprehensible for a human being.

What is the second template parameter of `A`? You don't know; you'd
have to read the *entire definition* of the class to find out. Whereas
if you have an explicit template header, you have the opportunity to
give the template parameter a name. And a good descriptive name tells
you what that parameter is, thus making the class easier to use.

Template headers are not a problem that the language should solve;
they are a very useful tool for understanding templates. There's
nothing "powerful" about ways to avoid writing them; there's nothing
you could do without them that you couldn't do with them.

Yeah I agree it would create a mess in maintenance of the code, and not an example to follow from Python actually.


Phil Bouchard
C.: (819) 328-4743

Fornux Logo