Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Announcing the Safe-Transmute Project Group #2835

Merged
merged 1 commit into from
Jan 7, 2020

Conversation

rylev
Copy link
Member

@rylev rylev commented Dec 10, 2019

rendered

This RFC is based on a similar RFC: #2797.

@nikomatsakis
Copy link
Contributor

On the actual topic, I am in favor of pursuing this for a few reasons. First, I think it's important that we offer as many "safe tools" as we can, and also to offer people APIs that give more structure to what they are doing.

Meta: what is a project group? What is this RFC?

On the meta topic, I just wanted to give people a bit of context. We are increasingly adopting this "shepherded project group" system, which I think we will have some upcoming RFCs to formalize once we've gained a bit of experience. The idea is that when we have people from the community interested in a design, and we have at least a lang team member who'd like to serve as a liaison, we can put those together and form a project group. This should happen as early as possible, so that we can capture as much of the design process as possible.

Creating a group will generally start with an informal conversation and an RFC. We'll create an associated Zulip stream (or streams, if needed) as well as a repository that tracks the progress. The plan is that the group should carry the feature all the way through to the stabilization stage, with RFCs or other decision mechanisms along the way for major decisions or changes of direction.

Meta: what kind of comments make sense here?

Since the focus of this RFC is just to create a group, the real question we are trying to answer is whether this is a good direction for the project to pursue, and not to have a discussion about the technical details. If you have concerns (e.g., about some details of the API), those will mostly be things to discuss in detail within the context of the group itself, not here.

This isn't to say all technical feedback is inappropriate. The main reason to raise technical concerns however would be either to (a) register concerns that the group can work to address, which wouldn't block this RFC or (b) if you think that there are so many flaws or unknowns that the idea is premature or infeasible. I think that the latter is pretty clearly not the case, but I'd be open to counterarguments. =)

@AndrewGaspar
Copy link

To comment on the merits of this proposal: I think having concepts related to safe transmutation in the core language would be very helpful for a project like rsmpi. rsmpi provides a Rust interaction model for MPI, which is the standard for inter-node communication in HPC applications, used in the world's fastest supercomputers. The MPI standard does not require any sort of type checking between communications, and no implementations do, as far as I know. Therefore, Rust must treat all MPI receive operations as, essentially, safe transmutes. (See rsmpi/rsmpi#54).

I'm considering adding the safe-transmute crate as a public dependency of rsmpi (rsmpi/rsmpi#79) in order to solve this problem. However, it would be even better if the necessary traits (and support for safe, automatic derivation for structured types) were in the core language so that different libraries all agreed on the right way to define these kinds of types, and all core types that satisfy the requirement would be appropriately marked.

@Lokathor
Copy link
Contributor

I'd like to explicitly state that I'm very happy to see safe union access being listed as a future goal. Most unions that you'd get from FFI are 100% safe to access.

@joshlf
Copy link
Contributor

joshlf commented Dec 13, 2019

I'd love to be involved with this if possible. I've done a lot of work in this space, and have future plans of my own that might dovetail nicely with this work:

  • The zerocopy crate
  • This draft RFC
  • Some other work that's been done in private with the intention of eventually being made public

cc @jswrenn @cbiffle @anp

@rylev
Copy link
Member Author

rylev commented Dec 16, 2019

@joshlf it would be really great to have you involved! The current discussion is happening on zulip.

@nikomatsakis
Copy link
Contributor

@rfcbot fcp merge

As this RFC is solely to charter a new group, and I don't really expect a lot of controversy with this as a focus, I'm going to move that we merge this RFC.

@nikomatsakis nikomatsakis added the T-lang Relevant to the language team, which will review and decide on the RFC. label Dec 16, 2019
@nikomatsakis
Copy link
Contributor

I think I didn't have the right labels when I issued the previous command. Let's try this again.

@rfcbot fcp merge

As this RFC is solely to charter a new group, and I don't really expect a lot of controversy with this as a focus, I'm going to move that we merge this RFC.

@rfcbot
Copy link
Collaborator

rfcbot commented Dec 16, 2019

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

No concerns currently listed.

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.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Dec 16, 2019
@rfcbot
Copy link
Collaborator

rfcbot commented Dec 19, 2019

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

@rfcbot rfcbot removed the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Dec 19, 2019
@rfcbot
Copy link
Collaborator

rfcbot commented Dec 29, 2019

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.

The RFC will be merged soon.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Dec 29, 2019
@nikomatsakis nikomatsakis merged commit 2c6f720 into rust-lang:master Jan 7, 2020
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jan 7, 2020

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

To track further discussion, subscribe to the Zulip stream project-safe-transmute

@rylev rylev deleted the project-safe-transmute branch January 8, 2020 12:40
@programmerjake

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants