vblang
vblang copied to clipboard
dotnet
[Proposal]: VB New Feature Unchecked math
This is to open a "Feature Specification" following the process "roslyn/docs/contributing/Developing a Language Feature.md" for PR VB Prototype "Checked expressions" dotnet/roslyn#41104 done by @AdamSpeight2008 and closed by @jaredpar for not following the process above. This is not to endorse or comment on that implementation but to start again and follow the process.
- A description of the feature (including any syntax changes involved) A new Keyword is added to Visual Basic Unchecked
The Unchecked keyword is used to suppress overflow-checking for integral-type arithmetic operations and conversions during compilation and run-time.
In an unchecked context, if an expression produces a value that is outside the range of the destination type, the overflow is not flagged. For example, because the calculation in the first example line is performed in an unchecked context, the fact that the result is too large for an integer is ignored, and int1 is assigned the value Integer.MinValue.
If the Unchecked Keyword is removed line 2 below, a compilation error occurs. The overflow can be detected at compile time because all the terms of the expression are constants.
Dim int1 as Integer = Unchecked (Integer.Max + 1) ' No compiler error
Dim int2 as Integer = Integer.Max + 1 ' Compiler error
This feature also provides an Unchecked Override for all mathematical operations that could cause Overflow done inside the function. so they don't throw math exceptions.
Private MaxUInteger As Uinteger= UInteger.MaxValue
' Stuff
Assert.Equal(UInteger.MinValue, Unchecked (MaxUInteger + CUInt(1)))
Assert.Throws(Of OverflowException)(Function() As UInteger
Return MaxUInteger + CUInt(1)
End Function)
- Discussions about impacted areas, such as overload resolution and type inference. Think through the major areas of the language specification while determine the potential impacts
Since the overload only happens within the Unchecked function it should not effect overload resolution and type inference. One issue is the new Keyword Unchecked if someone were using Unchecked as a variable name. This was the same issue for NameOf and should be handled the same way.
- Proposed changes to the API surface area.
I don't think this applies but the existing BoundExpression already has support for checked / unchecked expressions. There is an additional use of the Unchecked Keyword in For loops that should be looked into at the same time.
Hi @gafter ,
Did you know dotnet/vblang is graveyard ? No contribution ever response any issue here, or you just want to exile his issue from dotnet/roslyn ?
What will be the answer of Dim int1 as Integer = Unchecked (Integer.Max + 1) ' No compiler error Integer.Min?
@tverweij Yes.@KathleenDollard @gafter The instruction left when a prototype PR was submitted against Roslyn and closed by @jaredpar was to fill out a Proposal at dotnet/roslyn. As @RevensofT said no one is responding to anything on dotnet/vbLang.
@RevensofT the Roslyn project does not consider language changes not previously approved through their language design teams and vetted in their respective language repos.
does not consider language changes not previously approved through their language design teams
@Gafter: LOL 🥇 - What language design team?
their language design teams
@gafter: Does the VB language design team still exist? I haven't seen new VB language design meeting notes for 1 year and 2 months.
@gafter: Does the VB language design team still exist? I haven't seen new VB language design meeting notes for 1 year and 2 months.
That particular meeting seems to have been a one-off about pattern matching. The one before that was 6 months earlier, @Nukepayload2 .
Compare this with the pace of the C# language design team meetings: once or twice a week, and there already have been 7 meetings (based on the notes this year alone.
@gafter Where is the "respective language repos" for VB if not dotnet/roslyn where all the VB code exists and where this proposal was originally posted.
Not only they are taking proposed features from VB to C#, but worst Anthony D Green's title is now a former VB.MET PM! They are literally shutting down VB.NET!! This may be a good news, since the biggest obstacle to fork VB.NET with a new vision is the inconsistency with the original VB.NET language updates. If they call VB.NET TOD, we can give it a new life with all features we want.
@VBAndCs @AnthonyDGreen's status also mentioned Ex-MSFT which indicates that he left Microsoft.
But @gafter there are still 2 questions to you open. (Also to @KathleenDollard and @AnthonyDGreen)
-
Where is the VB Team - and when will they have any meeting? Because if there is no VB team or if they do not have any meetings, nothing will ever be approved. And that would mean that we are wasting our time here.
-
When (If) something gets approved, where can we find the rules / guidelines for the implementations? Because if we don't have them, nothing will ever be allowed to be merged. And that would also mean that we are wasting our time here.
The is a Prototype on my Github page for Expressions and I am working on Statements. Would love some review I did not have a lot of guidance.
@KathleenDollard @CyrusNajmabadi Looking for Champion to take this issue to VBLang LDM. It has been sitting here for 8 months. It is possible to do this as a nonbreaking change, if that is a concern as opposed to the way NameOf was done if that is an issue.
Solutions today are to move all the code dealing with unchecked math to C# (something like Hash where all the work in in C# and you just get a value back after all the math is done) or creating a new VB Project and put all Unchecked math in that project but that means that all math in that project is Unchecked and that probably is not what anyone wants.
I personally don't think this is valuable enough as a language feature. I think you can already enable/disable checked on an assembly level. @KathleenDollard not sure if you (or another member) would want to pick this up.
It has been sitting here for 8 months.
note: length of time really isn't part of any decision making. We have C# lang proposals that have been around for many years. It really comes down to if anyone thinks this fits the language and really would want to champion this for a future version.
@CyrusNajmabadi
Purely out of curiosity:
- What are the criteria for a language feature to be valuable enough / fits the language? Nothing seems to have satisfied such criteria for the past few years.
- How many people can champion something for a future version of VB?
- Of those, how many have been full-time VB programmers for any length of time, such that their experience is appropriate in addressing what is or is not fit for the language?
I think you can already enable/disable checked on an assembly level.
I was preparing a long story for this. But I could see it would just be TL;DR.
While it's niche, if the PR is already there, then there is definite case for adding this support.
If even I stumbled on a use for it, I'm sure there must be plenty of others.
For various reasons, I recently needed to embed the source code for the Blake2 hashing algorithm into a VB project that I inherited. This involved translating it from C#. And of course it needs unchecked math to work. Fortunately for me, the library I'm working on doesn't actually do any other math (it's a primitive document management library plugin for an ERP system), so I could get away with going unchecked on the whole assembly, but it made me feel dirty.
I personally don't think this is valuable enough as a language feature. I think you can already enable/disable checked on an assembly level.
Says the someone who is all excited about https://github.com/dotnet/csharplang/issues/2951. I think you can already concatenate const string on the operator level (known as "plus-sign" IIRC). But no matter, "It's implemented in a feature branch and will very likely be in C# 10." Enjoy!
I was preparing a long story for this. But I could see it would just be TL;DR.
I've encountered issues when trying to override GetHashCode in VB.NET. The answers to this SO question show some of the necessary convoluted workarounds because VB.NET doesn't have unchecked support.
Admittedly, GetHashCode implementation is a hard problem in any language; AFAICT this is one of the goals of record types in C# 9. But VB.NET isn't getting those either, so easing the pain of GetHashCode implementation is a big win specifically for VB.NET.
@CyrusNajmabadi
(I apologize in advance if my tone is a little harsh. There is nothing personal here, just a lot of pent-up frustration.)
You recommend in this comment that if someone wants to push for a particular feature, they need to convince an LDM member to champion it.
There are a few problems with this strategy:
- I think it reasonable to assume you meet -- or otherwise communicate -- with other LDM members quite frequently, perhaps even daily; so you obviously know who they are, and can interact with them. But nobody outside the LDM seems to possess of this information. How is the VB community to reach any member of the LDM? The standard channels (issues on the VB lang repo, Developer Community, posts on .NET blogs) don't seem to provide any response, and don't appear to have resulted in any noticeable changes in the language. (And if there have been such changes, where have they been documented? Or even mentioned?) I am not suggesting that the contact info of LDM members needs to be publicly available; they are individuals entitled to their privacy and peace of mind. But the problem still remains -- there's no way for users to communicate their needs to the LDM members.
- This is a more significant problem for VB features. Presumably, there are LDM members who have no experience in actually writing VB, and as such might not be appropriate to judge whether a given feature fits in to / adds value to the language. Finding LDM members who have VB experience is akin to finding a needle in an invisible haystack.
I point this out not to blame anyone, or rage uselessly at the universe, but in the hope that perhaps I might strike a chord somewhere which will point the way to a solution.
Comparing local unsigned math
Dim x += 1
To calling a separate module (assembly level) with
Dim x = Add(x , 1)
The time for 10,000,000 loops is shown in the last column below when running a simple For loop. Using a full unsigned math library is much worse.
What are the criteria for a language feature to be valuable enough / fits the language?
Someone on the VB ldm would have to champion it. To do that, they have to think it would be a good fit and worth doing.
Of those, how many have been full-time VB programmers for any length of time, such that their experience is appropriate in addressing what is or is not fit for the language?
I don't know the count with that description. i don't know what it means to be a "full time vb programmer". Does that mean only VB? Or treating VB as a first class language they're using?
FWIW, i work in VB practically every day. I think i've personally wanted unchecked for VB once. So it's pretty low on my list of things i about. Sorry :-/
Says the someone who is all excited about dotnet/csharplang#2951. I think you can already concatenate const string on the operator level (known as "plus-sign" IIRC). But no matter, "It's implemented in a feature branch and will very likely be in C# 10." Enjoy!
I'm not sure what you mean by that. I only made a few posts on that issue, explaining the feature and teh process around getting it into the language.
I've encountered issues when trying to override GetHashCode in VB.NET.
Could you give some of the issues? For VB i would expect to just use HashCode.Combine here.
How is the VB community to reach any member of the LDM?
I think the only way would be to create issues here. It's the same way for C# as well.
but in the hope that perhaps I might strike a chord somewhere which will point the way to a solution.
I'll raise this with some of them to see if there's anything they want to post on this topic (or the metatopic).
Thanks for taking the time to respond here.
Could you give some of the issues? For VB i would expect to just use HashCode.Combine here.
I was programming on .NET Framework at the time, which doesn't have HashCode.Combine. The problem is that GetHashCode returns an Integer, but the calculations needed for GetHashCode frequently overflow Integer, and often Long as well.
Of those, how many have been full-time VB programmers for any length of time, such that their experience is appropriate in addressing what is or is not fit for the language?
I don't know the count with that description. i don't know what it means to be a "full time vb programmer". Does that mean only VB? Or treating VB as a first class language they're using?
I realize that's an unclear or limiting description. I meant to exclude someone who took an hour or two to write a toy project in VB, and feels that experience qualifies them to determine what fits and adds value to the language. I understand there is a tendency for C# programmers, dismissive of VB, to do so without sufficient experience in VB.
The VB LDM is not currently active because we are going to hold .NET 5 (Core) and .NET Framework the same. We are not adding language features to any language on the .NET Framework.
@KathleenDollard As I read your statement it would seem you are not adding any language features to C#, F# or VB. Did you mean you are not adding any Language Features to VB that require .NET 5 (Core) functionality and would not run on Framework? If so, this proposal and almost all the ones currently on VB Lang fit that requirement since they all predate .NET 5, and they run on both Framework and .NET. If you are saying something else please clarify.