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
Contributor

rylev commented Dec 10, 2019

rendered

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 10, 2019

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. =)

@rylev rylev force-pushed the rylev:project-safe-transmute branch from b8f60e0 to 2c6f720 Dec 11, 2019
@AndrewGaspar

This comment has been minimized.

Copy link

AndrewGaspar commented Dec 11, 2019

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 bsteinb/rsmpi#54).

I'm considering adding the safe-transmute crate as a public dependency of rsmpi (bsteinb/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

This comment has been minimized.

Copy link

Lokathor commented Dec 11, 2019

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

rylev commented Dec 16, 2019

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 16, 2019

@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 label Dec 16, 2019
@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 16, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

rfcbot commented Dec 19, 2019

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

@rfcbot

This comment has been minimized.

Copy link

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.

@nikomatsakis nikomatsakis merged commit 2c6f720 into rust-lang:master Jan 7, 2020
@nikomatsakis

This comment has been minimized.

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 rylev:project-safe-transmute branch Jan 8, 2020
@programmerjake

This comment was marked as resolved.

Copy link

programmerjake commented Jan 9, 2020

@nikomatsakis the Zulip link got messed up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.