[clang-format] Formatting constructor initializer lists by putting them always on different lines

[JVApen]

Summary

Hi all,

I've been playing around with the clang for a while now and really enjoy it. Unfortunately clang-format does not yet do what I like it to do, so I started hacking it. So here is my first successful attempt to get something working.

The issue: ConstructorInitializerAllOnOneLineOrOnePerLine only works if 'If the constructor initializers don’t fit on a line', while I prefer it to always work. In other words, I use the following formatting:

Constructor()
  : a(a)
  , b(b)

Since everyone can benefit from upstreaming, I like to share my changes and get some feedback.
Here is already some of the stuff which I was uncertain about:

• Should I keep ConstructorInitializerAllOnOneLineOrOnePerLine or rename it (currently the second one)
• How to name the values, currently: Compact (old: false), BestFit (old: true), OnePerLine (new)
• Is the back-ward compatibility in ScalarEnumerationTraits a good idea? (On rename most likely not)

JVApen

[djasper]

Please read
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options

Does your style option qualify?

[JVApen]

In D14484#284767, @djasper wrote:

Please read
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options

Does your style option qualify?

• Is it used by a project of significant size? Yes, we use the same style at work, where I try to get this used by about 70 developers. (Which I consider already dozens of contributors) Though it is also the same style I learned at school.
• Does it have a publicly accessible style guide? Yes, it's both an accepted by the Google Style guide as Ubuntu Unity, which do not state that you have to use the compact form. Further more the graphisoft styleguide doesn't appear to allow the condensed form.
• Does it have a person willing to contribute and maintain patches? Maybe, I currently don't believe I'm familiar enough with the code to maintain it. Though without putting it out here (e.g. LLVM community) the answer will definitely be no. Furthermore, beside the 2 lines in TokenAnnotator.cpp, this style does not differentiate from the current implementation.

Though since you are the/a maintainer of this code, you are more qualified to give a final answer on this question.

Regardless, even if you don't want this patch upstreamed, I like to understand the codebase better as well as the considerations which lead to certain decisions for code changes. (See also the uncertainties I listed in the original post) Which at least will make my local changes similar to what they would be in case you would allow an upstream of them.

[djasper]

The Google and Unity style guides have explicit examples of using the one-line version. The other style guide (at least to me) isn't clear on forbidding what clang-format currently does.

My gut feeling is that it is not worth the cost of renaming and extending the current style option. If you are trying to convince ~70 people to use clang-format, there will be several things where it doesn't do 100% what the current practice is. However, this issue (like probably several of the others) is quite an infrequent issue with very limited impact on readability.

unittests/Format/FormatTest.cpp

9753

The reason we commonly accept true/false after migrating to an enum is so that the config files remain backwards compatible. If we rename the style attribute, however, more needs to be done to keep this backwards compatible. Setting the old name to true or false should set the corresponding value of the new name unless that one is explicitly set.

[djasper]

I actually have more thoughts on this. If we go down this road, there are many more options that people might envision. Maybe they don't want to wrap the initializer list, if there is just one initializer. Maybe they want to align the initializers somewhere after the constructor parameters:

Constructor() : aaa(aaa),
                bbb(bbb) {}

There are many options to do this, but really the difference in readability is quite small and I think it adds unnecessary complexity to clang-format.

[nhlubek]

Is it possible to discuss about this feature again?

This is only a corner case if you allow only 80 characters per line.
If you allow more characters (e.g. you use doxygen for inline formatting and want some space on the right) this quickly becomes very relevant, because then each initializer list gets very unreadable.

Currently it is even not possible, to reproduce the mock up example in the original implementation
(only by setting the line limit at 40 or so which is a bit unreasonable).
https://reviews.llvm.org/D32479

// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
    initializer1(),
    initializer2()
{}

[rfairliecuninghame]

I also think this feature bears further consideration.

I understand that google and other coding standard currently allows this, but I feel there's a certain degree of inconsistency in their doing so.
None of the open main coding standards would recommend or allow putting multiple variable initializations/assignments per line but this is effectively what is occurring in allowing this.
After all,

