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
LWG Poll 16: P1976R2 Fixed-size span construction from dynamic range #3772
Conversation
e2af9b7
to
8abef76
Compare
source/containers.tex
Outdated
\remarks The second template argument of the returned \tcode{span} type is: | ||
\begin{codeblock} | ||
Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent | ||
\end{codeblock} |
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 feels awkward to me given that we have an actual mechanism in the language for "I don't want to write this messy return type here". Did you consider:
- Change the return type of
as_bytes
toauto
, - "Let
U
bespan<const byte, Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent>
.", and return U{/*...*/};
?
(Dittoas_writable_bytes
.)
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 did consider introducing a type (or the extent) with "Let" but for some reason I didn't consider using auto
. The form I used is what Tomasz (paper author) proposed in a pending-LWG issue.
I'll use your suggestion and push a new commit.
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.
After trying a few ways to say it, I think the clearest is to use auto
as the return type and say:
Effects: Equivalent to:
auto p = reinterpret_cast<const byte*>(s.data());
auto n = s.size_bytes();
if constexpr (Extent == dynamic_extent)
return span<const byte>{p, n};
else
return span<const byte, sizeof(ElementType) * Extent>{p, n};
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.
Works for 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.
I think we could factor out some more commonality with:
Let
E
bedynamic_extent
ifExtent == dynamic_extent
, andsizeof(ElementType) * Extent
otherwise.Effects: Equivalent to:
return span<const byte, E>{reinterpret_cast<const byte*>(s.data()), s.size_bytes()};
but this is much better in any case - feel free to ignore if you have better things to do than twaddle with this bit of wording over and over.
I used the wording to be consistient with [span.sub]p9. However, I do not have any preference for one or another. |
source/containers.tex
Outdated
@@ -11236,20 +11260,29 @@ | |||
\indexlibraryglobal{as_bytes}% | |||
\begin{itemdecl} | |||
template<class ElementType, size_t Extent> | |||
span<const byte, Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent> | |||
span<const byte, @\seebelow@> |
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.
These changes are missing in the synopsis.
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.
Not really, since the synopsis just spells out Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent
in full, which is exactly what the see below expands to.
I pushed a new commit that does it differently anyway.
8abef76
to
14c9f7e
Compare
Please address the Travis failures. You can run "../tools/check.sh" in a Unix-y environment to see the errors right there. |
I don't see any errors when I build the PDF and run the check.sh script locally. 🤷♂️ |
@jwakely: Did you check the return value? I think you're falling afoul of https://github.com/cplusplus/draft/blob/master/tools/check.sh#L35 (here: https://github.com/cplusplus/draft/pull/3772/files#diff-0fb8725b6f959c00f8cef02d54e8c125R10857), but the check doesn't emit a terribly useful diagnostic. |
14c9f7e
to
0780bb6
Compare
Thanks, should be fixed now. |
0780bb6
to
e2001f8
Compare
Whether a function has a deduced return type is an observable part of its semantics; I'm not convinced we can change that editorially. |
Also fixes NB PL 250 (C++20 CD).
e2001f8
to
44fe758
Compare
construction to compensate for changes in P1976R2.
6d1e205
to
8dc2366
Compare
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.
These changes to avoid the deduced return types look fine to me. Thanks!
Also fixes NB PL 250 (C++20 CD).
[span.sub] p3 and p6: Add explicit return types to account for
constructor being explicit now.
[span.objectrep] p1 and p3: Move extent of return type into a remark.
Add explicit return type to account for explicit constructor.
Fixes #3718
Fixes cplusplus/papers#707
Fixes cplusplus/nbballot#246