Ttdfjt

I'm migrating a C++ Visual Studio Project from VS2017 to VS2019.

I'm getting an error now, that didn't occur before, that can be reproduced with these few lines of code:

struct Foo

 Foo() = default;
 int bar;
;
auto test = Foo 0 ;

The error is

(6): error C2440: 'initializing': cannot convert from
'initializer list' to 'Foo'

(6): note: No constructor could take the source type, or
constructor overload resolution was ambiguous

The project is compiled with /std:c++latest flag. I reproduced it on godbolt. If I switch it to /std:c++17, it compiles fine as before.

I tried to compile the same code with clang with -std=c++2a and got a similar error. Also, defaulting or deleting other constructors generates this error.

Apparently, some new C++20 features were added in VS2019 and I'm assuming the origin of this issue is described in https://en.cppreference.com/w/cpp/language/aggregate_initialization.
There it says that an aggregate can be a struct that (among other criteria) has

• no user-provided, inherited, or explicit constructors (explicitly defaulted or deleted constructors are allowed) (since C++17) (until C++20)


• no user-declared or inherited constructors (since C++20)

Note that the part in parentheses "explicitly defaulted or deleted constructors are allowed" was dropped and that "user-provided" changed to "user-declared".

So my first question is, am I right assuming that this change in the standard is the reason why my code compiled before but does not anymore?

Of course, it's easy to fix this: Just remove the explicitly defaulted constructors.

However, I have explicitly defaulted and deleted very many constructors in all of my projects because I found it was a good habit to make code much more expressive this way because it simply results in fewer surprises than with implicitly defaulted or deleted constructors. With this change however, this doesn't seem like such a good habit anymore...

So my actual question is:
What is the reasoning behind this change from C++17 to C++20? Was this break of backwards compatibility made on purpose? Was there some trade off like "Ok, we're breaking backwards compatibility here, but it's for the greater good."? What is this greater good?

The abstract from P1008, the proposal that led to the change:

C++ currently allows some types with user-declared constructors to be initialized via aggregate initialization, bypassing those constructors. The result is code that is surprising, confusing, and buggy. This paper proposes a fix that makes initialization semantics in C++ safer, more uniform,and easier to teach. We also discuss the breaking changes that this fix introduces.

One of the examples they give is the following.

struct X 
 int i4;
 X() = default;
;

int main() 
 X x1(3); // ill-formed - no matching c’tor
 X x23; // compiles!

To me, it's quite clear that the proposed changes are worth the backwards-incompatibility they bear. And indeed, it doesn't seem to be good practice anymore to = default aggregate default constructors.

The reasoning from P1008 (PDF) can be best understood from two directions:

1. If you sat a relatively new C++ programmer down in front of a class definition and ask "is this an aggregate", would they be correct?

The common conception of an aggregate is "a class with no constructors". If Typename() = default; is in a class definition, most people will see that as having a constructor. It will behave like the standard default constructor, but the type still has one. That is the broad conception of the idea from many users.

An aggregate is supposed to be a class of pure data, able to have any member assume any value it is given. From that perspective, you have no business giving it constructors of any kind, even if you defaulted them. Which brings us to the next reasoning:

2. If my class fulfills the requirements of an aggregate, but I don't want it to be an aggregate, how do I do that?

The most obvious answer would be to = default the default constructor, because I'm probably someone from group #1. Obviously, that doesn't work.

Pre-C++20, your options are to give the class some other constructor or to implement one of the special member functions. Neither of these options are palatable, because (by definition) it's not something you actually need to implement; you're just doing it to make some side effect happen.

Post-C++20, the obvious answer works.

By changing the rules in such a way, it makes the difference between an aggregate and non-aggregate visible. Aggregates have no constructors; so if you want a type to be an aggregate, you don't give it constructors.

Oh, and here's a fun fact: pre-C++20, this is an aggregate:

class Agg

 Agg() = default;
;

Note that the defaulted constructor is private, so only people with private access to Agg can call it... unless they use Agg, bypasses the constructor and is perfectly legal.

The clear intent of this class is to create a class which can be copied around, but can only get its initial construction from those with private access. This allows forwarding of access controls, as only code which was given an Agg can call functions that take Agg as a parameter. And only code with access to Agg can create one.

Or at least, that's how it is supposed to be.

Now you could fix this more targetedly by saying that it's an aggregate if the defaulted/deleted constructors are not publicly declared. But that feels even more in-congruent; sometimes, a class with a visibly declared constructor is an aggregate and sometimes it isn't, depending on where that visibly declared constructor is.

Actually, MSDN addressed your concern in the below document:

Modified specification of aggregate type

In Visual Studio 2019, under /std:c++latest, a class with any user-declared constructor (for example, including a constructor declared = default or = delete) isn't an aggregate. Previously, only user-provided constructors would disqualify a class from being an aggregate. This change puts additional restrictions on how such types can be initialized.