MyClass::MyClass(long _state1Long, short _state2Short, int *_state3Ptr)
  : state1Long(_state1Long), state2Short(_state2Short), state3Ptr(*_state3Ptr) {
}

is conceptually much the same as

MyClass::MyClass(long _state1Long, short _state2Short, int *_state3Ptr) {
  state1Long = _state1Long; state2Short = _state2Short; state3Ptr = *_state3Ptr;
}

which you would of course never allow.
I'm sure this conceptual inconsistency is apparent to a fair number of other C++ style guide writers where a one-per-line limitation on constructor initializers is mandated. [I'm in a similar position to JVApen and have had to patch the program to order to meet this requirement at my workplace.] Anyway, just an observation on the matter.

[rfairliecuninghame]

The excellent and extensive Poco library project (https://pocoproject.org/) is an open-source example which only places one constructor initializer per line (StyleGuide here: http://www.appinf.com/download/CppCodingStyleGuide.pdf, random example: https://github.com/pocoproject/poco/blob/master/Foundation/src/Base64Decoder.cpp).

[puya]

For what it's worth the original post is also the style used at our company. I am hesitant to patch clang-format as I don't want to have to maintain it so I hope this is added as an option. Or if there was a way we could add this style without having to patch clang format.

[MyDeveloperDay]

Looking at this I'm wondering if this Isn't at least partially handled by the BreakConstructorInitializersStyle in combination with ConstructorInitializerAllOnOneLineOrOnePerLine style?

I can't be exactly sure but I think BreakConstructorInitializersStyle didn't exist before 2017 D32479: clang-format: Introduce BreakConstructorInitializers option when this original patch was submitted

BreakConstructorInitializers: BeforeComma
ConstructorInitializerAllOnOneLineOrOnePerLine: true

SomeClass::Constructor() : aaaaaa(aaaaaaa), bbbbbb(bbbbbbb), cc(cc) {}

SomeClass::Constructor()
    : aaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaa,
             aaaaaaaaaaaaaaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

BreakConstructorInitializers: BeforeComma
ConstructorInitializerAllOnOneLineOrOnePerLine: false

SomeClass::Constructor()
    : aaaaaa(aaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

SomeClass::Constructor()
    : aaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaa,
             aaaaaaaaaaaaaaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

At least the unit tests appear to be covered by using those styles?

Nit: At a minimum, this patch would need to be rebased and be a full context diff, can anyone see a use case that can't be covered with what we have?

Moving to "request changes" (really request to abandon if not necessary any longer)

[puya]

Looking at this I'm wondering if this Isn't at least partially handled by the BreakConstructorInitializersStyle in combination with ConstructorInitializerAllOnOneLineOrOnePerLine style?

I’m fairly certain that’s only true when line is long enough to be broken. In which case second one ensures one per line (as opposed to different number of initializations per line) and the first one determines the style. They would not result in the requested behavior if the line is not longer than max column. (I will double check when I am in front of a computer)

[nhlubek]

In D14484#1689271, @MyDeveloperDay wrote:

Looking at this I'm wondering if this Isn't at least partially handled by the BreakConstructorInitializersStyle in combination with ConstructorInitializerAllOnOneLineOrOnePerLine style?

[...]

At least the unit tests appear to be covered by using those styles?

I checked with https://zed0.co.uk/clang-format-configurator/ and it isn't handled.

The reason is that BreakConstructorInitializersStyle only comes into play if the constructor initializers don't fit on a line.
The unit tests work because they have

Style.ColumnLimit = 60;

[nhlubek]

Required change for break after colon:

https://github.com/llvm-mirror/clang/pull/67

New unit test shows use case that is not covered currently.

[FStefanni]

Hi to all,

I am also interested to this option, since match my personal style, but more important, in my experience, this kind of formatting is very used.
I hope it will be implemented in a near future.

Which is the current status? Is someone going to support this?

Regards.

[catskul]

In D14484#2246171, @FStefanni wrote:

Hi to all,

I am also interested to this option, since match my personal style, but more important, in my experience, this kind of formatting is very used.
I hope it will be implemented in a near future.

Which is the current status? Is someone going to support this?

Regards.

@FStefanni it seems ConstructorInitializerAllOnOneLineOrOnePerLine = false may do the trick per @MyDeveloperDay .

I tried this and had success so far. Try it out and see if it resolves your use case.

In D14484#1689271, @MyDeveloperDay wrote:

Looking at this I'm wondering if this Isn't at least partially handled by the BreakConstructorInitializersStyle in combination with ConstructorInitializerAllOnOneLineOrOnePerLine style?

I can't be exactly sure but I think BreakConstructorInitializersStyle didn't exist before 2017 D32479: clang-format: Introduce BreakConstructorInitializers option when this original patch was submitted

BreakConstructorInitializers: BeforeComma
ConstructorInitializerAllOnOneLineOrOnePerLine: true

SomeClass::Constructor() : aaaaaa(aaaaaaa), bbbbbb(bbbbbbb), cc(cc) {}

SomeClass::Constructor()
    : aaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaa,
             aaaaaaaaaaaaaaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

BreakConstructorInitializers: BeforeComma
ConstructorInitializerAllOnOneLineOrOnePerLine: false

SomeClass::Constructor()
    : aaaaaa(aaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

SomeClass::Constructor()
    : aaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaa,
             aaaaaaaaaaaaaaaaaaa)
    , bbbbbb(bbbbbbb)
    , cc(cc) {}

At least the unit tests appear to be covered by using those styles?

Nit: At a minimum, this patch would need to be rebased and be a full context diff, can anyone see a use case that can't be covered with what we have?

Moving to "request changes" (really request to abandon if not necessary any longer)

[FStefanni]

Hi,

thank you for the suggestion, but it does not, at least with BreakConstructorInitializers: AfterColon (which is what I use).
If initializers are "small enough" to fit the constructor line, all will finish on the same line.

E.g.

MyClass::MyClass(): a(), b()
{}

But what I like is:

MyClass::MyClass(): 
    a(), 
    b()
{}

Regards.

[catskul]

@FStefanni, after managing to update this patch to work with the latest code, and trying out your example it appears this patch doesn't quite cover your case.

I did manage to fix it to cover your case, but I suppose at this point I should ask @MyDeveloperDay and @djasper, can/should I upload my diff to replace this one?

I'd like to adopt this diff and get it past the finish line if possible.

@JVApen, do you mind me adopting this, would you rather? I can pass it back to you if you'd prefer.

In D14484#2338756, @FStefanni wrote:

Hi,

thank you for the suggestion, but it does not, at least with BreakConstructorInitializers: AfterColon (which is what I use).
If initializers are "small enough" to fit the constructor line, all will finish on the same line.

...

[tksuoran]

I would like to use exactly the same formatting (really exactly one initializer (and nother else) per line).
Some comments:

• Keep ConstructorInitializerAllOnOneLineOrOnePerLine so that the change does not break any existing behavior
• Default value for ConstructorInitializerKind would make ConstructorInitializerAllOnOneLineOrOnePerLine to be used
• Non-default values for ConstructorInitializerKind would enable for example really exactly one initializer per line - yay!
• End result:
  • Old style settings keep working and it just works, giving old results
  • New style settings can omit ConstructorInitializerAllOnOneLineOrOnePerLine and use ConstructorInitializerKind and it just works

[MyDeveloperDay]

We can't rename options without giving some form of backwards compatibility, personally, I think we need to start again with this review if its still of interest, this one is 6 years old.

[FStefanni]

Hi,

in case of any doubt: yet it is of interest.
6 years old means only that it has not been "fixed" in the meanwhile...

Please consider that there are not many code formatters for C++, since it is quite a complex language (and a lot of different formatting conventions!).
So we are just waiting to have integrated the formatting rules that we need.

Regards.

[Jeroen]

In D14484#2788953, @FStefanni wrote:

Hi,

in case of any doubt: yet it is of interest.
6 years old means only that it has not been "fixed" in the meanwhile...

Please consider that there are not many code formatters for C++, since it is quite a complex language (and a lot of different formatting conventions!).
So we are just waiting to have integrated the formatting rules that we need.

Regards.

Feel free to revive my patch, I'll be very happy to finally start using this.

[nhlubek]

In order to push this forward I have written a bug ticket that highlights this issue:

https://bugs.llvm.org/show_bug.cgi?id=50549

The patch is also really simple with the clang-format options that are available nowadays
https://github.com/Nikolai-Hlubek/clang/tree/ConstructorInitializer_AlwaysBreakAfterColon

[owenpan]

See D108752.

[HantaoPan]

Hi,
I am interesting in this feature too. You know, consistency is crucial to a large program...
As for as I known, Clion has this option "Wrap always" in Function declaration parameters. This is exactly what I need!

regards,

[owenpan]

In D14484#4079711, @HantaoPan wrote:

Hi,
I am interesting in this feature too. You know, consistency is crucial to a large program...

regards,

As mentioned above, it has been added in D108752. See also https://clang.llvm.org/docs/ClangFormatStyleOptions.html#packconstructorinitializers.

[HantaoPan]

In D14484#4087827, @owenpan wrote:

In D14484#4079711, @HantaoPan wrote:

Hi,
I am interesting in this feature too. You know, consistency is crucial to a large program...

regards,

As mentioned above, it has been added in D108752. See also https://clang.llvm.org/docs/ClangFormatStyleOptions.html#packconstructorinitializers.

Thank you! Is there a similar flag wrt function parameter? (say a "Never" other than "false", which can always put each function parameter on its own line.)

[owenpan]

In D14484#4087879, @HantaoPan wrote:

Thank you! Is there a similar flag wrt function parameter? (say a "Never" other than "false", which can always put each function parameter on its own line.)

Nope.

docs/ClangFormatStyleOptions.rst

   A regular expression that describes comments with special meaning,
   which should not be split into lines or otherwise changed.
 
-**ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``)
-  If the constructor initializers don't fit on a line, put each
-  initializer on its own line.
+**ConstructorInitializer** (``ConstructorInitializerKind``)
+  Formatting of the constructor initializer.
 
+  Possible values:
+
+  * ``CI_Compact`` (in configuration: ``Compact``)
+    Puts all the initializers in a compact block of multiple lines with
+    multiple initializers on the same line.
+  * ``CI_BestFit`` (in configuration: ``BestFit``)
+    Eiter all initializers are on a single line (it this fits),
+    otherwise every initializer has its own line.
+  * ``CI_OnePerLine`` (in configuration: ``OnePerLine``)
+    Always put the initializers on their own line, regardless if they would fit
+    on a single line.
+
 **ConstructorInitializerIndentWidth** (``unsigned``)
   The number of characters to use for indentation of constructor
   initializer lists.

include/clang/Format/Format.h

   /// which should not be split into lines or otherwise changed.
   std::string CommentPragmas;
 
-  /// \brief If the constructor initializers don't fit on a line, put each
-  /// initializer on its own line.
-  bool ConstructorInitializerAllOnOneLineOrOnePerLine;
+  enum ConstructorInitializerKind {
+    CI_Compact,    ///< Put all initializers in a compact block
+    CI_BestFit,    ///< Use the compact if all fits on a single line,
+                   ///< otherwise put one per line.
+    CI_OnePerLine, ///< Put all initializers on their own line
+  };
 
+  /// \brief The placement of the constructor initializers.
+  ConstructorInitializerKind ConstructorInitializer;
+
   /// \brief The number of characters to use for indentation of constructor
   /// initializer lists.
   unsigned ConstructorInitializerIndentWidth;

                R.BreakConstructorInitializersBeforeComma &&
            BreakAfterJavaFieldAnnotations == R.BreakAfterJavaFieldAnnotations &&
            ColumnLimit == R.ColumnLimit && CommentPragmas == R.CommentPragmas &&
-           ConstructorInitializerAllOnOneLineOrOnePerLine ==
-               R.ConstructorInitializerAllOnOneLineOrOnePerLine &&
+           ConstructorInitializer == R.ConstructorInitializer &&
            ConstructorInitializerIndentWidth ==
                R.ConstructorInitializerIndentWidth &&
            ContinuationIndentWidth == R.ContinuationIndentWidth &&

lib/Format/ContinuationIndenter.cpp

     State.Stack.back().Indent =
         State.Column + (Style.BreakConstructorInitializersBeforeComma ? 0 : 2);
     State.Stack.back().NestedBlockIndent = State.Stack.back().Indent;
-    if (Style.ConstructorInitializerAllOnOneLineOrOnePerLine)
+    if (Style.ConstructorInitializer != FormatStyle::CI_Compact)
       State.Stack.back().AvoidBinPacking = true;
-    State.Stack.back().BreakBeforeParameter = false;
+    State.Stack.back().BreakBeforeParameter =
+        (Style.ConstructorInitializer == FormatStyle::CI_OnePerLine);
   }
   if (Current.isOneOf(TT_BinaryOperator, TT_ConditionalExpr) && Newline)
     State.Stack.back().NestedBlockIndent =

