Repository navigation
Why do deduction guides for take_view and drop_view have different constraints? LWG 3447 #3997
Description
Activity
I believe the presence or absence (and the spelling) of associated constraints influences partial ordering, before the shape of the target type is even considered. So, this does not appear to be an editorial change.
@CaseyCarter , @jwakely ?
drop_viewwas added later by P1035R7, so the inconsistency could just be an oversight, but I agree it's not editorial.It looks like that
take_viewguide and this one are the only constrained guides for view adaptors:template<input_range R> split_view(R&&, range_value_t<R>) -> split_view<views::all_t<R>, single_view<range_value_t<R>>>;take_viewsignificantly predatesdrop_view. When we addedtake_view, therangeconstraint was necessary to ensure thatiterator_t<R>was well-formed initer_difference_t<iterator_t<R>>.P1035 constrains
iterator_titself withrange, and addedrange_difference_t<R>as arange-constrained alias foriter_difference_t<iterator_t<R>>so neitherdrop_viewnortake_viewrequire this constraint. P1035 had blanket editorial instructions to replaceiter_difference_t<iterator_t<R>>withrange_difference_t<R>, but it didn't occur to the authors to also audit constraints elsewhere and remove any we'd made extraneous.TLDR: Changing this would have no normative effect, but it falls into that grey area where we need experts to attest to that. I suggest filing an LWG issue.
Reacted by S. B. TamHandled by LWG3447.
- changed the title
[-]Why do deduction guides for take_view and drop_view have different constraints?[/-][+]Why do deduction guides for take_view and drop_view have different constraints? LWG 3447[/+]on May 16, 2020 - addednot-editorialIssue is not deemed editorial; the editorial issue is kept open for tracking.Issue is not deemed editorial; the editorial issue is kept open for tracking.
on May 16, 2020 Status: WP
This can be closed.
In [range.take.view], the deduction guide for
take_viewis declared as:In [range.drop.view], the deduction guide for
drop_viewis declared as:Note the difference between their template parameter lists.
AFAIK there's no difference in effect, because
views::all_tonly accepts aviewable_range.Can they be declared in a more similar way?