Skip to content
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

Merged
merged 2 commits into from Mar 3, 2020

Conversation

jwakely
Copy link
Member

@jwakely jwakely commented Feb 20, 2020

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

@jensmaurer jensmaurer added this to the post-2020-02 milestone Feb 20, 2020
\remarks The second template argument of the returned \tcode{span} type is:
\begin{codeblock}
Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent
\end{codeblock}
Copy link
Contributor

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 to auto,
  • "Let U be span<const byte, Extent == dynamic_extent ? dynamic_extent : sizeof(ElementType) * Extent>.", and
  • return U{/*...*/};?
    (Ditto as_writable_bytes.)

Copy link
Member Author

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.

Copy link
Member Author

@jwakely jwakely Feb 20, 2020

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};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.

Copy link
Contributor

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 be dynamic_extent if Extent == dynamic_extent, and sizeof(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.

@tomaszkam
Copy link

I used the wording to be consistient with [span.sub]p9. However, I do not have any preference for one or another.

@@ -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@>
Copy link
Contributor

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.

Copy link
Member Author

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.

@jensmaurer
Copy link
Member

Please address the Travis failures. You can run "../tools/check.sh" in a Unix-y environment to see the errors right there.

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Feb 21, 2020
@jensmaurer jensmaurer changed the title P1976R2 Fixed-size span construction from dynamic range LWG Poll 16. P1976R2 Fixed-size span construction from dynamic range Feb 21, 2020
@jensmaurer jensmaurer changed the title LWG Poll 16. P1976R2 Fixed-size span construction from dynamic range LWG Poll 16: P1976R2 Fixed-size span construction from dynamic range Feb 21, 2020
@jwakely
Copy link
Member Author

jwakely commented Feb 21, 2020

I don't see any errors when I build the PDF and run the check.sh script locally. 🤷‍♂️

@tkoeppe
Copy link
Contributor

tkoeppe commented Feb 21, 2020

@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.

@jensmaurer
Copy link
Member

@jwakely , @tkoeppe is right. \expects and friends should be alone on a line.

@jwakely
Copy link
Member Author

jwakely commented Feb 21, 2020

Thanks, should be fixed now.

@zygoloid
Copy link
Member

zygoloid commented Mar 3, 2020

Whether a function has a deduced return type is an observable part of its semantics; I'm not convinced we can change that editorially.

construction to compensate for changes in P1976R2.
Copy link
Member Author

@jwakely jwakely left a 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!

@zygoloid zygoloid merged commit 11aa675 into master Mar 3, 2020
@zygoloid zygoloid removed the changes requested Changes to the wording or approach have been requested and not yet applied. label Mar 3, 2020
@jensmaurer jensmaurer deleted the motions-2020-02-lwg-16 branch February 12, 2021 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants