The place for the VB community to join our collective voice! See https://github.com/CommunityVB/Main for more info.
@DualBrain
I guess I'm confused as I see the article; is there something I'm missing?
if you go to: https://devblogs.microsoft.com/dotnet/
and start browsing the blog, you'll notice there's no news about VB unless you use the magnifying glass to search and type "VB"
However, this news
https://devblogs.microsoft.com/dotnet/whats-new-for-visual-basic-in-visual-studio-2022/
was visible on the blog and now doesn't come with all the other news anymore.
I joined the blog on November 8, 2021 and saw the news about Kathleen's VB, now if you don't look in the magnifying glass you won't find it on the blog.
I found it strange that this happened
Looks like there might be something taking place regarding language change...
The feature is called CallerArgumentExpression with the C# spec found at https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/caller-argument-expression
The VB specific activity can be found at dotnet/roslyn#54132
The TLDR of this is that Visual Studio 2022 v17.1 should see VB "16.9" being the default language version (it is currently "16.0").
For anyone interested about the process of getting changes done around "language changes" that will impact developers; take a moment to review:
Keep in mind that this a conversation among members of the Roslyn team about a change requested (initiated) by a manager. Don't get me wrong, I'm happy to see this type of thing taking place... just because some people think that it is a "small change" that most likely won't affect anyone, the policies are in place to help ensure/guarantee that things are looked at. When outsiders encounter this level of "push-back", there are complaints that the team is resisting change... but I don't see this as being the case. If you want to contribute something, you have to do so following the same level required by the team members. I just find the chain of events and conversation in this pull request enlightening and take some solace in the idea that we really do have people on the team doing their best to ensure we continue to have a high quality product that requires a consistent high-bar with regard to changes being made.
Right now, to do the same thing:
Imports System
Module Program
Sub Main(args As String())
Console.WriteLine("HELLO WORLD!")
End Sub
End Module
or more accurately...
Imports System
Module Program
Sub Main(args As String())
10:
Console.WriteLine("HELLO WORLD!")
End Sub
End Module
Imports System
10:
Console.WriteLine("HELLO WORLD!")
The reason why I include line numbers in the first example is to think about the following example:
10 PRINT "HELLO WORLD!"
20 X = X + 1
30 IF X > 10 THEN GOTO 50
40 GOTO 10
50 END
which would (theoretically, if Top-Level Code existed in VB) to:
Imports System
Dim x As Integer
10:
Console.WriteLine("HELLO WORLD!")
x=x+1
If x > 10 Then GoTo 50
GoTo 10
50:
End
or, depending on if you had certain Project options set appropriately...
10:
Console.WriteLine("HELLO WORLD!")
x=x+1
If x > 10 Then GoTo 50
GoTo 10
50:
End
For a really insane option, what about the following?
? "HELLO WORLD!"
What if, indeed...
AND... what if... and I do ask this in all seriousness... this were possible WITHOUT changing the VB compiler? It might just indeed be possible to support this with the tools that currently exist where (once available) all you would have to do is simply add a nuget reference.
Which then leads me to ask what would PRINT
(or ?
) do for different project types? In a Console
application it would output text to the, well, Console
. In a WinForms application, would it be equivalent to a Debug.Print
or for "logging"? In an ASP.NET type application, would it be for sending content to the browser (HTML)?
DISCLAIMER: This may be something that requires a team of people to participate in (ultimately) to accomplish.
I'm in the process of learning more about Roslyn (navigating through syntax trees) and in the process of exploring how I want to handle certain things I discovered that ?
is something that is specifically looked for. Just for giggles, tried the following code in a method:
? "HELLO WORLD!"
And the error one receives will be similar to "Expression statement is only allowed at the end of an interactive submission."
This statement, though, is completely recognized and parses correctly since it is legal in the interactive side of things and, at least to me, it's interesting to see entry.Kind = SyntaxKind.PrintStatement
.
This will make it a little more difficult (in some ways) to do what I'm wanting to do... however, it also makes it easy to detect (since it already can do so).
Point being that ?
is does (technically) exist in VB (Roslyn) but is only used (assumption) in limited scope (interactive")... (NOTE: It might not actually be used outside of the error checking, I'm making an assumption that the very limited interactive stuff in VS is using this; it might not be as it could still be using the old way* since we don't have VB scripting available to us.) I may explore this more in the future; but if anyone else knows any more details, please share.
After a long wait my fix to handling formatting _ ‘ is in the current release of Visual Studio 2022. I want the thank @CyrusNajmabadi and @SamHarwell for making it happen. This continues to give me hope to be able at add additional feature to VB by community in the future.
AWESOME!
This continues to give me hope to be able at add additional feature to VB by community in the future.
My view is that the answer has (all along) not been a (hard) "No!"... but rather the bar is pretty high in order to get a "Yes!". Also, "no plan" doesn't mean "nothing is going to happen"; or, more specifically, plans can and do change over the course of time. Changes are indeed taking place both within Roslyn as well as in .NET / Visual Studio / WinForms / etc. that DIRECTLY impact VB.
to answer your question about VB, I'm working on trying to make things more async, and to work on perf not causing blocking issues in it in the typing experience -- @CyrusNajmabadi
Can you take a moment to update about the work you were referring to when you posted this a while back?
?
for printing, even if it possible. In C#, we use cw+tab shortcut for Console.writeline snippent, which doesn't exist in VB, and there is an issue about that dotnet/roslyn#37049
<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>Console.WriteLine</Title>
<Author>M. Hmdy Ghanem</Author>
<Shortcut>cw</Shortcut>
</Header>
<Snippet>
<Code Language="VB">
<![CDATA[Console.WriteLine($msg$)]]>
</Code>
<Declarations>
<Object>
<ID>msg</ID>
<Type>System.String</Type>
<ToolTip>The message you want to write.</ToolTip>
<Default>"Hello"</Default>
</Object>
</Declarations>
</Snippet>
</CodeSnippet>
</CodeSnippets>
Console.WriteLine("Hello")
?
as a shortcut for the snippet, but didn't work as it is used to show the snippet context menu. It would be nice ;)
cwl
.
@CyrusNajmabadi
Does the visual basic specification and compiler, assert atomicity within "multi-part" block structures.
For example the ElseIf
in an If Then ... End If
block.
We have the following code (as is).
' statements 0
If someCondition = True Then
' statements 1
ElseIf someCondition = False Then
' statements 2
Else
' statements 3
End If
' statements 4
is transformed into
' statements 0
If someCondition = True Then
' statements 1
Else
' *** What prevents evaluate of someCondition being different from prior evaluation.
If someCondition = False Then
' statements 2
Else
' statements 3
End If
End If
' statements 4
Is someCondition
asserted to be atomic ( non-changing ) between each usage?
As from my knowledge the lowered form does not seem to have that "ambient property", or does the transformation production obtain that "ambient property" from the transformation of an ElseIf
statement.
If it doesn't would a copy of the value of "someConditon" into "tmp" prior to the If Block, and rename the usage of "someCondition" with on this block to "tmp". Gain that guarentee.
I think this is something to do with Side-Effects and/or Contract propagation.
Otherwise, if the variable you are testing is not a local variable but instead a property of a class... the class could literally return a different result each and every check.
Alternatively (I believe) this could be resolve by using Select Case
.
If it doesn't would a copy of the value of "someConditon" into "tmp" prior to the If Block, and rename the usage of "someCondition" with on this block to "tmp". Gain that guarentee.
This would only be true if the developer honored this restriction.
is predominantly is lowered to an
If ... Then` structure, so same suitable effect exists. In a "pure" single threaded non-eventing/interuptting evaluation it trivial and can be ignored. In a non-linear evaluation environment it does, so assisting the programmer to have awareness, or code-fix.
If
checking is completely within the context of the If
statements. So multi-threaded code shouldn't be an issue (in this example - which I feel is more common). In the event the value does change, there is a high possibility this was what the developer desired/intended. Now if we talk about properties... the value of the property is controlled by the object and one would have to wonder under what conditions that this would be an issue. In some circumstances, the value changing between the If
statements may actually be desired. There are also two very different Select Case
models (lowering)... as you said there is one that is basically a bunch of individual If
statements while the (ultimately) desired lowering would be the "jump list". To my knowledge, the "jump list" version would evaluate the value once and is significantly faster than and something I tend to try to setup for under normal conditions. If the desire is to make the variable unchanging, there are (of course) mechanisms in place to assist with that as well. But I don't think there is a "blanket" mechanism or even warning that would cover all the scenarios and my gut is telling me this would create more confusion than it would potentially address any sort of pitfall. In other words, I can't imagine how one would look at the code a know whether or not this might be a potential issue across all the possible scenarios that could exist. I could, of course, be missing something... so there is always that. ;-)