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:

struct A

{

    auto member1;

    auto member2;

    A(auto arg1, auto arg2) : member1(arg1), member2(arg2) {}

};

Would be equivalent to:

template <typename Arg1, typename Arg2>

struct A

{

    Arg1 member1;

    Arg2 member2;

    A(Arg1 arg1, Arg2 arg2) : member1(arg1), member2(arg2) {}

};

So that:

A a(1, 2.2);

Would generate:

A<int, float> a(1, 2.2);

Thus I would count the number of non-static data members inside the class and map their types based on the [implicit / explicit] constructor's arguments. That feature could be quite powerful IMO.

--

Phil Bouchard
Founder
C.: (819) 328-4743