cppwp | HTML version of the current C++ working paper | Document Editor library

This is covered in temp.deduct.type#11

These forms can be used in the same way as T is for further composition of types.

It might be clearer if you write your template with a different typename than T, e.g.

No.

[cpp.pre]/1:

A preprocessing directive consists of a sequence of preprocessing tokens that satisfies the following constraints: At the start of translation phase 4, the first token in the sequence, referred to as a directive-introducing token, begins with the first character in the source file (optionally after whitespace containing no new-line characters) or follows whitespace containing at least one new-line character, and is [...]

Preprocessing-directive-ness is determined at the start of translation phase 4, prior to any macro replacement. Therefore, I; is not recognized as a directive, and the import from the macro expansion of I is not replaced by the import-keyword token. This in turn means that it is not recognized as a module-import-declaration during translation phase 7, and is instead simply an ill-formed attempt to use the identifier import without a preceding declaration.

The point of this dance is to ensure that build systems can know a file's dependencies without having to fully preprocess the file - which would be required if imports can be formed from macro replacement.

This change was an inadvertent result of phrasing the rules more orthogonally, but since that orthogonality allows a few additional meaningful overload sets, there hasn’t been any hurry to “fix” it. In particular, it might work well with the proposal for deducing this that’s currently under consideration.

The behavior is undefined, regardless of whether or not the Base constructor accepts the parameter by reference.

When control reaches Base(variable = 50), the lifetime of variable hasn't started yet, because data members are initialized after base classes.

So first, writing to it causes UB because the lifetime hasn't started yet. Then, because you pass by value, reading from it is also UB.

[class.base.init]/13

In a non-delegating constructor, initialization proceeds in the following order:

— First, and only for the constructor of the most derived class ..., virtual base classes are initialized ...

— Then, direct base classes are initialized ...

— Then, non-static data members are initialized in the order they were declared in the class definition ...

— Finally, the ... the constructor body is executed.

Idea by @Jarod42: as an experiment, you can try this in a constexpr context, which is supposed to catch UB.

Short answer: You used different Clang versions in your examples, Clang 11 has a correct implementation, while Clang 10 does not.

In my answer I go into detail why Clang 11 and MSVC are right and GCC is wrong in both cases.

From [over.match.oper]#3 the candidates include four sets:

For [...] a binary operator @ [...] four sets of candidate functions, designated member candidates, non-member candidates, built-in candidates, and rewritten candidates, are constructed as follows:

In your case the rewritten candidates are determined by [over.match.oper]#3.4.4:

For the equality operators, the rewritten candidates also include a synthesized candidate, with the order of the two parameters reversed, for each non-rewritten candidate for the expression y == x.

In your case for an expression x == y the candidates of interest are:

• member candidates: candidates for x.operator==(y)
• non-member candidates: candidates for operator==(x, y)
• rewritten candidates: non-rewritten candidates for y == x, which are y.operator==(x) and operator==(y, x).

Let's look at your two examples and determine the best candidate.

For the expression a == y the candidates are:

By the plain wording of [except.ctor]/3, it applies to objects with any storage duration, as long as they are subobjects of an object whose construction was terminated by an exception. This should not be controversial.

However, the wording of [except.ctor] has changed over time, and this seems to have created some issues which the OP has noticed. The background is that the wording used to be simliar to the current wording, with "stack unwinding" only referring to the destruction of automatic objects, and someone noticed that this created an inconsistency, where, when no matching handler is found, it is not guaranteed whether stack unwinding occurs, but it is guaranteed that subobject destruction occurs (since there is nothing in the text to say that it may not happen if a handler is not found). This was CWG 1774. CWG agreed that this inconsistency was undesirable (and perhaps it was unintentional, though that page doesn't say). So the wording was changed so that subobject destruction would be an aspect of "stack unwinding", and thus covered under [except.handle]/9, instead of being a separate process. But then later, to resolve a different DR that has nothing to do with exceptions, the old wording was added back, and I'm 90% sure that it was unintentional. The intent of the resolution to CWG2256 was just to avoid discrimination against trivially destructible objects, and not to actually change anything about exception handling.

Therefore, the current wording is defective, and the standard should still be read as if "stack unwinding" includes subobject destruction (i.e., the resolution to CWG 1774 stands). You might even be able to fix this editorially (i.e., submit a pull request against the standard source).

Scoped enums always have fixed underlying type. [dcl.enum]/5 (C++17):

For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed.

So your E has fixed underlying type of int. Then in paragraph 8:

For an enumeration whose underlying type is fixed, the values of the enumeration are the values of the underlying type.

2 is in range for int, so by the text you quoted from [expr.static.cast], the behaviour of the cast is well-defined.

Both A ∧ B and A are already in disjunctive normal form and conjunctive normal form.

In this case, there is one disjunctive clause in P, and one conjunctive clause in Q.

You then check if any subclause of P0 (A ∧ B) subsumes any subclause of Q0 (A), which it does (A subsumes A).

Actually, the section [class.protected#1] is an additional clause for [class.access.base#5] when the nominated member is a protected member of the naming class to which R occurs at a member or friend of a derived class.
According to class.access.base#1, the non-static protected member of N is accessible as a private member of the derived class P. We are permitted to access the member m in a friend of P as per class.access.base#5.2, if the naming class is P

m as a member of N is private, and R occurs in a member or friend of class N, or

Back to [class.protected#1], we should take a look at the following rule:

An additional access check beyond those described earlier in Clause [class.access] is applied when a non-static data member or non-static member function is a protected member of its naming class ([class.access.base])115 As described earlier, access to a protected member is granted because the reference occurs in a friend or member of some class C.

In other words, the rule says that only if these conditions are satisfied will the additional rule be applied. That is:

1. The member should first be a non-static member(data or function)
2. The member should be a protected member of the naming class.

In order to make the additional rule apply, the following conditions should also be satisfied

1. As described earlier, access to a protected member is granted because the reference occurs in a friend or member of some class C.
2. If the access is to form a pointer to member ([expr.unary.op]), the nested-name-specifier shall denote C or a class derived from C.
3. All other accesses involve a (possibly implicit) object expression. In this case, the class of the object expression shall be C or a class derived from C.

Condition 3 might have some confusion, however, it does not say C must be the naming class or not. It just says that the member can be accessible in a member or friend of C.

After sorting out these conditions, we could take a look at the example