rust
/
rfcs
mirror of https://github.com/rust-lang/rfcs
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #3544 from RalfJung/t-opsem-link 

t-opsem RFC: link to t-types RFC
This commit is contained in:
Eric Huss 2023-12-16 06:44:52 -08:00 committed by GitHub
parent 94f88619c0 97f77e53f1
commit 798ba4e1ef
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
text/3346-t-opsem.md
View File

@ -5,7 +5,7 @@
# Summary
Create an operational semantics team that is tasked with owning the semantics of unsafe code. This responsibility would be transferred from T-types, which had previously been given ownership of this domain. Additionally, this team replaces the Unsafe Code Guidelines working group, which has been doing much of the work in this space.
Create an operational semantics team that is tasked with owning the semantics of unsafe code. This responsibility would be transferred from [T-types], which had previously been given ownership of this domain. Additionally, this team replaces the Unsafe Code Guidelines working group, which has been doing much of the work in this space.
## Mission and responsibilities
@ -35,9 +35,9 @@ It is not possible to precisely define where the scope of the team's responsibil
## Relationships to other teams
**T-lang**: The team is a subteam of T-lang. It has the same relationship to T-lang as T-types has. This means decisions about "details" will be made by the team alone, but decisions around the big picture "direction" will require consultation with T-lang.
**T-lang**: The team is a subteam of T-lang. It has the same relationship to T-lang as [T-types] has. This means decisions about "details" will be made by the team alone, but decisions around the big picture "direction" will require consultation with T-lang.
**T-types**: As T-types will no longer own semantics questions, the responsibilities of T-opsem and T-types are not expected to overlap. However, like other teams, T-types is expected to consult T-opsem on any changes that require support from the operational semantics. For example, if T-types wants to extend the borrow checker to allow more code patterns, T-opsem must confirm that the code that this permits can be supported by a reasonable operational semantics. Conversely, when T-opsem wants to declare some unsafe code UB, it better be the case that T-types does not have plans to allow the same action to be expressible in safe code. Additionally, T-types and T-opsem are expected to need to collaborate heavily on the syntax and semantics of MIR, since MIR is pivotal to both teams' interests.
**T-types**: As [T-types] will no longer own semantics questions, the responsibilities of T-opsem and T-types are not expected to overlap. However, like other teams, T-types is expected to consult T-opsem on any changes that require support from the operational semantics. For example, if T-types wants to extend the borrow checker to allow more code patterns, T-opsem must confirm that the code that this permits can be supported by a reasonable operational semantics. Conversely, when T-opsem wants to declare some unsafe code UB, it better be the case that T-types does not have plans to allow the same action to be expressible in safe code. Additionally, T-types and T-opsem are expected to need to collaborate heavily on the syntax and semantics of MIR, since MIR is pivotal to both teams' interests.
**T-compiler**: Unlike T-types, T-opsem is not a subteam of T-compiler as it does not own any implementations. However, T-compiler is still expected to request approval from T-opsem before adding any optimization that depends on new theorems about the operational semantics. T-opsem will ensure that these theorems are expected to be true and are reasonable things for the compiler to depend on now.
@ -112,3 +112,5 @@ As noted above, the team and certainly all of its members are expected to have i
- One alternative is to maintain the status quo, that is to have T-types continue to be responsible for these decisions.
Currently, the intersection between the members of WG-unsafe-code-guidelines and T-types is small. This means this option seems non-ideal, as it is unlikely that individuals interested in the topics that remain with T-types after this RFC are the same people who are most interested in working on opsem topics.
[T-types]: 3254-types-team.md