Skip to content

Conversation

@Tsche
Copy link
Member

@Tsche Tsche commented Nov 9, 2025

Fixes #8473

Also fixes cplusplus/papers#535
Also fixes cplusplus/nbballot#584
Also fixes cplusplus/nbballot#721
Also fixes cplusplus/nbballot#722
Also fixes cplusplus/nbballot#723

@Tsche
Copy link
Member Author

Tsche commented Nov 9, 2025

While applying the paper I noticed that we use the section title "Tuple interface" in [complex.tuple] and [array.tuple] instead. Shall we do the same here and rename [intseq.binding] to [intseq.tuple] along with "Tuple interface" as title?

@frederick-vs-ja
Copy link
Contributor

While applying the paper I noticed that we use the section title "Tuple interface" in [complex.tuple] and [array.tuple] instead. Shall we do the same here and rename [intseq.binding] to [intseq.tuple] along with "Tuple interface" as title?

I'm personally fine with such inconsistency because integer_sequence is not made tuple-like.

@eisenwave

This comment was marked as resolved.

@eisenwave eisenwave added this to the post-2025-11 milestone Nov 9, 2025
template<size_t I, class T, T... Values>
struct tuple_element<I, const integer_sequence<T, Values...>> {
using type = T;
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't normally apply two-space indentation to definitions of classes. However, we're not consistent about that in general. There are definitions like struct nontype_t which are indented.

I don't think it needs to be fixed here, just something to keep in mind.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to sometimes do that for short class definitions and empty classes (which would be the case for tuple_size directly above).

Currently tuple_element specializations for array, tuple and pair use 2-space indentation for the definition. Specializations for complex and ranges::subrange do not.

I've left it as is for now.

Comment on lines 84 to 86
};

template<size_t I, class T, T... Values>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this separating blank line should exist. We normally specify overload sets without such separators. However, these are not function overloads, so it's a bit of an edge case.

Note that the synopsis does not have a blank line separator.

Thomas should make a judgment call here.

Copy link
Member Author

@Tsche Tsche Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the blank line to match synopsis. For ranges::subrange we do not have a newline between tuple_element specializations either, but we also do not have one after the tuple_size specialization (which imho does not help readability).

@eisenwave
Copy link
Member

eisenwave commented Nov 12, 2025

@jensmaurer
Copy link
Member

jensmaurer commented Nov 12, 2025

Please amend the commit message per https://github.com/cplusplus/draft/wiki/Commit-message-format#nb-comment-resolutions and force-push. Feel free to squash the fix-up commit at that time.

(add "Also fixes NB ...")

@jensmaurer jensmaurer added the changes requested Changes to the wording or approach have been requested and not yet applied. label Nov 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changes requested Changes to the wording or approach have been requested and not yet applied.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2025-11 LWG Motion 14] P1789R3 Library Support for Expansion Statements P1789 R1 Library Support for Expansion Statements

4 participants