Create an Operational Semantics Team

[JakobDegen]

This RFC proposes creating T-opsem, a subteam of T-lang that replaces WG-unsafe-code-guidelines and will be the long term owner of questions around undefined behavior, memory models, etc.

There was discussion about this on Zulip.

Rendered

[compiler-errors]

Added T-lang and T-types labels at the request of @JakobDegen. Whether or not T-types needs to participate in this team's creation decision is undecided, though better to add it now and remove it later -- cc @rust-lang/types. ❤️ 😃

[JakobDegen]

To clarify, my reason for adding T-types is that this is responsibility that was given to T-types in the RFC that created that team, and it seems mean to take things away without asking first 😛

[RalfJung]

The two teams are expected to heavily interact on the syntax and semantics of MIR specifically -- right? that seems worth documenting.

[JakobDegen]

I've included this for T-types. I'm somewhat hesitant to include this for T-compiler, since I don't see a fundamental reason that rustc's MIR should be the same as the spec's MIR

[RalfJung]

I don't see a fundamental reason that rustc's MIR should be the same as the spec's MIR

If they are not the same, we will probably want to have a translation from rustc's MIR to the spec's core language, as a means to give precise semantics to rustc's MIR.

[nikomatsakis]

@rfcbot merge

This has been under discussion for some time! I am excited about seeing this team get started.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @compiler-errors
• @cramertj
• @jackh726
• @joshtriplett
• @lcnr
• @nikomatsakis
• @oli-obk
• @pnkfelix
• @scottmcm
• @spastorino

Concerns:

• process-for-adding-members resolved by Create an Operational Semantics Team #3346 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

For historical context:

I initially felt that this should be part of the types team's remit, since establishing soundness of the type system requires establishing an operational semantics, but it's become clear that the area of unsafe code interactions require special considerations that are really a distinct specialty from Rust's static type system (although the two certainly interact), and so it make sense to have a dedicated team.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[joshtriplett]

This section should include information on the process of adding a member. I would suggest using the language proposed by the libs and style teams:

Proposed new members of the team are nominated by existing members. All existing members of the team must affirmatively agree to the addition of a member, with zero objections; if there is any objection to a nomination, the new member will not be added. In addition, the team lead or another team member will check with the moderation team regarding any person nominated for membership, to provide an avenue for awareness of concerns or red flags.

Or, alternatively, do we want the membership to be determined by approval from lang? (That's not a proposal, that's a question to check which model we want.)

[JakobDegen]

Or, alternatively, do we want the membership to be determined by approval from lang?

My gut reaction to this is that the types team does not - as far as I know - do this, and if the system is working for them we should only diverge with a clear reason for why our needs are different (such a reason certainly might exist, but I don't know it)

[nikomatsakis]

My assumption is that the opsem team would manage its own membership.

[joshtriplett]

@rfcbot concern process-for-adding-members

Per suggestion. Happy with this otherwise.

[JakobDegen]

@joshtriplett forget to ask in the triage meeting today, can the concern be resolved?

[joshtriplett]

@rfcbot resolve process-for-adding-members

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[JakobDegen]

Teams PR is up, so this should be good to merge I think? Not sure if convention dictates that I let someone from the approving team hit the big scary green button

[compiler-errors]

As far as I'm aware, any member of the project can click merge. I can do so, since it seems like all the pre-requisites are satisfied (renaming the file to reflect the issue# and setting up the PR link correctly).