Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Announcing the Safe-Transmute Project Group #2835
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. =)
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
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:
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.
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.