Title
Type dependence of function-style cast to incomplete array type
Status
drafting
Section
13.8.3.3 [temp.dep.expr]
Submitter
Richard Smith

Created on 2021-03-12.00:00:00 last changed 1 week ago

Messages

Date: 2021-08-15.00:00:00

Notes from the August, 2021 teleconference:

CWG agreed with the suggested change. There was some support for the “more precise” approach mentioned in the description.

Date: 2021-03-12.00:00:00

Consider:

  using T = int[];
  using U = int[2];
  template<auto M, int ...N> void f() {
    auto &&arr1 = T(N...);
    auto &&arr2 = T{N...};
    auto &&arr3 = U(M, M);
    auto &&arr4 = U{M, M};
  };

I think here T(N...) is not type-dependent, per 13.8.3.3 [temp.dep.expr] paragraph 3, but should be. (I think T{N...} is type-dependent.) Conversely, I think U{M, M} is type-dependent, per 13.8.3.3 [temp.dep.expr] paragraph 6, but should not be. (U(M, M) is not type-dependent.)

I think we should say that

    simple-type-specifier ( expression-listopt )
    typename-specifier ( expression-listopt )
    simple-type-specifier braced-init-list
    typename-specifier braced-init-list

are type-dependent if the type specifier names a dependent type, or if it names an array of unknown bound and the braced-init-list or expression-list is type-dependent.

(I think we could be a little more precise than that in the case where there is no top-level pack expansion: T{M, M} needs to be type-dependent for a general array of unknown bound T due to brace elision, but not in the case where the array element type is a scalar type. And T(M, M) does not need to be type-dependent because direct aggregate initialization can't perform brace elision. But I think the simpler rule is probably good enough.)

History
Date User Action Args
2021-11-15 00:00:00adminsetmessages: + msg6544
2021-03-12 00:00:00admincreate