On 3/21/21 10:16 AM, Jason McKesson wrote:
> On Sun, Mar 21, 2021 at 1:08 AM Phil Bouchard <boost_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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.

-- 
*Phil Bouchard*
Founder
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>