lib/Format/Format.cpp

   }
 };
 
+
+template <>
+struct ScalarEnumerationTraits<FormatStyle::ConstructorInitializerKind> {
+  static void enumeration(IO &IO,
+                          FormatStyle::ConstructorInitializerKind &Value) {
+    IO.enumCase(Value, "Compact", FormatStyle::CI_Compact);
+    IO.enumCase(Value, "BestFit", FormatStyle::CI_BestFit);
+    IO.enumCase(Value, "OnePerLine", FormatStyle::CI_OnePerLine);
+
+    // For backward compatibility.
+    IO.enumCase(Value, "false", FormatStyle::CI_Compact);
+    IO.enumCase(Value, "true", FormatStyle::CI_BestFit);
+  }
+};
+
 template <> struct MappingTraits<FormatStyle> {
   static void mapping(IO &IO, FormatStyle &Style) {
     // When reading, read the language first, we need it for getPredefinedStyle.

                    Style.BreakConstructorInitializersBeforeComma);
     IO.mapOptional("ColumnLimit", Style.ColumnLimit);
     IO.mapOptional("CommentPragmas", Style.CommentPragmas);
-    IO.mapOptional("ConstructorInitializerAllOnOneLineOrOnePerLine",
-                   Style.ConstructorInitializerAllOnOneLineOrOnePerLine);
+    IO.mapOptional("ConstructorInitializer", Style.ConstructorInitializer);
     IO.mapOptional("ConstructorInitializerIndentWidth",
                    Style.ConstructorInitializerIndentWidth);
     IO.mapOptional("ContinuationIndentWidth", Style.ContinuationIndentWidth);

   LLVMStyle.BreakAfterJavaFieldAnnotations = false;
   LLVMStyle.ColumnLimit = 80;
   LLVMStyle.CommentPragmas = "^ IWYU pragma:";
-  LLVMStyle.ConstructorInitializerAllOnOneLineOrOnePerLine = false;
+  LLVMStyle.ConstructorInitializer = FormatStyle::CI_Compact;
   LLVMStyle.ConstructorInitializerIndentWidth = 4;
   LLVMStyle.ContinuationIndentWidth = 4;
   LLVMStyle.Cpp11BracedListStyle = true;

   GoogleStyle.AllowShortLoopsOnASingleLine = true;
   GoogleStyle.AlwaysBreakBeforeMultilineStrings = true;
   GoogleStyle.AlwaysBreakTemplateDeclarations = true;
-  GoogleStyle.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  GoogleStyle.ConstructorInitializer = FormatStyle::CI_BestFit;
   GoogleStyle.DerivePointerAlignment = true;
   GoogleStyle.IncludeCategories = {{"^<.*\\.h>", 1}, {"^<.*", 2}, {".*", 3}};
   GoogleStyle.IndentCaseLabels = true;

lib/Format/TokenAnnotator.cpp

       Right.Previous->MatchingParen->NestingLevel == 0 &&
       Style.AlwaysBreakTemplateDeclarations)
     return true;
