Fix CnTransGroup#107 & CnTransGroup#152

src/1.DeducingTypes/item2.md

@@ -115,21 +115,21 @@ auto x2(27);
 auto x3 = { 27 };
 auto x4{ 27 };
 ````
-这些声明都能通过编译，但是他们不像替换之前那样有相同的意义。前面两个语句确实声明了一个类型为`int`值为27的变量，但是后面两个声明了一个存储一个元素27的 `std::initializer_list<int>`类型的变量。
+这些声明都能通过编译，但是他们不像替换之前那样有相同的意义。除了第三个声明了一个存储一个元素27的 `std::initializer_list<int>`类型的变量，其他都声明了一个类型为`int`值为27的变量。
 ````cpp
 auto x1 = 27;                   //类型是int，值是27
 auto x2(27);                    //同上
 auto x3 = { 27 };               //类型是std::initializer_list<int>，
                                 //值是{ 27 }
-auto x4{ 27 };                  //同上
+auto x4{ 27 };                  //同上（译者注：书出版后，这一点发生了变化，与 x1, x2 是一个语义了）
 ````
-这就造成了`auto`类型推导不同于模板类型推导的特殊情况。当用`auto`声明的变量使用花括号进行初始化，`auto`类型推导推出的类型则为`std::initializer_list`。如果这样的一个类型不能被成功推导（比如花括号里面包含的是不同类型的变量），编译器会拒绝这样的代码：
+这就造成了`auto`类型推导不同于模板类型推导的特殊情况。当用`auto`声明的变量使用`=`+花括号进行初始化，`auto`类型推导推出的类型则为`std::initializer_list`。如果这样的一个类型不能被成功推导（比如花括号里面包含的是不同类型的变量），编译器会拒绝这样的代码：
 ````cpp
 auto x5 = { 1, 2, 3.0 };        //错误！无法推导std::initializer_list<T>中的T
 ````
 就像注释说的那样，在这种情况下类型推导将会失败，但是对我们来说认识到这里确实发生了两种类型推导是很重要的。一种是由于`auto`的使用：`x5`的类型不得不被推导。因为`x5`使用花括号的方式进行初始化，`x5`必须被推导为`std::initializer_list`。但是`std::initializer_list`是一个模板。`std::initializer_list<T>`会被某种类型`T`实例化，所以这意味着`T`也会被推导。 推导落入了这里发生的第二种类型推导——模板类型推导的范围。在这个例子中推导之所以失败，是因为在花括号中的值并不是同一种类型。
 
-对于花括号的处理是`auto`类型推导和模板类型推导唯一不同的地方。当使用`auto`声明的变量使用花括号的语法进行初始化的时候，会推导出`std::initializer_list<T>`的实例化，但是对于模板类型推导这样就行不通：
+对于花括号的处理是`auto`类型推导和模板类型推导唯一不同的地方。当使用`auto`声明的变量使用`=`+花括号的语法进行初始化的时候，会推导出`std::initializer_list<T>`的实例化，但是对于模板类型推导这样就行不通：
 ````cpp
 auto x = { 11, 23, 9 };         //x的类型是std::initializer_list<int>
 
@@ -169,5 +169,5 @@ resetV({ 1, 2, 3 });            //错误！不能推导{ 1, 2, 3 }的类型
 
 **请记住：**
 
-+ `auto`类型推导通常和模板类型推导相同，但是`auto`类型推导假定花括号初始化代表`std::initializer_list`，而模板类型推导不这样做
++ `auto`类型推导通常和模板类型推导相同，但是`auto`类型推导假定`=`+花括号初始化代表`std::initializer_list`，而模板类型推导不这样做
 + 在C++14中`auto`允许出现在函数返回值或者*lambda*函数形参中，但是它的工作机制是模板类型推导那一套方案，而不是`auto`类型推导