You can replace the last line with:

morph->search_list.emplace_back( morph->dictionary.size() - 1, 0, 0, 0 );

Thus the object is created not through brace initialization which does not allow narrowing conversion.

The narrowing conversion is from the return value of the call to size which returns std::size_t which is unsigned.

For why size() - 1 is not converted to a signed value see: C++ Implicit Conversion (Signed + Unsigned)

The operands to your addition expression are undergoing integral promotion.

In particular, arithmetic operators do not accept types smaller than int as arguments, and integral promotions are automatically applied after lvalue-to-rvalue conversion, if applicable. This conversion always preserves the value.

Your a and b are being promoted to int or unsigned int, added, and then converted back down to unsigned char.

If the conversion is expected program behavior (from your point of view as the designer), you can explicitly cast it to the type you want. An explicit cast is not a narrowing conversion. An implicit cast is. So if we change the implicit cast to an explicit cast, the program is no longer ill-formed.

T t = { static_cast<unsigned char>(a + b) };

Both are narrowing conversions in the sense of the standard, because not all values of int fit into uint32_t, already because of the sign.

However, normally narrowing conversions are simply allowed as explicit as well as implicit conversions. This has always been the case since C (or longer).

Unfortunately a narrowing conversion is usually a defect in the code and therefore it is a problem that these conversions can happen implicitly or even explicitly without some clear indication that the conversion is intended.

With C++11 adding new meaning to initialization with braces, it was decided to make narrowing conversions ill-formed if the initialization uses braces. Except for old aggregate initialization cases this was a non-breaking change and so was more reasonable than e.g. making all narrowing conversions in all contexts ill-formed, which would seriously break most non-trivial programs.

This is actually a good reason to generally prefer initialization with braces over parentheses. It is much easier to create a bug or vulnerability if narrowing conversions are not diagnosed, although that diagnosis can also come from a compiler warning or external lint tool as well.

Unfortunately there are also arguments against generally preferring initialization with braces, so it isn't that easy. I don't intend to list all pros and cons. There should be sufficient discussion on that topic on this site and elsewhere.

I ran into this breaking change when I used GCC. The compiler printed an error for code like this:

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {i & 0xFFFFFFFF, i >> 32};
}

In function void foo(const long long unsigned int&):

error: narrowing conversion of (((long long unsigned int)i) & 4294967295ull) from long long unsigned int to unsigned int inside { }

error: narrowing conversion of (((long long unsigned int)i) >> 32) from long long unsigned int to unsigned int inside { }

Fortunately, the error messages were straightforward and the fix was simple:

void foo(const unsigned long long &i)
{
    unsigned int a[2] = {static_cast<unsigned int>(i & 0xFFFFFFFF),
            static_cast<unsigned int>(i >> 32)};
}

The code was in an external library, with only two occurrences in one file. I don't think the breaking change will affect much code. Novices might get confused, though.

Though both int and size_t may be the same bit-wdth they differ in that the int is a signed value, so it's range (for, e.g. 16-bit) would be [-32768..+32767] while the same hypothetical 16-bit size_t would be in [0..65535] range. That conversion from a signed value to an unsigned is what is being reported as "narrowing".

A fix (in this case) is based on knowledge that your values are indeed unsigned so you can "tell" the compiler as much with an explicit conversion:

auto y{static_cast<size_t>(x << z)};

If practical do:

enum FunctionType
{
    NORMAL   = 0, 
    RANGE    = 1
};

typedef struct TableEntry
{
    FunctionType value;
    const char *label;
} TableEntry;


TableEntry functionTypes[] = 
{
    {NORMAL,   "NORMAL"},
    {RANGE, "RANGE"}
};

Otherwise, change the type in the struct to int, or explicitly base the enumeration on the same type as in the struct.

Btw., I the think g++ warning is unfounded and wrong, since the original code is valid C++03. Correction: As I understand it now, the diagnostic is correct, and this is a breaking change in C++11. I just couldn't believe it.

About the naming convention: those all uppercase identifiers are good for Java programmers (who are used to that convention), but in C++ they increase the chances of inadvertent text substitution. There are also the aesthetic considerations. Much win in reserving all uppercase for macros.

When you declare a variable as char, it's implementation-dependent whether it's signed or unsigned. If you need to be able to store negative values, you should declare it signed explicitly, rather than relying on the implementation-defined default.

signed char c[1] = { -108 };