+  if (Right.is(TT_CtorInitializerColon) &&
+      Style.ConstructorInitializer == FormatStyle::CI_OnePerLine)
+    return true;
   if ((Right.isOneOf(TT_CtorInitializerComma, TT_CtorInitializerColon)) &&
-      Style.BreakConstructorInitializersBeforeComma &&
-      !Style.ConstructorInitializerAllOnOneLineOrOnePerLine)
+      (Style.BreakConstructorInitializersBeforeComma &&
+      Style.ConstructorInitializer == FormatStyle::CI_Compact))
     return true;
   if (Right.is(tok::string_literal) && Right.TokenText.startswith("R\""))
     // Raw string literals are special wrt. line breaks. The author has made a

unittests/Format/FormatTest.cpp

                "      aaaaaaaaaaa(aaaaaaaaaaa),\n"
                "      aaaaaaaaaaaaaaaaaaaaat(aaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}");
 
+  FormatStyle BestFit = getLLVMStyle();
+  BestFit.ConstructorInitializer = FormatStyle::CI_BestFit;
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaaaaaaaaaa(aaaaaaaaaaaaaa),\n"
+               "      aaaaaaaaaaaaa(aaaaaaaaaaaaaa),\n"
+               "      aaaaaaaaaaaaa(aaaaaaaaaaaaaa) {}",
+               BestFit);
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaaaaaaaaaa(aaaaaaaaaaaaaa), // Some comment\n"
+               "      aaaaaaaaaaaaa(aaaaaaaaaaaaaa),\n"
+               "      aaaaaaaaaaaaa(aaaaaaaaaaaaaa) {}",
+               BestFit);
+  verifyFormat("MyClass::MyClass(int var)\n"
+               "    : some_var_(var),            // 4 space indent\n"
+               "      some_other_var_(var + 1) { // lined up\n"
+               "}",
+               BestFit);
+  verifyFormat("Constructor() : a(a), a(a) {}\n",
+               BestFit);
+  verifyFormat("Constructor()\n"
+               "    : aaaaa(aaaaaa),\n"
+               "      aaaaa(aaaaaa),\n"
+               "      aaaaa(aaaaaa),\n"
+               "      aaaaa(aaaaaa),\n"
+               "      aaaaa(aaaaaa) {}",
+               BestFit);
+  verifyFormat("Constructor()\n"
+               "    : aaaaa(aaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaa,\n"
+               "            aaaaaaaaaaaaaaaaaaaaaa) {}",
+               BestFit);
+  BestFit.ColumnLimit = 60;
+  verifyFormat("Constructor()\n"
+               "    : aaaaaaaaaaaaaaaaaaaa(a),\n"
+               "      bbbbbbbbbbbbbbbbbbbbbbbb(b) {}",
+               BestFit);
+
+  EXPECT_EQ("Constructor()\n"
+            "    : // Comment forcing unwanted break.\n"
+            "      aaaa(aaaa) {}",
+            format("Constructor() :\n"
+                   "    // Comment forcing unwanted break.\n"
+                   "    aaaa(aaaa) {}"));
+
   FormatStyle OnePerLine = getLLVMStyle();
-  OnePerLine.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  OnePerLine.ConstructorInitializer = FormatStyle::CI_OnePerLine;
   verifyFormat("SomeClass::Constructor()\n"
                "    : aaaaaaaaaaaaa(aaaaaaaaaaaaaa),\n"
                "      aaaaaaaaaaaaa(aaaaaaaaaaaaaa),\n"

                "}",
                OnePerLine);
   verifyFormat("Constructor()\n"
+               "    : a(a),\n"
+               "      a(a) {}",
+               OnePerLine);
+  verifyFormat("Constructor()\n"
                "    : aaaaa(aaaaaa),\n"
                "      aaaaa(aaaaaa),\n"
                "      aaaaa(aaaaaa),\n"

 
   // This test takes VERY long when memoization is broken.
   FormatStyle OnePerLine = getLLVMStyle();
-  OnePerLine.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  OnePerLine.ConstructorInitializer = FormatStyle::CI_BestFit;
   OnePerLine.BinPackParameters = false;
   std::string input = "Constructor()\n"
                       "    : aaaa(a,\n";

   CHECK_PARSE_BOOL(BinPackParameters);
   CHECK_PARSE_BOOL(BreakBeforeTernaryOperators);
   CHECK_PARSE_BOOL(BreakConstructorInitializersBeforeComma);
-  CHECK_PARSE_BOOL(ConstructorInitializerAllOnOneLineOrOnePerLine);
   CHECK_PARSE_BOOL(DerivePointerAlignment);
   CHECK_PARSE_BOOL_FIELD(DerivePointerAlignment, "DerivePointerBinding");
   CHECK_PARSE_BOOL(IndentCaseLabels);

   CHECK_PARSE("SpaceAfterControlStatementKeyword: true", SpaceBeforeParens,
               FormatStyle::SBPO_ControlStatements);
 
+  Style.ConstructorInitializer = FormatStyle::CI_BestFit;
+  CHECK_PARSE("ConstructorInitializer: Compact", ConstructorInitializer,
+              FormatStyle::CI_Compact);
+  CHECK_PARSE("ConstructorInitializer: BestFit", ConstructorInitializer,
+              FormatStyle::CI_BestFit);
+  CHECK_PARSE("ConstructorInitializer: OnePerLine", ConstructorInitializer,
+              FormatStyle::CI_OnePerLine);
+  // For backward compatibility:
+  CHECK_PARSE("ConstructorInitializer: false", ConstructorInitializer,
+              FormatStyle::CI_Compact);
+  CHECK_PARSE("ConstructorInitializer: true", ConstructorInitializer,
+              FormatStyle::CI_BestFit);
+
   Style.ColumnLimit = 123;
   FormatStyle BaseStyle = getLLVMStyle();
   CHECK_PARSE("BasedOnStyle: LLVM", ColumnLimit, BaseStyle.ColumnLimit);

                ", c(c) {}",
                Style);
 
