Shulou(Shulou.com)11/24 Report--

CTOnews.com, November 20, the Rust team announced that it had accepted the proposal of RFC 3355 a few months ago and decided to begin to develop an official specification for the Rust language.

In the process, Eric (maintainer of Rust reference), Felix (Rust language team), Joel (Rust Foundation) and Mara (author of RFC) formed a "specification team" to work together to promote the work, officials said.

A few days ago, the specification team posted an introduction to the progress of this work and some other follow-up plans, and announced that it would develop a regular meeting schedule, identify a list of stakeholders, and produce the first Demo product for the team in the future. CTOnews.com collates the relevant content as follows:

The editor side (Editor) as the "editor" role specified in the RFC, because when the foundation sought the ideal candidate for the position, a candidate's proposal was finally rejected, and the foundation finally chose to consider internal options as an alternative.

Joel, the foundation's technical director, offered to take the position as part of his current job. Because of Joel's extensive experience in industry standards and technical editing, as well as its close relationship with the Rust project, Eric,Felix and Mara quickly agreed to put Joel in the specification editor position.

The Specification team (Specification Team) official said that because editors could not do the work alone, they formed the specification team as a sub-team of the language team.

The members include:

Felix Klock (team leader)

Mara Bos (team leader)

Joel Marcey (team member, editor)

Eric Huss (team member)

Stakeholders officials have announced that they will select and maintain a list of "stakeholders", including "experts" and "specification users", who will act as consultants and reviewers.

The members include:

All members of the Rust language team

One or more representatives from the type team

One or more representatives from the operational semantic team

One or more representatives from Ferrocene (high security / availability, such as the automotive industry)

One or more representatives from formal method research and development

One or more representatives from the operating system developer (Rust for Linux; Microsoft)

Permissions and approval (Authority and Approval) although the specification team is responsible for writing and editing the specification, the authority over the definition of the Rust language is still the responsibility of the relevant teams, such as the language team and the library API team. These teams should involve other teams / subteams as necessary, for example, by asking questions, nominating issues for discussion, and requesting FCP approval on key decisions.

Officials say that in order to enable the specification team to generate content and iterate without the constraints of the approval process, they will develop a draft specification in the working repository to publicly track projects that still need team approval and questions raised by stakeholders.

We classify all changes as minor or major changes. Minor changes are projects that seem uncontroversial or trivial to the specification team. For example, the language team has passed FCP-approved changes, typesetting and syntax fixes, clear clarification, and similar exciting changes. Major changes are those that may be problematic, important, or controversial. Any member of the specification team and relevant authority teams, as well as any specification stakeholder, can mark the change as a significant change. Major changes to the specification must go through the usual approval process (such as the language FCP) to appear in a released (non-draft) version of the specification.

The language and specification team should strive to have at least one shared member (such as Felix) to act as a liaison to ensure that official understandings of "what are minor changes" and "what are major changes" are synchronized.

The goal of the target specification team is to create and maintain the Rust specification.

The purpose of the Rust specification is to provide authoritative resources for determining which source texts are valid Rust programs and the behavior of these programs. The ideal specification is:

Current and future versions of Rust define defined boundaries for the semantics of a given Rust program

Provides a detailed description of the semantics of the Rust version coupled to the instance of the specification.

Details about a specific version can be provided directly in the specification or indirectly through other documentation that is delegated to the relevant Rust team.

The release rhythm Rust release will be independent of the specification approval process, which is considered from the design point of view. Normative work must not add new obstacles to the project that need to be overcome to meet its existing obligations, such as a six-week release cycle.

The team's vision is to eventually reach the level of automatic delivery of updated specifications and to be able to complete at the pace of the project's 6-week release. However, in the short and medium term, it hopes to be free to lag behind the six-week release pace. The ability to lag behind the Rust release plan can be particularly useful when the specification team gradually adds new content to areas that have not been covered before, or significantly reduces the scope of the current version of the specification.

Although the specification development process does not prevent release, changes in language functionality should be combined with relevant updates to the specification. Once a specific version of the specification is released, changes to the language functionality recorded in the current specification will not be stable if the specification team does not approve the corresponding pull request to the current draft specification. Changes to language features that are not recorded in the specification can be stabilized without updating the specification, but members of the specification team are required to confirm that the corresponding functionality is not recorded.

By enforcing rules that new functionality must be part of the specification before it can be stabilized, it is expected to eliminate the main source of potential lag between the specification and the Rust version.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.