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 default_sequence_traits #207

Merged
merged 10 commits into from
Aug 21, 2024
Merged

Add default_sequence_traits #207

merged 10 commits into from
Aug 21, 2024

Conversation

tcbrindle
Copy link
Owner

The sequence concept has several optional customisation points, for example read_at_unchecked() and for_each_while(), for which we can provide a reasonable default if the sequence implementation does not.

Previously this was handled by the wrapper functions (flux::read_at_unchecked etc) examining the sequence_traits<T> struct and using the customised function if it existed, otherwise falling back to their default implementation.

This PR changes the arrangement somewhat. Rather than being strictly optional, the sequence concept now requires that all customisation points are implemented. We can still provide default implementations, but this is now handled by having sequence_traits<T> inherit from a new base class default_sequence_traits. (In principle using this base class is not required by the sequence concept, but in practise everyone will want to use it.)

This has the advantage that user-defined customisations can now be concept-checked; that is, if a user provides an incompatible signature for e.g. for_each_while in their sequence_traits, it will hide the default implementation, and result in a compile error; previously, the incompatible signature would just have been ignored and the default impl would silently have been used.

For complicated sequence implementations (e.g. the zip and cartesian_product families), this means that we also need to be explicit about when we're using the default impls vs using customised versions. This is a good thing.

Add flux::default_sequence_traits, a base class containing sensible default implementations of (at the moment) read_at_unchecked, move_at and move_at_unchecked.

Also, change the sequence concept definition to require that these customisation points are implemented (or in practise, that sequence_traits<T> inherits from default_sequence_traits)
We now always use the version that the sequence impl provides
Copy link

codecov bot commented Aug 20, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.30%. Comparing base (bbdd46f) to head (4bb55a8).
Report is 11 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #207   +/-   ##
=======================================
  Coverage   98.30%   98.30%           
=======================================
  Files          70       71    +1     
  Lines        2479     2485    +6     
=======================================
+ Hits         2437     2443    +6     
  Misses         42       42           

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

MSVC is complaining that `using default_sequence_traits::for_each_while` in `drop_adaptor::sequence_traits` references an unknown base class, which doesn't make a lot of sense as it very definitely does inherit from it... but never mind, we'll work around it anyway
Strangely, GCC and Clang didn't complain about this, and neither did MSVC when building locally -- only in CI. But it definitely looks wrong.
@tcbrindle tcbrindle merged commit 6e4b9dd into main Aug 21, 2024
41 checks passed
@tcbrindle tcbrindle deleted the pr/default_sequence_traits branch November 5, 2024 18:59
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.

1 participant