-
Notifications
You must be signed in to change notification settings - Fork 32
New issue: Multidimensional arrays are not supported by <tt>meta::ref… #530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
8fc9b6b
942f387
e1fd56a
84e10f5
a9358f8
e259f3b
27cfcfa
1507da3
031eb1f
75d9c65
b411229
ea949a8
7281717
23018b7
da2030a
55c6daa
65ccce4
cd8b3cf
e0c7eb1
0e2ef10
a07a46a
3deb1a6
014da74
c149fc6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,112 @@ | ||||||
| <?xml version='1.0' encoding='utf-8' standalone='no'?> | ||||||
| <!DOCTYPE issue SYSTEM "lwg-issue.dtd"> | ||||||
|
|
||||||
| <issue num="4483" status="New"> | ||||||
| <title>Multidimensional arrays are not supported by <tt>meta::reflect_constant_array</tt> and related functions</title> | ||||||
| <section> | ||||||
| <sref ref="[meta.define.static]"/> | ||||||
| </section> | ||||||
| <submitter>Tomasz Kamiński</submitter> | ||||||
| <date>27 Nov 2025</date> | ||||||
| <priority>99</priority> | ||||||
|
|
||||||
| <discussion> | ||||||
| <p>As any array type (even of structural types) is not considered an structural type, per | ||||||
| <sref ref="[temp.param]"/> p12, any invocation of `reflect_constant_array`/`define_static_array` | ||||||
| with multidimensional array or `span` of arrays is ill formed due <i>Mandate</i> in | ||||||
| <sref ref="meta.define.static"/> p8 that requires range value type to be structural.</p> | ||||||
|
|
||||||
| <p>As a consequence, `constant_of` currently supports only single-dimensional array | ||||||
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| (<tt>reflect_constant_arry</tt> strips outermost extents), while multi-dimensional array are | ||||||
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| rejected.</p> | ||||||
|
|
||||||
| <p>Furthermore, `define_static_object` currently uses <tt>define_static_array(span(addressof(t), 1)).data()</tt>, | ||||||
| for array types. As for `T[N]` input this creates an multidimensional `T[1][N]` constant parameter | ||||||
tomaszkam marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| object, this function does not support array at all. Furthermore creating an distinct template | ||||||
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| parameter object leads to emission of (otherwise unnecessary) additional symbols, and breaks the | ||||||
| invariant that for all supported object types <tt>&constant_of(o) == define_static_object(o)</tt>. | ||||||
| We should use `reflect_constant_array` for arrays directly.</p> | ||||||
|
|
||||||
| <p>The <i>Throws</i> clause of `reflect_constant_array` was updated to include any exception | ||||||
| thrown by iteration over range.</p> | ||||||
| </discussion> | ||||||
|
|
||||||
| <resolution> | ||||||
| <p> | ||||||
| This wording is relative to <paper num="N5014"/> ammended with changes from LWG <iref ref="4432"/>. | ||||||
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| </p> | ||||||
|
|
||||||
| <ol> | ||||||
|
|
||||||
| <li><p>Modify <sref ref="[meta.define.static]"/> as indicated:</p> | ||||||
|
|
||||||
| <pre> | ||||||
| template<ranges::input_range R> | ||||||
| consteval info reflect_constant_array(R&& r); | ||||||
| </pre> | ||||||
| <blockquote> | ||||||
| <p>-8- Let <tt><del>T</del><ins>U</ins></tt> be <tt>ranges::range_value_t<R></tt> | ||||||
| and <ins><tt>T</tt> be <tt>remove_all_extents_<U></tt></ins> | ||||||
| <del><i>e<sub>i</sub></i> be <tt>static_cast<T>(*<i>it<sub>i</sub></i>)</tt>, | ||||||
| where <i>it<sub>i</sub></i> is an iterator to the <i>i<sup>th</sup></i> element of `r`</del>. | ||||||
| </p> | ||||||
| <p>-9- <i>Mandates</i>: | ||||||
| <ul style="list-style-type: none"> | ||||||
| <li><ins>(9.1) —</ins> <tt>T</tt> is a structural type (<sref ref="[temp.param]"/>), | ||||||
| <del><tt>is_constructible_v<T, ranges::range_reference_t<R>></tt> is `true`, and</del> | ||||||
| </li> | ||||||
| <li><ins>(9.2) —</ins> <tt>T</tt> satisfies <tt>copy_constructible</tt><ins>, and</ins></li> | ||||||
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| <li><ins>(9.3) —</ins> <tt>U</tt> does not denote array type, then <tt>is_constructible_v<T, ranges::range_reference_t<R>></tt> is <tt>true</tt>.</li> | ||||||
|
||||||
| <li><ins>(9.3) —</ins> <tt>U</tt> does not denote array type, then <tt>is_constructible_v<T, ranges::range_reference_t<R>></tt> is <tt>true</tt>.</li> | |
| <li><ins>(9.3) — if <tt>U</tt> is not an array type, then <tt>is_constructible_v<T, ranges::range_reference_t<R>></tt> is <tt>true</tt>.</ins></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also replace dontes.
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Dani-Hub marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This "any of" construction followed by the item list sounds weird to me. I think about a better formulation. My current proposal would be to replace the item lists by individual sentences each one starting with "Any [...] of ", this seems to be existing practice elsewhere. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On reflector discussion Hubert requested "Any of" to emphasize unspecified nature of which one is selected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not criticizing the usage of "any of" (This is standard formaulation), but the concrete usage here where we use "any of" before as introducer before the bullet list and then expressing each bullet item as a seemingly continuation of this "any of". But a sentence such as "any of exception thrown by increment and dereference operations on iterator to r and comparison of such iterator to sentinel," doesn't sound like a real sentence to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My suggestion would be to replace the bullet list by individual sentences roughly as follows:
Any exception thrown by increment and dereference operations on iterator to r and comparison of such iterator to sentinel. Any exception thrown by the evaluation of any argument of reflect_constantei. meta::exception if evaluation of any reflect_constant(ei)evaluation of
reflect_constant or reflect_constant_array would exit via an exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tomaszkam We can keep the list style if we use the approach used in [string.insert] p10, that means without any introducer before the list and potentially using "Any exception ..." as begin of the first and second item. This has the effect that each bullet item is a full sentence.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated it in this manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
Uh oh!
There was an error while loading. Please reload this page.