[Proposal] Introduce `Dim` tuple syntax, discards, and inline `Dim` for out variables

[Pac-Dessert1436]

Summary

VB.NET does not yet support Dim tuple deconstruction syntax, despite consistent community requests dating back to 2018 (see: dotnet/vblang#346). As of 2026, modern coding tools and third-party extensions have begun emulating this syntax, highlighting strong demand for first-class support.

This feature would bring VB.NET parity with modern tuple patterns, improve code brevity, and simplify common patterns like deconstruction, inline out variables, and value discards.

Proposed Syntax & Examples

1. Tuple Deconstruction with Dim (Type Inference & Explicit Typing)

Support direct tuple deconstruction using the Dim statement, with both inferred and explicit type support:

' Dim tuple syntax with local type inference
Dim (a, b) = (3, 5)

' Explicit type annotation for tuple elements
Dim (a As Integer, b As Integer) = (3, 5)

2. Discard Slots (Empty Deconstruction Slots)

Allow empty slots in tuple deconstruction to discard unused values (a common and useful pattern in modern .NET languages):

' Discard the first value; assign only the second and third elements
Dim (, a, b) = (3, 5, 7)
' Result: a = 5, b = 7; first value (3) is ignored

3. Inline Dim for C#'s out Variables

Simplify the usage of C#'s out parameters in VB.NET with inline Dim syntax (automatic type inference, no pre-declaration required):

Dim input = Console.ReadLine()

' Inline Dim for out variable - type is inferred automatically
If Integer.TryParse(input, Dim x) Then
    ' x is strongly typed as Integer
    Dim y = 3 * x - 2
    Console.WriteLine("x = {0}, y = {1}", x, y)
End If

' Discard the out variable entirely using an empty slot
If Integer.TryParse(input, ) Then Console.WriteLine("Input is a valid integer.")

Motivation & Benefits

1. Modernize VB.NET: Align with contemporary .NET language patterns for tuples and discards.
2. Reduce Boilerplate: Eliminate redundant variable declarations for out parameters and tuple unpacking.
3. Community Demand: Long-requested feature with widespread support from VB.NET developers.
4. Tooling Consistency: Match the behavior already being emulated by popular coding tools.

---

In conclusion, as both a C# and VB.NET developer, I strongly encourage the VB.NET language team to prioritize implementing this critical productivity feature. Many thanks for your consideration!

[paul1956]

While these are great feature none are critical for continued usage of VB.net but lack of support for newer .Net runtime API’s is. Look at System.JSON and how many important API’s are not accessible from VB.Net.

These need to either be fixed on the .Net side or better in VB.Net.

[Pac-Dessert1436]

While these are great feature none are critical for continued usage of VB.net but lack of support for newer .Net runtime API’s is. Look at System.JSON and how many important API’s are not accessible from VB.Net.

These need to either be fixed on the .Net side or better in VB.Net.

That's terrific. I'm pretty grateful to your insightful feedback! I can't agree more with the fact that VB.NET's compatibility with modern .NET runtime APIs - especially System.Text.Json - is a far more critical pain point than just missing syntax sugar like the Dim tuple syntax I just mentioned. While nicer syntax improves developer experience, being locked out of core JSON APIs directly blocks VB.NET from modern .NET ecosystems.
For this reason I fully support your call to fix these API access gaps, whether on the .NET runtime side or VB.NET compiler side. Let’s keep pushing for both: better language syntax and full parity with C# in accessing all modern .NET core libraries, so VB.NET can stay relevant in current development workflows.