Skip to content

Conversation

@CaseyCarter
Copy link
Contributor

@CaseyCarter CaseyCarter commented Feb 24, 2021

These constraints redundantly repeat the constraints from the template we're partially specializing for. This isn't incorrect, but it is unnecessary, adds opportunities for editorial errors, and is inconsistent with how other partial specializations of templates for constrained types are specified.

EDIT: To be perfectly clear, removing these constraints has no normative effect. One cannot so much as form the template-id meow<T, U> if T and U don't satisfy the constraints of meow. So if a partial specialization matches the pattern meow<T, U>, we know a priori that the constraints of meow are satisfied by T and U. The only possible results of duplicating the constraints are that an implementation may waste compiletime rechecking them, and WG21 will waste time keeping them in sync. Witness the recent fiasco that resulted from changing the constraints on iota_view and failing to propagate that change to the four necessary places (microsoft/STL#1693 (comment)) for reference; we have enough required duplication without adding optional duplication =).

These constraints redundantly repeat the constraints from the template we're partially specializing for. This isn't incorrect, but it is unnecessary, adds opportunities for editorial errors, and is inconsistent with how other partial specializations of templates for constrained types are specified.
@jensmaurer
Copy link
Member

@jwakely , could you please approve?

@jensmaurer jensmaurer merged commit 2fdafbe into cplusplus:master Mar 12, 2021
@CaseyCarter CaseyCarter deleted the unconstrain branch March 12, 2021 23:51
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.

3 participants