The original wording of this question lacks objective design criteria, though I think the consensus is actually fairly settled on this particular issue (namely that unsigned bytes are much more useful than signed ones). The trouble with the question as-written was that there was no requirement to provide a consensus view—potential answerers could give whatever personal opinion they want, which is unhelpful and precisely why we try to require objective design criteria. I’ve edited the question to try to bring it on-topic.

The core of my question is still there, so I'm fine with the change. However, on that topic, I do not see why to exclude personal opinions if there is a good reason presented alongside. If there were a really obvious objective reason to choose one side, the topic would have been settled before things like IEEE-754. Simply, because it's a very central topic.

I agree that opinions are not a priori a problem, but we do want answers to be relatively authoritative. If people provide answers that are purely based on their own opinions, it is impossible to decide whether or not they are correct, short of treating voting like a popularity contest. Language design is not a popularity contest, it is a discipline of study, so requiring a certain level of evidence or authority helps to encourage more thoughtful and reasoned answers.

What is the signedness of a byte? Bytes are octets of ones and zeros, nothing more really. Arithmetic operations or arithmetic types can be signed or unsigned. This may seem pedantic, but the question as phrased doesn't make much sense to me. Also the part C++ has unsigned bytes (std::byte) is not true. std::byte has no arithmetic operations defined on it and is thus neither signed nor unsigned.

@chrysante TBH, I would have appreciated this comment as an answer. Nonetheless, the underlying type of std::byte is unsigned.

I guess I could make it an answer but it is really meant as a clarification. Because you could either mean "Should I use the numbers [0,255] or [-128,127]" to represent a byte?" or "My language shall support division for single bytes, should it be signed or unsigned division?" And yes, in the former sense std::byte is unsigned because std::byte{ -1 } doesn't compile.

This question feels really weird to me because every language I've used with a byte type has both. E.g., u8 and i8 in Rust, or byte and unsigned byte

@RydwolfPrograms the question is meant the other way round. It's type byte := i8 or type byte := u8? The language has both types already irrespective of the byte type.

"C++ has unsigned bytes (std::byte), but I've seen a lot of code using signed chars as bytes." Have you? In my experience, most code uses "plain" char, the signedness of which is implementation-defined. Which is an additional programming-language design approach, but maybe not a preferable one.

@RydwolfPrograms Java has only signed bytes, for example. It's regarded by many as a mistake.

The question seems to be putting the cart before the horse. You should consider first what your byte type represents. Is it indeed like C++'s std::byte, which represents only a collection of bits, to which signedness is irrelevant? Is it a character type, like C char? Or if instead it is a small numeric type then do you want it to be signed? (There are good arguments against general numeric types being unsigned.) And do you even need to choose? If you see usefulness for both signed and unsigned versions, then why can't you have both?

Whatever you choose to do, just don't make the same mistake as C where the char type has implementation defined signedness.

@PaŭloEbermann, Java has one unsigned integer type: 16-bit char.

why not just provide types equivalent to int8, uint8 and char? Let the programmer decide what they want.

@chrysante: It depends on what the language's equivalent of byte all1s = ~0; print(int(all1s)); does. If it prints -1, then bytes are signed. If it prints 255 (or some other positive number), then bytes are unsigned. If it produces an error because byte can't be converted to int, then "signedness" isn't meaningful.

@dan04 that's kind of a stretch, int(all1s) could perform a sign extension and uint(all1s) could perform a zero extension. How these conversions are defined doesn't say much about the byte type.

@MatheusMoreira: I wouldn't call what C did a "mistake". If an application only cares about storing values 0..127, having a type that treats values where the high bit is set as either 128..255 or -128..-1, whichever is more convenient, may allow it to be processed as efficiently on platforms which only support sign-extended loads as on platforms that don't support sign-extended loads. The mistake was using the same type to represent characters, small numbers, and memory bits.

@supercat: True. The correspondence between "character" and "byte" broke as soon as people wanted to represent Chinese or Japanese on a computer.