From 9948bdc157be4d770c3d9a8a0f3ce80712061bae Mon Sep 17 00:00:00 2001 From: Herb Sutter Date: Thu, 2 May 2019 11:47:00 -0700 Subject: [PATCH] Update ES.23 to allow = initialiization (#1416) * Update ES.23 to allow = initialiization * Silencing Travis * Changed title back to original, it's fine * Add note about explicit --- CppCoreGuidelines.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 6d1eb7e..d5895a6 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -10647,15 +10647,20 @@ For initializers of moderate complexity, including for `const` variables, consid * Flag declarations with default initialization that are assigned to before they are first read. * Flag any complicated computation after an uninitialized variable and before its use. -### ES.23: Prefer the `{}` initializer syntax +### ES.23: Prefer the `{}`-initializer syntax ##### Reason -The rules for `{}` initialization are simpler, more general, less ambiguous, and safer than for other forms of initialization. +Prefer `{}`. The rules for `{}` initialization are simpler, more general, less ambiguous, and safer than for other forms of initialization. + +Use `=` only when you are sure that there can be no narrowing conversions. For built-in arithmetic types, use `=` only with `auto`. + +Avoid `()` initialization, which allows parsing ambiguities. ##### Example int x {f(99)}; + int y = x; vector v = {1, 2, 3, 4, 5, 6}; ##### Exception @@ -10663,11 +10668,14 @@ The rules for `{}` initialization are simpler, more general, less ambiguous, and For containers, there is a tradition for using `{...}` for a list of elements and `(...)` for sizes: vector v1(10); // vector of 10 elements with the default value 0 - vector v2 {10}; // vector of 1 element with the value 10 + vector v2{10}; // vector of 1 element with the value 10 + + vector v3(1, 2); // vector of 1 element with the value 2 + vector v4{1, 2}; // vector of 2 element with the values 1 and 2 ##### Note -`{}`-initializers do not allow narrowing conversions (and that is usually a good thing). +`{}`-initializers do not allow narrowing conversions (and that is usually a good thing) and allow explicit constructors (which is fine, we're intentionally initializing a new variable). ##### Example @@ -10677,7 +10685,7 @@ For containers, there is a tradition for using `{...}` for a list of elements an ##### Note -`{}` initialization can be used for all initialization; other forms of initialization can't: +`{}` initialization can be used for nearly all initialization; other forms of initialization can't: auto p = new vector {1, 2, 3, 4, 5}; // initialized vector D::D(int a, int b) :m{a, b} { // member initializer (e.g., m might be a pair) @@ -10698,7 +10706,7 @@ Initialization of a variable declared using `auto` with a single value, e.g., `{ The C++17 rules are somewhat less surprising: auto x1 {7}; // x1 is an int with the value 7 - auto x2 = {7}; // x2 is an initializer_list with an element 7 + auto x2 = {7}; // x2 is an initializer_list with an element 7 auto x11 {7, 8}; // error: two initializers auto x22 = {7, 8}; // x22 is an initializer_list with elements 7 and 8 @@ -10720,10 +10728,6 @@ Like the distinction between copy-initialization and direct-initialization itsel Use plain `{}`-initialization unless you specifically want to disable explicit constructors. -##### Note - -Old habits die hard, so this rule is hard to apply consistently, especially as there are so many cases where `=` is innocent. - ##### Example template @@ -10741,10 +10745,8 @@ Old habits die hard, so this rule is hard to apply consistently, especially as t ##### Enforcement -Tricky. - -* Don't flag uses of `=` for simple initializers. -* Look for `=` after `auto` has been seen. +* Flag uses of `=` to initialize arithmetic types where narrowing occurs. +* Flag uses of `()` initialization syntax that are actually declarations. (Many compilers should warn on this already.) ### ES.24: Use a `unique_ptr` to hold pointers