-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type suffix for Byte
and SByte
types
#213
Comments
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.
|
@Bill-McC, # is a type suffix for I'm happy with |
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
|
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. |
Ditto. Well, almost. I do use 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!) |
Would be nice to see them depreciated and eventually removed, freeing up their reuse in new syntax additions. |
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. |
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 |
@KathleenDollard I agree that just ' Is this an integer hex for decimal 27 or byte hex for decimal 1?
Dim value = &H1B The proposal was for Again, I code with |
@AnthonyDGreen Thanks for clarifying!!! We were bouncing between three issues when we reviewed this and over looked that. UB/SB solve the problem. |
@craigajohnson Could you ping #27. It's quite old so will be a while before it comes up for review otherwise. |
Note, if we do add this we're also need to update some assertions that state that visual basic doesn't support them. |
@AdamSpeight2008 that Visual Basic doesn't support what--what is "them" in your sentence? |
@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 writeCByte(-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 anInteger
) to theSByte
type but withOption Strict
for being stupid. C#, for example, doesn't forbid this implicit conversion. We should probably fixOption 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 andSB
for signed bytes. F# for example usesY
andUY
but that's not very intuitive. The reason we picked these is two fold:B
andUB
, or if we should prefer the CLS-compliant unsigned byte and put the extra character on the signed byte,B
andSB
.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
or255UB
. It seems like a harmless and natural extension to the language though.The text was updated successfully, but these errors were encountered: