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

Add const_iterable_sequence concept #154

Merged
merged 5 commits into from
Jan 22, 2024
Merged

Conversation

tcbrindle
Copy link
Owner

For a sequence S, const_iterable_sequence<S> means we can use S const as a sequence with the expected semantics.

Specifically, we require that:

  • S const is a sequence
  • S and S const have the same cursor type and the same value type
  • S and S const have the same const_element_type
  • For every extended sequence concept (multipass, bidirectional etc), excluding read_only_sequence, both S and S const must satisfy the concept or both must not satisfy the concept. For example, if S is bidirectional then S const must be bidirectional and vice versa
  • If S models read_only_sequence then S const must model read_only_sequence -- that is, S const may strengthen the const-qualification of elements but not weaken it
  • Semantic requirement: iterating over S const yields "the same elements" as iterating over S (but let's gloss over exactly how we define "same"...)

We've previously assumed all of these things are true (except possibly the const_element_t requirement), but it's good to have them checked by the compiler where we can.

For a sequence S, `const_iterable_sequence<S>` means we can use `S const` as a sequence with the expected semantics.

Specifically, we require that:

 * `S const` is a sequence
 * `S` and `S const` have the same cursor type and the same value type
 * `S` and `S const` have the same `const_element_type`
 * For every extended sequence concept (`multipass`, `bidirectional` etc), excluding `read_only_sequence`, both `S` and `S const` must satisfy the concept or both must not satisfy the concept; for example, if `S` is bidirectional then `S const` must be bidirectional and vice versa
 * If `S` models `read_only_sequence` then `S const` must model `read_only_sequence` -- that is, `S const` may strengthen the const-qualification of elements but not weaken it
 * Semantic requirement: iterating over `S const` yields "the same elements" as iterating over `S` (but let's gloss over exactly how we define "same"...)

We've previously assumed all of these things are true (except possibly the `const_element_t` requirement), but it's good to have them checked by the type system where we can.
Apparently when using C++23 various headers have been moved around so we no longer get things automatically included.
As in several other places, std::tuple and std::pair need the C++23 `common_reference` changes so that we can do correct concept checking.
Copy link

codecov bot commented Jan 21, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b54eb3f) 97.99% compared to head (b9fb820) 97.99%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #154   +/-   ##
=======================================
  Coverage   97.99%   97.99%           
=======================================
  Files          66       66           
  Lines        2392     2392           
=======================================
  Hits         2344     2344           
  Misses         48       48           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tcbrindle tcbrindle merged commit 44bd131 into main Jan 22, 2024
25 checks passed
@tcbrindle tcbrindle deleted the pr/const_iterable_sequence branch January 30, 2024 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant