vblang

Visual Basic .NET Language Design

Welcome to the official repo for Visual Basic .NET language design.

• Full Language Specification: Markdown
• List of proposals can be found in the proposals folder.
• Archives of notes from design meetings, etc., can be found in the meetings folder.

If you discover bugs or deficiencies in the above, please leave an issue to raise them, or even better: a pull request to fix them.

For new feature proposals, however, please raise them for discussion, and only submit a proposal as a pull request if invited to do so by a member of the Language Design Team (a \”champion\”).

Discussion

Discussion pertaining to language features takes place in the form of issues in this repo, under the Discussion label.

If you want to suggest a feature, discuss current design notes or proposals, etc., please open a new issue, and it will be tagged Discussion.

GitHub is not ideal for discussions, but it is beneficial to have language features discussed nearby to where the design artifacts are. Comment threads that are short and stay on topic are much more likely to be read. If you leave comment number fifty, chances are that only a few people will read it. To make discussions easier to navigate and benefit from, please observe a few rules of thumb:

• Discussion should be relevant to Visual Basic .NET language design. Issues that are not will be summarily closed.
• Choose a descriptive title for the issue, that clearly communicates the scope of discussion.
• Stick to the topic of the issue title. If a comment is tangential, start a new issue and link back.
• If a comment goes into detail on a subtopic, also consider starting a new issue and linking back.
• Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment?

Design Process

Visual Basic .NET is designed by the Visual Basic .NET Language Design Team (LDT).

1. To submit, support, and discuss ideas please use the Discussion label.

2. Ideas that the LDT feel could potentially make it into the language should be turned into proposals, based on this template, either by members of the LDT or by community members by invitation from the LDT. The lifetime of a proposal is described in proposals/README.md. A good proposal should:

   • Fit with the general theme and aesthetic of the language.
   • Not introduce subtly alternate syntax for existing features.
   • Add a lot of value for a clear set of users.
   • Not add significantly to the complexity of the language, especially for new users.

3. A prototype owner (who may or may not be proposal owner) should implement a prototype in their own fork of the Roslyn repo and share it with the design team and community for feedback. A prototype must meet the following bar:

   • Parsing (if applicable) should be resilient to experimentation–typing should not cause crashes.
   • Include minimal tests demonstrating the feature at work end-to-end.
   • Include minimal IDE support (keyword coloring, formatting, completion).

4. Once a prototype has proven out the proposal and the proposal has been approved-in-principle by the design team, a feature owner (who may or may not be proposal or prototype owner(s)) implemented in a feature branch of the Roslyn repo. The bar for implementation quality can be found here.

5. Design changes during the proposal or feature implementation phase should be fed back into the original proposal as a PR describing the nature of the change and the rationale.

6. A PR should be submitted amending the formal language specification with the new feature or behavior.

7. Once a feature is implemented and merged into shipping branch of Roslyn and the appropriate changes merged into the language specification, the proposal should be archived under a folder corresponding to the version of the language in which it was included, e.g. VB 15.1 proposals). Rejected proposals are archived under the rejected folder.

Language Design Meetings

Language Design Meetings (LDMs) are held by the LDT and occasional invited guests, and are documented in Design Meeting Notes in the meetings folder, organized in folders by year. The lifetime of a design meeting note is described in meetings/README.md. LDMs are where decisions about future Visual Basic .NET versions are made, including which proposals do work on, how to evolve the proposals, and whether and when to adopt them.

Implementation

The reference implementation of the Visual Basic .NET language can be found in the Roslyn repository. Until recently, that was also where language design artifacts were tracked. Please allow a little time as we move over active proposals.

DISCLAIMER: An active proposal is under active consideration for inclusion into a future version of the Visual Basic .NET programming language but is not in any way guaranteed to ultimately be included in the next or any version of the language. A proposal may be postponed or rejected at any time during any phase of the above process based on feedback from the design team, community, code reviewers, or testing.