Suffix for byte type

Topics: C# Language Design
Apr 13, 2014 at 6:59 AM
Byte type is used for colors(picture, graphics etc.)
Byte don't have own suffix so we sometimes write cast.
//if Color has float overload, 255 means 255.0f 
Color color = new Color((byte)255, (byte)127, (byte)0, (byte)255);

//byte suffix 'b', for example
Color color = new Color(255b, 127b, 0b, 255b);

//unimportant but we can
byte value = 1;
var value = 1b;
Do you think this suffix is necessary?
Apr 13, 2014 at 8:10 AM
Necessary? No. But I was looking for it couple of times as well...
Apr 13, 2014 at 5:13 PM
This should probably be added at the same time as the binary literals. Perhaps binary literals should even default to being byte (I can't imagine a lot of cases wherein someone wants to write more than 8 binary digits).
Apr 14, 2014 at 8:16 AM
I would vote for it. It would be useful for byte[] manual initialization. However, I'm not sure if such syntax might not clash with something.
Coordinator
May 4, 2014 at 1:55 PM
Hey all,

So, we added binary literals in VB last fall and got similar feedback from early testers. We did decide to add a suffix for byte for VB. We settled on SB (for signed byte) and UB (for unsigned byte). The reason it's not just B and SB is two-fold. One, the B suffix is ambiguous if you're writing in hexadecimal (what does 0xFFB mean?) and even if we had a solution for that, or another character than 'B' ('Y' was considered, F# uses this) no one could remember whether the default was signed or unsigned - .NET bytes are unsigned by default so it would make sense to pick B and SB but all the other suffixes are signed by default so it would be consistent with other type suffixes to pick B and UB. In the end we went for unambiguous SB and UB.

As for C#, another interesting detail is that C# also lacks a type suffix for 'short'. Would it be odd to skip that on or would we also ad S/US?

Anthony D. Green, Program Manager, Visual Basic & C# Languages Team
May 4, 2014 at 4:06 PM
I agree that you should add unambiguous suffixes to all available primitives, so, S/US should be replaced by SS/US.

Now, why not adding custom literals like in C++11? http://en.cppreference.com/w/cpp/language/user_literal

That way you can reimplement all suffixes as custom-literal ones (maybe requesting a "_" by default, like 253_UB).
May 4, 2014 at 6:15 PM
I am in for both byte and short suffixes with unambiguities, if this is going to be added (and given the desire for parity between VB and C# it seems likely).
However, as for the Ultrahead suggestion, I think s for short is enough - we are not going to switch to sl for (signed) long either.
May 4, 2014 at 10:24 PM
I would be strongly in favor of adding type suffixes for the byte, sbyte, short and ushort types in C# and agree with Anthony that the best ones to use would be: ub, sb, s and us respectively.
May 4, 2014 at 11:31 PM
vulpecula wrote:
I would be strongly in favor of adding type suffixes for the byte, sbyte, short and ushort types in C# and agree with Anthony that the best ones to use would be: ub, sb, s and us respectively.
I think I might be inclined to use ss rather than just s (and allow, but not require, si and sl), so as to make clear that the prefix means "signed short" rather than just "signed".
May 6, 2014 at 9:16 PM
ADGreen wrote:
As for C#, another interesting detail is that C# also lacks a type suffix for 'short'. Would it be odd to skip that on or would we also ad S/US?
A definite "yes please" to adding a suffix for shorts! Whether it should be S or something else should be considered carefully, though.

In case it influences you in either direction, I'll just remind anyone else who is old enough to have written in IBM S/360 assembler that we used an H suffix back in those days to denote 2-byte (i.e. short int) values, H standing for Halfword. If nothing else, it would get around the (admittedly small) "does this S mean Short or Signed?" confusion.
May 6, 2014 at 10:38 PM
I don't like "h" as a suffix for a signed halfword, since 10h would be prone to confusion with 0x10. I think sh might be an okay prefix for signed short, but that might make unsigned short seem a little indecisive (123uh).
May 8, 2014 at 5:16 PM
I don't see a way how s could be confused with signed. What would that mean? Would you expect 0xFFFFFFFFs to mean unchecked((int)0xFFFFFFFF)?
May 8, 2014 at 8:06 PM
JanKucera wrote:
I don't see a way how s could be confused with signed. What would that mean? Would you expect 0xFFFFFFFFs to mean unchecked((int)0xFFFFFFFF)?
If someone said "C# has been changed so that 0xFFFFFFFFs is a legitimate constant specification; what would you expect its type and value to be, and how confident would you be in that expectation?" I would be quite confident that it would be an expression of type System.Int32 whose value was -1.

Likewise if the expression had been 0xFFFFss, or 0xFFFFsh I would expect, with slightly less certainty, that the meaning was System.Int16, also with a value of -1.

Things would get rather murkier, however, with 0x0FFFFFFFFs, 0x0000FFFFs and 0xFFFFs. I would not think it unreasonable to define the first as an Int64 whose value was 4294967295, the second as an int32 whose value was 65535, and the third as an int whose value was -1 [in each case, the number would be interpreted as the shortest signed type sufficient to hold an integer value which, if sign-extended to arbitrary length, would end with the specified digits].

IMHO, when adding syntax features to a language, one should endeavor to avoid situations where someone who is generally familiar with the language but unfamiliar with the feature might plausibly guess that it means something other than what it actually does. Either forbid usage cases where more than one meaning would make sense [e.g. if a lone s means short, limit literals to four digits (outlawing the first two murky examples); if it means "signed", require that the literal contain exactly 16, 8, 4, or 2 digits [depending upon type] or make the syntax sufficiently unlike anything else that people who haven't seen it before will have no idea it means. Note that while I would disfavor my stated plausible interpretation of the "murky" literals in a language where the types of literals are semantically significant, it could be the most reasonable interpretation in a language which numeric literals have no type beyond what would be inferred from their value.
May 10, 2014 at 1:46 AM
Suffixes for bytes are a very good idea, removing the need for casts in some situations. UB/SB is a good compromise I think since B/SB is not possible. I'd add S/SS for shorts as well for consistency.
May 10, 2014 at 2:20 AM
christoph_hausner wrote:
Suffixes for bytes are a very good idea, removing the need for casts in some situations. UB/SB is a good compromise I think since B/SB is not possible. I'd add S/SS for shorts as well for consistency.
Do you mean us/ss?
May 15, 2014 at 1:17 AM
Edited May 15, 2014 at 1:17 AM
supercat wrote:
Do you mean us/ss?
Oops, what I actually meant was S/US.
May 15, 2014 at 1:40 PM
christoph_hausner wrote:
supercat wrote:
Do you mean us/ss?
Oops, what I actually meant was S/US.
What do you think of my reasons for disliking a lone S as a suffix?
May 15, 2014 at 7:24 PM
supercat wrote:
What do you think of my reasons for disliking a lone S as a suffix?
I think it's more important to keep the language as consistent as possible and that means S/US. As JanKucera said, I don't see why SS is supposed to be less confusing than a single S. Quite the contrary, actually, e.g. if someone wanted to see if there is a suffix for shorts he'd probably try "S" as suffix and not "SS".
May 15, 2014 at 7:49 PM
Edited May 15, 2014 at 7:49 PM
christoph_hausner wrote:
supercat wrote:
What do you think of my reasons for disliking a lone S as a suffix?
I think it's more important to keep the language as consistent as possible and that means S/US. As JanKucera said, I don't see why SS is supposed to be less confusing than a single S. Quite the contrary, actually, e.g. if someone wanted to see if there is a suffix for shorts he'd probably try "S" as suffix and not "SS".
A person might try that, and if the error message said The suffix 's' is invalid; the suffix for Int16 is 'ss', I think the person would pretty quickly figure out what to do, at least in the expected case where the person wanted a short.

In some languages (e.g. Java), a hex literal like 0xFFFFFFFF is a perfectly legitimate representation for a 32-bit signed integer quantity -1. When porting code from such languages, it would be useful to allow the use of sl, si, ss, or sb suffix for such purpose, at least on a literal containing the exact number of digits required for the type (use of a single s following such an 8-digit hex literal could yield The suffix 's' is invalid; the suffix for an Int32 hex literal is 'si'). Otherwise, if one is e.g. porting Java code which makes use of a hex literal like 0xDEADBEEF, would there be any nice way of representing that in C# without requiring an unchecked numeric context or having the code be specific to literals whose first digit was eight or higher? If I saw something like (int)((0xDEADBEEF ^ 0x80000000)-0x80000000L I could probably figure out that its purpose was to compute the value that 0xDEADBEEFsi would represent.
Developer
May 15, 2014 at 10:22 PM
Edited May 15, 2014 at 10:29 PM
If someone said "C# has been changed so that 0xFFFFFFFFs is a legitimate constant specification; what would you expect its type and value to be, and how confident would you be in that expectation?"
I would have no idea. When explained that it means 'signed' I would say "the C# language design team should stop drinking while coming up with integer suffixes." ;)

I see no problem with s/us.
May 15, 2014 at 10:37 PM
Edited May 15, 2014 at 10:42 PM
angocke wrote:
I would have no idea. When explained that it means 'signed' I would say "the C# language design team should stop drinking while coming up with integer suffixes." ;)
How would you suggest writing the value which in Java would be written 0xDEADBEEF, in such a way as to make its hex representation clear, and allow the value to be recognized as a compile-time constant, without requiring use of an unchecked numeric context? I would think 0xDEADBEEFsi, if allowed, would be clearer than anything else I can think of. Can you think of any presently-legal notation that would come close?

Also, given that short and byte are both shorter than the type to which most arithmetic expressions will get promoted, I don't think the same imperatives that would lead to int being signed by default are nearly as applicable to short. The reason that even positive integer quantities are signed by default is that operations between Int32 and UInt32 yield a UInt32 result, but that rationale is not applicable to types shorter than int. I would guess that Int16 is used somewhat more often than UInt16, but the usage ratio is nowhere near that of Int32 versus UInt32.
Dec 6, 2016 at 3:43 PM
I specifically registered to CodePlex to upvote a byte literal! Please make this work:
//byte suffix 'b', for example
Color color = new Color(255b, 127b, 0b, 255b);

//unimportant but we can
byte value = 1;
var value = 1b;
Dec 8, 2016 at 2:31 PM
Good for you, though I would suggest filing that at https://github.com/dotnet/roslyn/issues where the discussions have moved.