On Sun, Mar 21, 2021 at 1:08 AM Phil Bouchard <firstname.lastname@example.org> 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 <email@example.com> wrote: On 3/20/21 12:13 PM, Ville Voutilainen wrote: On Sat, 20 Mar 2021 at 17:54, Phil Bouchard via Std-Proposals <firstname.lastname@example.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 gone. 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.