You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 18, 2024. It is now read-only.
After working on a patch to clang for P0332 (pull request with patch coming soon), the biggest issue I see with this proposal is that array incompleteness is no longer "local" (I don't have a better word for this, but it will become clear what I mean pretty soon). That is, you only have to look at the outermost extent to determine the completeness of an array type. Because of this, we can always say that an array type is:
complete, T[N], and we don't care about the extents of T (if any) as long as T is a complete type. Thus we only have to store information about [N] with the type and we can treat everything else recursively.
incomplete, T[], and we don't care about the extents of T (if any) as long as T is a complete type.
Note that in both cases, we only have to examine one "layer" of the completeness of T, and zero layers of the extents.
Now consider the state of affairs under P0332. Given a type T[N],
the type is complete if T is not an array type.
if T is an array type of the form U[M], we have to (recursively) examine the completeness of U.
if T is an array of the form U[], we know that T[N] is an incomplete type, but we still have to expand the definition of incomplete type to include N (in addition to the extents, if any, of U)
This would lead to some structural changes in the way array types are described in clang. It's not a deal-breaker by any means, but it's emblematic of why this is not a trivial change.
The text was updated successfully, but these errors were encountered:
We need a taxonomy of incomplete types. The standard talks about incomplete types in many ways: cvvoid, incomplete class, array of unknown bound, incomplete type that cannot be completed, incompletely-defined object type, array of incomplete class type, incomplete non-void type, incomplete object type, incompletely defined class, etc.
After working on a patch to clang for P0332 (pull request with patch coming soon), the biggest issue I see with this proposal is that array incompleteness is no longer "local" (I don't have a better word for this, but it will become clear what I mean pretty soon). That is, you only have to look at the outermost extent to determine the completeness of an array type. Because of this, we can always say that an array type is:
T[N]
, and we don't care about the extents ofT
(if any) as long asT
is a complete type. Thus we only have to store information about[N]
with the type and we can treat everything else recursively.T[]
, and we don't care about the extents ofT
(if any) as long asT
is a complete type.Note that in both cases, we only have to examine one "layer" of the completeness of
T
, and zero layers of the extents.Now consider the state of affairs under P0332. Given a type
T[N]
,T
is not an array type.T
is an array type of the formU[M]
, we have to (recursively) examine the completeness ofU
.T
is an array of the formU[]
, we know thatT[N]
is an incomplete type, but we still have to expand the definition of incomplete type to includeN
(in addition to the extents, if any, ofU
)This would lead to some structural changes in the way array types are described in clang. It's not a deal-breaker by any means, but it's emblematic of why this is not a trivial change.
The text was updated successfully, but these errors were encountered: