CWG2102 [expr.new] Clarify if the constructor needs to be accessible for a class type when using new T[0]

[ranaanoop]

Full name of submitter (unless configured in github; will be published with the issue): Anoop Rana

Reference (section label): [expr.new]

Link to reflector thread (if any): https://stackoverflow.com/questions/76307898/new-a0-initialization-of-zero-size-array-with-dynamic-storage-duration-for-a

Issue description:

It is not clear if the following program is well-formed or ill-formed according to the current wording.

class A {
    A()=delete;    
};

int main()
{
     auto ptr = new A[0];  
}

We see implementation divergence here. As per [expr.new]:

When the value of the expression is zero, the allocation function is called to allocate an array with no elements.

One possible interpretation of the above clause is that since the array doesn't have any elements, there is no need for any initialization and hence no need for the constructor to be accessible or to exist at all. This should be clarified. The intention seems that there is no need for the ctor to exist or be accessible.

Suggested resolution:

It should be clarified that whether the above behaves as if there is no initialization and so no need for accessible ctor etc or the constructor needs to be accessible.

[languagelawyer]

It should be clarified that the above behaves as if there is no initialization and so no need for accessible ctor etc.

What if the value of the expression is zero, but it is known only in «runtime»

[ranaanoop]

@languagelawyer Good point, so it seems the easiest(simplest) is to add a sentence below the above quoted reference [expr.new] saying that even if the expression comes to be 0, the ctor still needs to be accessible(in case T is a class type).

[languagelawyer]

As it was noticed on SO, CWG2102?

[frederick-vs-ja]

Ah, CWG2102 seems to be resolved editorially (EDIT2608). @jensmaurer

[jensmaurer]

Right, that editorial issue helps CWG2102 a bit, but not all questions asked in CWG2102 are addressed by that editorial fix.

[jensmaurer]

I've amended CWG2102 with the question about T[0], and I've added a proposed resolution there.

[frederick-vs-ja]

The currently proposed resolution hasn't addressed new A[0]() or new A[0]{} yet.

And there is also implementation divergence now (Godbolt link):

	new A[0]	new A[0]()	new A[0]{}
GCC	√	√	√
Clang	×	×	√
MSVC	×	×	×

[jensmaurer]

The currently proposed resolution hasn't addressed new A0 or new A[0]{} yet.

Agreed. But that should be handled by the regular initializer interpretation, not by anything special in expr.new, I think. Anyway, I'm wondering whether T[0] (constant 0) should have rules different from T[i] where i has runtime value 0.

[frederick-vs-ja]

Anyway, I'm wondering whether T[0] (constant 0) should have rules different from T[i] where i has runtime value 0.

If we want to differentiate between T[0] and T[runtime_zero], we need to constant-evaluate expr in decltype(new T[expr]) to determine whether expr is a constant expression of value 0. However, the decision made in CWG2392 seemingly implied that expr in new T[expr] shouldn't be potentially constant evaluated.

But that should be handled by the regular initializer interpretation, not by anything special in expr.new, I think.

Hmm... it seems that [expr.new] p23.1 is already applying the rules for default-initialization to the cases without new-initializer.

The related rules in regular initializer interpretation are:

If T is an array type, each element is default-initialized. ([dcl.init.general] p7.2, for new T[n])

if T is an array type, then each element is value-initialized; ([dcl.init.general] p9.2, for new T[n]())

Otherwise, if the element is not a reference, the element is copy-initialized from an empty initializer list ([dcl.init.list]). ([dcl.init.aggr] p5.2, for new T[n]{})

When n is 0, there is no such an element, and T[0] is not a valid type. So it's also questionable whether these rules can be natually applied.

Perhaps we should say "whatever n (the expression) is, for the purpose of checking semantic constraints, there is always a hypothetical element added to the array" (but we need to do this after checking whether n is erroneous).

[jensmaurer]

Fixed: CWG2102

[lprv]

I feel like the specific case of T[0] is a red herring. The real problem here is that neither the current text of the standard nor the proposed resolution to this issue clearly explain how new T[runtime_value] {1, 2} requires T to be default-constructible, and whether the same applies to new T[2] {1, 2} and why. Once that's properly specified, zero-sized arrays shouldn't require any special treatment, the rules for the general case would handle those just fine.

---

the decision made in CWG2392 seemingly implied that expr in new T[expr] shouldn't be potentially constant evaluated

The issue page gives the following rationale for the decision:

A similar situation arises for narrowing conversions, except that in the latter case, determining the value at compile-time empowers to allow additional cases, whereas the new-expression case uses a compile-time value to prohibit additional cases.

Constant-evaluating expr could in fact 'allow additional cases' (new arrays of non-default-constructible elements), so this motivation seems obsolete.

All major implementations already accept this:

struct T {
  // No default ctor.
  T(int);
};

T* p = new T[2] {1, 2};

[RealLitb]

How is this different from w.r.t. checking of access?

for(int i = 0; i < 0; i++) new Class;

The '0' in your new-expression is not even in a place that is constrained syntactically to a constant-expression (it's a new-type-id.. and if your were to parenthesize it, it would be ill-formed with 0 because it would become a declarator), making it match my for-loop really nicely. Access-checking is done independently of whether an object actually is created at runtime - it suffices if it appears in the CFG, I think. Think about

void f(X = X()); // access check happens here, even if f is not called.

[RealLitb]

We have the rule:

Access control is applied uniformly to declarations and expressions.

That means, access control does not apply to evaluations of expressions, but to expressions (statically). A note may be sufficient somewhere in expr.new:

[Note: Access checking on the (implicit) call-expression to constructors, destructors and allocation functions will happen regardless of whether these are actually evaluated, even in the case of creation or destruction of an array without elements. -- end Note]

[jensmaurer]

@RealLitb, is your comment in any way directed at the current proposed resolution of CWG2102, or just at the discussion in this ticket?