Type suffix for `Byte` and `SByte` types

[AnthonyDGreen]

Today in VB all the integral literal types have a type suffix (S, US, I, UI, L, UL). There isn't one for byte, which is mostly fine, but it's still incomplete. And for the Option Strict crowd this forces them to write CByte(-1). We talked about how to change the language to avoid this error but after some thought I concluded that the error was not in the language for implicitly converting -1 (implicitly an Integer) to the SByte type but with Option Strict for being stupid. C#, for example, doesn't forbid this implicit conversion. We should probably fix Option Strict to not report an error for this conversion but that's orthogonal to whether there's a native syntax for 8-bit integer types in the language.

All that being said, we talked it over in the LDM some time ago and decided to just add suffix characters for these two types. After much debate we settled on UB for unsigned bytes and SB for signed bytes. F# for example uses Y and UY but that's not very intuitive. The reason we picked these is two fold:

1. Because all of the other integral types are signed as standard (CLS-compliant) and use an extra character for the unsigned types we weren't sure if we should go for consistency and use B and UB, or if we should prefer the CLS-compliant unsigned byte and put the extra character on the signed byte, B and SB.
2. B is a valid digit character in the hexadecimal base. We could just restrict these characters to decimal but hexadecimal byte literals seem like an awfully common use case of the byte type.

I guess the counter argument would be that since bytes already take up so few characters adding two more to the end starts to really obscure their value, e.g. &HFFUB or 255UB. It seems like a harmless and natural extension to the language though.

[Bill-McC]

UB seems fine. I think I'd prefer tagging, eg 255#Byte, &HFF#Byte, etc. The # would allow the display of a filtered intellisense list.

[reduckted]

@Bill-McC, # is a type suffix for Double, so that wouldn't work very well.

I'm happy with UB and SB, but isn't this a duplicate of #111?

[Bill-McC]

Good catch. I haven’t used the identifier suffixes in years and years. I know just because it is a legacy thing doesn’t give an excuse to change it, BUT, we do have the strange cases such as : Dim x = 1.0# Dim x = 1.0R Dim x# = 1.0R Dim x# = 1.0# And then oddities like: Dim x = 1.0R x# = 1.1 The IDE will try to remove the # on the variable identifier where it is not it’s original declaring, but will allow it even if that was not . And then we have syntax like : x# = 1.0! Perfectly legal in strictest sense. To me they are all things that make VB harder for me to use, not easier. If I have to stop and look something up, then the saving of keystrokes has cost me far more time. As more and more people program in other languages, having to remember these nuances, having so much duplication and overlap rather than have an easy approachable language, diminishes reasons to stick or go back to using VB. I would much prefer the language to use words and say exactly what it is. I think just like how the IDE will remove the # from x# = 1.0, it could also auto suggest #Double where literals are used, or even have #Double as the default for # without causing any breaking change. No doubt adding UB to the list is the easiest path, and really it does no more damage than that already done. But I do question if it is really the spirit of VB as an approachable language. It’s just a dozen literal type characters and half a dozen identifier type characters

[paul1956]

I hate, haven't used and don't recommend any of these suffixes because as was said I just have to look them up and Google/Bing aren't good at looking up #. What about a code fix for existing code and autocorrect for new code for people that don't like to type. maybe the formatter should just fix this on load. I found if funny that there is a change request for C# to replace several symbols with words (&& with And...) I almost replied just use VB. This is making VB more C# like and not in a good way. The beauty of VB is any programmer can read the code and intent is very clear without having to look stuff up.

[reduckted]

I hate, haven't used and don't recommend any of these suffixes

Ditto. Well, almost. I do use # sometimes (only after the literal value) because it's stuck in my muscle-memory from VB6 days. Maybe I need to write an analyzer to enforce R instead of #.

But regardless, it's part of the language, so it won't be going anywhere (although there are a number of legacy things I'd love to see die!)

[Echo-8-ERA]

Would be nice to see them depreciated and eventually removed, freeing up their reuse in new syntax additions.

[KathleenDollard]

I have some concern about &B at the start of a number meaning binary and B at the end meaning Byte.

I don't know what else we would use, but when this was proposed binary literals ($B) weren't a thing.

I do not know what other letter we would use for Byte. No other prefixing character is also a suffix.

[craigajohnson]

While you are considering this, could we also please consider the GUID literal proposal? This would be particularly useful when decorating with attributes and not having to wrap the literal as a string and convert. #27

[AnthonyDGreen]

@KathleenDollard I agree that just B would be wrong. It wouldn't work for hex:

' Is this an integer hex for decimal 27 or byte hex for decimal 1?
Dim value = &H1B

The proposal was for SB for signed-byte and UB for unsigned-byte to avoid that problem and others. They were originally discussed when &B binary literals were first discussed/prototyped/previewed (pre-VS2015 RTM) but not when binary literals were finally released (VS2017).

Again, I code with Strict Off and am fine with implicitly converting integer literals to Byte, this is only something for the crowd that likes to be extra explicit about literal data types but finds CByte(255) too verbose.