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.

Sign up for GitHub

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

Jump to bottom

Class templates in Clause 33 are not indented #1516

Closed
jwakely opened this issue Mar 5, 2017 · 5 comments
Closed

Class templates in Clause 33 are not indented #1516

jwakely opened this issue Mar 5, 2017 · 5 comments

Comments

@jwakely
Copy link
Member

jwakely commented Mar 5, 2017 •
edited

For example:

namespace std {
  template <class R>
  class future {

This applies to all the lock types, promise, future and packaged_task. I'll fix it after motions-2017-03-lwg-17 is merged in, because that adds a new lock type (which is not indented, for local consistency).
@jwakely
Copy link
Member Author

jwakely commented Mar 5, 2017

Instead of indenting the entire class bodies by an additional two spaces we could take the approach used by reference_wrapper

namespace std {
  template <class R> class future {

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 6, 2017

@jwakely: I'm not sure. That doesn't generallze well, and we can't do that for every class template. So perhaps we shouldn't do it for any. There's no problem with indenting that body by another two spaces.

@jensmaurer
Copy link
Member

Uh, it's nowhere indented, it seems: [ios.overview], [vector.overview]. Do you have an example of your desired indentation?

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Feb 15, 2018
@tkoeppe
Copy link
Contributor

tkoeppe commented Feb 15, 2018

@jensmaurer: I thought we had already come to a decision on this in a different issue somewhere; check the wiki? [re.traits] would be an example of the style I believe I was referring to, although I think we ultimately decided against that and in favour of the style given in the OP here (in case where we do break the line).

@jensmaurer
Copy link
Member

Follow-on discussions in #1576, partly overridden by #1754.

@jensmaurer jensmaurer mentioned this issue Feb 16, 2018
Closed
@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jwakely @tkoeppe @jensmaurer