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.

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

Inconsistent spacing between "template" and "<" #53

Closed
sdutoit opened this issue Apr 15, 2013 · 15 comments
Closed

Inconsistent spacing between "template" and "<" #53

sdutoit opened this issue Apr 15, 2013 · 15 comments
Assignees
Milestone

Comments

@sdutoit
Copy link
Contributor

sdutoit commented Apr 15, 2013

From an email to cxxeditor@:

template<typename T>

or

template <typename T>

The standard as-is has 1494 instances of 'template<' that I can find trivially, and 2053 instances of 'template <'.

@sdutoit
Copy link
Contributor Author

sdutoit commented Apr 15, 2013

I intend to use template <typename T> throughout - if only because there are more instances of that style existing, and the choice is arbitrary.

@lichray
Copy link
Contributor

lichray commented Aug 29, 2013

I +1 for using typename in place of class in template parameter list wherever possible.

@PeterSommerlad
Copy link

My +100 template is so "last millenium" :-)
On 29.08.2013, at 23:42, Zhihao Yuan notifications@github.com wrote:

I +1 for using typename in place of class in template parameter list wherever possible.


Reply to this email directly or view it on GitHub.

@PeterSommerlad
Copy link

Or were you only talking about the space between template and < ???

@lichray
Copy link
Contributor

lichray commented Aug 30, 2013

The thread itself is talking about the spacing. I seldom see <typename T>'s usage in the standard, so I suddenly felt too excited...

@zygoloid
Copy link
Member

Editorial meeting consensus: use template< not template < (41% vs 59%, but we prefer the former).
Use class not typename unless the example is demonstrating that typename can be used, since class is 2-3 orders of magnitude more common.

@AlisdairM
Copy link
Contributor

AlisdairM commented Jul 6, 2016

Can we confirm the preference is:

template<class T, template class<class U>>
and not
template <typename T,template class <typename U> >

(space and keyword choice)

I will perform a sweep of all library clauses after the Oulu papers land, and apply the preferred rule.
Understood that this may miss the CD, but should be easily landed before ballot resolutions arrive.

My preference would be template <typename T, template typename<typename U>> so it is a good job that I don't get to pick ;)

@tkoeppe
Copy link
Contributor

tkoeppe commented Jul 6, 2016

@AlisdairM: My understanding is that "space after comma" and "closing >>" are uncontroversial and desirable. On the other hand, both openings template< and template < appear in roughly equal numbers and should not be changed at this point.

It's probably best to wait until all the motions have been merged unless you're happy to rebase.

@AlisdairM
Copy link
Contributor

I want to do whatever is required to close the issue - the legwork seems easy, but repetitive :)
Yes, I definitely plan to wait till all the motions have landed, so that I am looking at the full text.

I would prefer guidance to resolve one way or the other on the 'template <' vs. 'template<', but if the conclusion is that both are acceptable, I will look for local consistency in each clause, and leave it at that.

@FrankHB
Copy link
Contributor

FrankHB commented Jul 11, 2016

I don't like the idea to choose a style merely according to the amount of instances, unless there are no other reasons.

Personally I prefer template< as we usually don't have any whitespace between identifier and lparen of function parameter list in a function declaration. Spaces are also rarely occurred before ( or < of function/template argument lists. This results a simpler rule: just avoid any space before the first token of function/template parameter/argument lists. The current preference of space fits to my flavor:)

BTW, I've ever searched for some tools to format code in this style, but failed. Notably, clang-format had implemented the needed functionality about whitespace after template, but eventually rejected. The reviewer also mentioned the style in the standard. Perhaps they should reconsider it this time.
See also http://stackoverflow.com/questions/34423615/cpp-template-spacing-using-clang-format-3-6-not-working-as-expected.

Note I still prefer typename to ease some refactoring work, as template<typename T, template<typename> class C>. Some more tips:

  • Order is significant. Please note the phrase template class is not well-formed here...
  • I prefer >> because it looks tightly.
  • I don't keep optional parameter names in any parameter list, unless they are necessary (esp. for documentation). Proper naming is difficult.
  • I use class only when it should be a "class". For a template template-parameter, it must be a "class" rather than "typename" since ordinary types have no way to be higher-rank polymorphic in C++. Choosing permissive requirements of grammar is an effort to simplify the parser of a conforming implementation rather than direct encouragement to prefer class over typename.

@jwakely
Copy link
Member

jwakely commented Jul 11, 2016

I have a weak preference for template< without a space, just because it's slightly more compact and so gives us one more character spare. That way we might be able to fit something on one line that needed breaking (or ran into the margin) otherwise.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Nov 18, 2016
jensmaurer added a commit to jensmaurer/draft that referenced this issue Dec 20, 2016
Use 'template<class T>'.
Also remove space between two closing template brackets in [lib].

Fixes cplusplus#53.
jensmaurer added a commit to jensmaurer/draft that referenced this issue Dec 20, 2016
Use 'template<class T>'.
Also remove space between two closing template brackets in [lib].

Fixes cplusplus#53.
@jensmaurer jensmaurer self-assigned this Dec 20, 2016
@jensmaurer jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Dec 20, 2016
@jensmaurer
Copy link
Member

Editorial meeting consensus: Don't apply for C++17.

@jensmaurer jensmaurer added this to the C++20 milestone Mar 2, 2017
jensmaurer added a commit to jensmaurer/draft that referenced this issue Mar 5, 2017
Use 'template<class T>'.
Also remove space between two closing template brackets in [lib].

Fixes cplusplus#53.
jensmaurer added a commit to jensmaurer/draft that referenced this issue Mar 5, 2017
Use 'template<class T>'.
Also remove space between two closing template brackets in [lib].

Fixes cplusplus#53.
@burblebee burblebee reopened this Mar 8, 2019
@burblebee
Copy link
Contributor

I'm reopening this because I ran into this while reviewing PR #2719, applied from P1458R1. I would like to see a consistent form for this, with guidance added to our Specification-Style-Guidelines.

@burblebee burblebee added the decision-required A decision of the editorial group (or the Project Editor) is required. label Mar 8, 2019
@CaseyCarter
Copy link
Contributor

CaseyCarter commented Mar 8, 2019

FWIW, we use template< in the specification of the Library, but allow template < in some examples (IIRC) as a nod to the validity of both styles. I suspect it would simplify the editorial team's job if you instituted a blanket ban on template < so the CI could validate it.

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 9, 2019

@burblebee: Thanks for finding this. The guidance is clear (see above); I have finally updated the wiki to reflect this. Please apply the intended (no-space) formatting to this and all future wording changes.

@tkoeppe tkoeppe closed this as completed Mar 9, 2019
@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
Labels
None yet
Projects
None yet
Development

No branches or pull requests