Visual Basic

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. Discussion pertaining to language features takes place in the form of issues in this repo, under the Discussion label. 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? 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. 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. 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.