On 3/20/21 11:43 AM, Jason McKesson via Std-Proposals wrote:
> On Sat, Mar 20, 2021 at 12:53 AM Phil Bouchard via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>> Why is that disallowed when you can simply workaround the problem?
> That's not a good enough reason to add any feature to the language.
>
> I don't know if you're talking about allowing `auto`-deduction of
> members of a class or CTAD-based deduction of members of a class. But
> the reason not to do it is the same regardless.

Yes I was implying that.

> Namely: that initializer does not *have to be* used to initialize that
> member. With normal `auto` or CTAD deduction, you're talking about an
> object which is definitely going to be initialized by a given
> initializer. But in your example, you don't know what's going to
> initialize the member. Yes, `A::l` has a default member initializer,
> but this is only the *default* initializer. Since `A` is an aggregate,
> it can be overridden as easily as: `A{{5.4f, 8.4f}};`
>
> Should that mean that `A::l` is a `list<float>` in this case? Some
> might assume that it should be. *Especially* since `auto` now is more
> easily used to create template functions, some might think that you
> can use `auto` or similar mechanisms to create template *classes*
> without an explicit template header.
>
> 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...

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