Usage of special member functions

[miscco]

Generally it is considered best practise to not declare special member functions needlessly but rather default them, e.g. the trivial default constructor

struct foo {
   foo() {}
};

would be better declared

struct foo {
   foo() = default;
};

The same applies for the other special member functions, Greg Falcon even mentions it in his talk at CppCon2018 [https://www.youtube.com/watch?v=6ZOygaUjzjQ]. Nevertheless these special member functions are present everywhere in abseil, e.g.

abseil-cpp/absl/container/internal/common.h

Line 58 in cd86d0d

constexpr node_handle_base() {}

Is there a reason for that or is that just on the bottom of the list?

[asoffer]

With = default, the constructor will not be constexpr.

[miscco]

According to cppreference this is not the case since C++11. In fact, the current C++ standard draft reads in Chapter 15.1 [class.ctor] §7:

A default constructor that is defaulted and not defined as deleted is implicitly defined when it is odr-used to create an object of its class type or when it is explicitly defaulted after its first declaration.
The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with no ctor-initializer and an empty compound-statement.
If that user-written default constructor would be ill-formed,the program is ill-formed.
If that user-written default constructor would satisfy the requirements of a constexpr constructor the implicitly-defined default constructor is constexpr.
Before the defaulted default constructor for a class is implicitly defined, all the non-user-provided default constructors for its base classes and its non-static data members shall have been implicitly defined.

Similarly a implicitely defined default constructor also inherits the exception specification that follow from the class-members

[zhangxy988]

Note that the proposed change does change traits behavior, e.g. https://gcc.godbolt.org/z/ek-8XZ.
I am not sure why the constructors were written in the form constexpr T() {} instead of T() = default. For that we need to check with the original author.
Do you have a specific concern on this other than "it looks better"?

[miscco]

Yes the implicitely defaulted constructor indeed may change the type traits of the class. However please note that they are strictly more correct.

In you example there is no reason why Bar should not be trivially constructible. Even worse the fourth assert is an actual bug. Bar<NoDefaultCtor> should not be marked as default constructible

[brenoguim]

Having correct traits behavior is kind of important. Several containers optimize based on traits. Not sure its relevant in this case, but in general it's kind of important.

[miscco]

THere was a internal discussion and the corresponding PRs were closed. Insofar this issue should be closed too