Why should I prefer the "explicitly typed initializer" idiom over explicitly giving the type

Following the C++ Standard:

§ 8.5 Initializers [dcl.init]

15. The initialization that occurs in the form

    T x = a;
    

    as well as in argument passing, function return, throwing an exception (15.1), handling an exception (15.3), and aggregate member initialization (8.5.1) is called copy-initialization.

I can think of the example given in the book:

auto x = features(w)[5];

as the one that represents any form of copy-initialization with auto / template type (deduced type in general), just like:

template <typename A>
void foo(A x) {}

foo(features(w)[5]);

as well as:

auto bar()
{
    return features(w)[5];
}

as well as:

auto lambda = [] (auto x) {};
lambda(features(w)[5]);

So the point is, we cannot always just "move type T from static_cast<T> to the left-hand side of assignment".

Instead, in any of the above examples we need to explicitly specify the desired type rather than allowing compiler deduce one on its own, if the latter can lead to undefined behavior:

Respectively to my examples that would be:

/*1*/ foo(static_cast<bool>(features(w)[5]));

/*2*/ return static_cast<bool>(features(w)[5]);

/*3*/ lambda(static_cast<bool>(features(w)[5]));

As such, using static_cast<T> is an elegant way of forcing a desired type, which alternatively can be expressed by explicit contructor call:

foo(bool{features(w)[5]});

---

To summarize, I don't think the book says:

Whenever you want to force the type of a variable, use auto x = static_cast<T>(y); instead of T x{y};.

To me it sounds more like a word of warning:

The type inference with auto is cool, but may end up with undefined behavior if used unwisely.

And as a solution for the scenarios involving type deduction, the following is proposed:

If the compiler's regular type-deduction mechanism is not what you want, use static_cast<T>(y).

---

UPDATE

And answering your updated question, which of the below initializations should one prefer:

bool priority = features(w)[5];

auto priority = static_cast<bool>(features(w)[5]);

auto priority = bool(features(w)[5]);

auto priority = bool{features(w)[5]};

Scenario 1

First, imagine the std::vector<bool>::reference is not implicitly convertible to bool:

struct BoolReference
{
    explicit operator bool() { /*...*/ }
};

Now, the bool priority = features(w)[5]; will not compile, as it is not an explicit boolean context. The others will work fine (as long as the operator bool() is accessible).

Scenario 2

Secondly, let's assume the std::vector<bool>::reference is implemented in an old fashion, and although the conversion operator is not explicit, it returns int instead:

struct BoolReference
{
    operator int() { /*...*/ }
};

The change in signature turns off the auto priority = bool{features(w)[5]}; initialization, as using {} prevents the narrowing (which converting an int to bool is).

Scenario 3

Thirdly, what if we were talking not about bool at all, but about some user-defined type, that, to our surprise, declares explicit constructor:

struct MyBool
{
    explicit MyBool(bool b) {}
};

Surprisingly, once again the MyBool priority = features(w)[5]; initialization will not compile, as the copy-initialization syntax requires non-explicit constructor. Others will work though.

Personal attitude

If I were to choose one initialization from the listed four candidates, I would go with:

auto priority = bool{features(w)[5]};

because it introduces an explicit boolean context (which is fine in case we want to assign this value to boolean variable) and prevents narrowing (in case of other types, not-easily-convertible-to-bool), so that when an error/warning is triggered, we can diagnose what features(w)[5] really is.

---

UPDATE 2

I have recently watched Herb Sutter's speech from CppCon 2014 titled Back to the Basics! Essentials of Modern C++ Style, where he presents some points on why should one prefer the explicit type initializer of auto x = T{y}; form (though it is not the same as with auto x = static_cast<T>(y), so not all arguments apply) over T x{y};, which are:

1. auto variables must always be initialized. That is, you can't write auto a;, just like you can write error-prone int a;

2. The modern C++ style prefers the type on the right side, just like in:

   a) Literals:

   auto f = 3.14f;
   //           ^ float
   

   b) User-defined literals:

   auto s = "foo"s;
   //            ^ std::string
   

   c) Function declarations:

   auto func(double) -> int;
   

   d) Named lambdas:

   auto func = [=] (double) {};
   

   e) Aliases:

   using dict = set<string>;
   

   f) Template aliases:

   template <class T>
   using myvec = vector<T, myalloc>;
   

   so as such, adding one more:

   auto x = T{y};
   

   is consistent with the style where we have name on the left side, and type with initializer on the right side, what can be briefly described as:

   <category> name = <type> <initializer>;
   

3. With copy-elision and non-explicit copy/move constructors it has zero-cost compared to T x{y} syntax.

4. It is more explicit when there are subtle differences between the types:

    unique_ptr<Base> p = make_unique<Derived>(); // subtle difference
   
    auto p = unique_ptr<Base>{make_unique<Derived>()}; // explicit and clear
   

5. {} guarantees no implicit conversions and no narrowing.

But he also mentions some drawbacks of the auto x = T{} form in general, which has already been described in this post:

1. Even though the compiler can elide the right-hand side's temporary, it requires an accessible, non-deleted and non-explicit copy-constructor:

    auto x = std::atomic<int>{}; // fails to compile, copy constructor deleted
   

2. If the elision is not enabled (e.g. -fno-elide-constructors), then moving non-movable types results in expensive copy:

    auto a = std::array<int,50>{};
   

I don't have the book in front of me, so I can't tell if there's more context.

But to answer your question, no, using auto+static_cast in this particular example is not a good solution. It violates another guideline (one for which I've never seen any exceptions justified):

• Use the weakest cast/conversion possible.

Unnecessarily strong casts subvert the type system and prevent the compiler from generating diagnostic messages in case a change occurs elsewhere in the program that affects the conversion in an incompatible way. (action at a distance, the boogey-man of maintenance programming)

Here the static_cast is unnecessarily strong. An implicit conversion will do just fine. So avoid the cast.

Context from the book:

Though std::vector<bool> conceptually holds bools, operator[] for std::vector<bool> doesn’t return a reference to an element of the container (which is what std::vector::operator[] returns for every type except bool). Instead, it returns an object of type std::vector<bool>::reference (a class nested inside std::vector<bool>).

There is no advantage, it is more error prevention, when you using auto with external library.

I think, this is the main idea of such idiom. You should be explicit and force auto to behave correctly.

BTW, here the nice article on GotW about auto.