-  Style.ConstructorInitializerAllOnOneLineOrOnePerLine = true;
+  Style.ConstructorInitializer = FormatStyle::CI_BestFit;
   Style.ConstructorInitializerIndentWidth = 4;
   verifyFormat("SomeClass::Constructor() : aaaaaaaa(aaaaaaaa) {}", Style);
   verifyFormat(

                "    , aaaaaaaa(aaaaaaaa)\n"
                "    , aaaaaaaa(aaaaaaaa) {}",
                Style);
+
+  Style.ConstructorInitializer = FormatStyle::CI_OnePerLine;
+  Style.ConstructorInitializerIndentWidth = 4;
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaaaaa(aaaaaaaa) {}",
+               Style);
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaa(aaaaa)\n"
+               "    , aaaaa(aaaaa)\n"
+               "    , aaaaa(aaaaa)\n",
+               Style);
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaaaaa(aaaaaaaa)\n"
+               "    , aaaaaaaa(aaaaaaaa)\n"
+               "    , aaaaaaaa(aaaaaaaa) {}",
+               Style);
+  Style.ConstructorInitializerIndentWidth = 4;
+  Style.ColumnLimit = 60;
+  verifyFormat("SomeClass::Constructor()\n"
+               "    : aaaaaaaa(aaaaaaaa)\n"
+               "    , aaaaaaaa(aaaaaaaa)\n"
+               "    , aaaaaaaa(aaaaaaaa) {}",
+               Style);
 }
 
 TEST_F(FormatTest, Destructors) {