-
Notifications
You must be signed in to change notification settings - Fork 82
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
[API] The alignment configuration for the band changed to seqan3::align_cfg::band_fixed_size #1873
[API] The alignment configuration for the band changed to seqan3::align_cfg::band_fixed_size #1873
Conversation
I assigned myself, because I'm was also requested to review PR #1876. |
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.
Only small things! Despite the high number of changes the diff look pretty good :)
requires output_stream_over<stream_t, underlying_type_t const &> && | ||
((skills & strong_type_skill::stream) != strong_type_skill::none) | ||
//!\endcond | ||
stream_t & operator<<(stream_t & stream, strong_type<underlying_type_t, derived_t, skills> const & value) |
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.
Why did you not overload debugstream
?
I'm not a huge fan of overloading every possible stream operator.
I would prefer a specific overload for debugstream
.
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 found it weird if we say the skill allows streaming the type but then only restrict it to the debug stream. I am also in slight preference for making the strong type a public type at some point.
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.
The question is why strong types are not always printable if the underlying type is printable?
Please just overload debug_stream 🥺
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.
That is exactly the design of the strong types. They are not supposed to automatically inherit the behavior of the underlying type but it needs to be selected individually. If you want the type to inherit all its features just use a type alias.
It would be ok, I guess as, long as the strong type is detail to make it only debug streambale. It would not be ok if it is public. Something we should consider for the future if we are beginning to use strong types in more public interfaces. Since then the user knows what can be done with the interface. I will make it now explicit, but that should become a generic stream overload if it goes public.
@marehr when you are done I'll rebase onto master to get rid of the changelog conflict. |
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.
🥺
requires output_stream_over<stream_t, underlying_type_t const &> && | ||
((skills & strong_type_skill::stream) != strong_type_skill::none) | ||
//!\endcond | ||
stream_t & operator<<(stream_t & stream, strong_type<underlying_type_t, derived_t, skills> const & value) |
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.
The question is why strong types are not always printable if the underlying type is printable?
Please just overload debug_stream 🥺
b14e78b
to
2595eaf
Compare
Codecov Report
@@ Coverage Diff @@
## master #1873 +/- ##
=======================================
Coverage 97.67% 97.67%
=======================================
Files 253 254 +1
Lines 9552 9565 +13
=======================================
+ Hits 9330 9343 +13
Misses 222 222
Continue to review full report at Codecov.
|
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 completely sure how to proceed.
Technically, this PR should come after #1871, but it will work any way even after that PR.
My only open issue would be renaming type_skills
-> skills_
.
requires std::same_as<band_t, static_band> | ||
//!\endcond | ||
struct band : public pipeable_config_element<band<band_t>, band_t> | ||
class band_fixed_size : public pipeable_config_element<band_fixed_size, seqan3::detail::empty_type> |
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.
class band_fixed_size : public pipeable_config_element<band_fixed_size, seqan3::detail::empty_type> | |
class band_fixed_size : public pipeable_config_element<band_fixed_size, seqan3::detail::empty_type> |
Is this blocked by #1871?
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.
No, both could be valid. But need to be updated anyway. Since #1871 is in second review already i will update this afterwards.
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.
#1871 is merged :D
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 know
*/ | ||
{ std::remove_reference_t<strong_type_t>::skills }; | ||
//!\cond | ||
requires std::same_as<decltype(std::remove_reference_t<strong_type_t>::skills), strong_type_skill const>; |
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 will mess up #1866 again 😿 But such is live 🤷
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.
whatever comes first :)
@@ -112,11 +166,12 @@ namespace seqan3::detail | |||
* | |||
* \include test/snippet/core/detail/strong_type_adding_skills.cpp | |||
*/ | |||
template <typename value_t, typename derived_t, strong_type_skill skills = strong_type_skill::none> | |||
template <typename value_t, typename derived_t, strong_type_skill type_skills = strong_type_skill::none> |
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.
template <typename value_t, typename derived_t, strong_type_skill type_skills = strong_type_skill::none> | |
template <typename value_t, typename derived_t, strong_type_skill skills_ = strong_type_skill::none> |
After our new resolution 🦆 and 🏃
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.
😢 Why did I agree on this? So ugly.
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.
Hm I have the feeling this might be resolved in another commit but then again your commit history is clean?
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 history is always clean 🙆♂️ :)
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.
So you are just refusing the renaming? :D
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.
No, but I usually sleep during the night and obviously do not update the changes then. ;)
SEQAN3_CONCEPT strong_type_specialisation = requires (strong_type_t && obj) | ||
{ | ||
//!\endcond | ||
|
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.
Stupid question, but wouldn't something like this suffice?
template <typename strong_type_t>
SEQAN3_CONCEPT strong_type_specialisation = requires (strong_type_t && obj)
{
typename strong_type_t::value_type;
{strong_type_t::skills};
requires std::derived_from<strong_type_t, // I forgot the order of arguments.
strong_type<typename strong_type_t::value_type,
strong_type_t,
strong_type_t::skills>>;
}
with some additional std::remove_cvref_t
for strong_type_t &
instances?
I think this would be a bit more close to the intention of type specialisation. (I forgot in our earlier discussion that the strong type is inherited, so is_type_specialisation_of_v
wouldn't have worked even without mixed template arguments.)
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'll check
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.
did you check?
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.
still open?
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.
no
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.
Only small stuff
SEQAN3_CONCEPT strong_type_specialisation = requires (strong_type_t && obj) | ||
{ | ||
//!\endcond | ||
|
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.
did you check?
@@ -112,11 +166,12 @@ namespace seqan3::detail | |||
* | |||
* \include test/snippet/core/detail/strong_type_adding_skills.cpp | |||
*/ | |||
template <typename value_t, typename derived_t, strong_type_skill skills = strong_type_skill::none> | |||
template <typename value_t, typename derived_t, strong_type_skill type_skills = strong_type_skill::none> |
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.
Hm I have the feeling this might be resolved in another commit but then again your commit history is clean?
* \returns `stream_t &` A reference to the given stream. | ||
*/ | ||
template <typename char_t, strong_type_specialisation strong_type_t> | ||
debug_stream_type<char_t> & operator<<(debug_stream_type<char_t> & stream, strong_type_t && value) |
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.
Shouldn't this also require that the underlying type is streamable?
Edit: Damn but we still have this bug that "everything is streamable" right?
requires std::same_as<band_t, static_band> | ||
//!\endcond | ||
struct band : public pipeable_config_element<band<band_t>, band_t> | ||
class band_fixed_size : public pipeable_config_element<band_fixed_size, seqan3::detail::empty_type> |
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.
#1871 is merged :D
5011d11
to
646a771
Compare
SEQAN3_CONCEPT strong_type_specialisation = requires (strong_type_t && obj) | ||
{ | ||
//!\endcond | ||
|
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.
still open?
…gn_cfg::band_fixed_size * Rename the existing band to align_cfg::band_fixed_size * Introducing strong types for setting lower and upper diagonal * Direct access of the members via the config. * Adjust the tutorial and all snippets * Adjust the API documentation * Remove all references to the old static_band mechanism * Fix all dependent classes and tests
646a771
to
f63e2b9
Compare
Changes
fixes seqan/product_backlog#98