> So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`?

I don't think it begs the question, but it does raise one!

Nit: "begs the question" means "raises the question" in many contemporary colloquial contexts. It can _also_ refer to a type of logical fallacy in philosophical contexts.

The phrase can be confusing because of its overloaded definitions, so it's best to avoid it. But if you understood what someone meant when they used it, then... you understood it's meaning.

Remember to treat the study of language descriptively rather than prescriptively!

https://en.wiktionary.org/wiki/beg_the_question

Well there's the so-called usual arithmetic conversions that will basically convert every uint16_t to an unsigned int. The C and C++ languages do a silent conversion on your back anyways so you might as well make it explicit.

Usually promotions are to signed int, not unsigned. (With some exceptions. But every uint16_t value can fit in int.)

Unless int is 16-bit. Code like this is potentially UB; you should use int32_t as the target.

You should use long, and don't ever assume it's exactly 32-bits. The fixed size types are often an overused crutch that hampers future portability.

There are no mainstream 16-bit int platforms. It's fine to know what you target.

The promotions that are really surprising are from uint64_t bitfields to int (because it's based on value representability).

  struct {
    uint64_t a : 33,
             b : 15;
  } s;
  // s.b gets "promoted" to int, s.a does not

A well-configured C++ compiler will error-out on such a silent conversion.

The C++ compiler is required to perform this silent conversion according to the standard: https://en.cppreference.com/w/cpp/language/implicit_conversi...