Dedicated strike team to resolve unsafe code guidelines #1643
Conversation
|
cc @arielb1 @ubsan @eternaleye @rust-lang/lang |
nikomatsakis
added
the
T-lang
nikomatsakis
force-pushed
the
memory-model-strike-team
branch
from
2b38396 to
af83792
Compare
|
I am interested as well. |
|
Something I'd've expected the RFC to mention: What's the motivation for forming a separate "strike team" to take on this responsibility, instead of making it a priority for one or more of the existing teams*? Is it expected that the membership of the strike team will have minimal overlap with the existing teams? Otherwise, if it's mostly the same people, the amount of capacity they have available to dedicate to the effort will be a constant independently of what team rosters they appear on. Of course the phrase "strike team" evokes swift and decisive progress, and everyone's in favor of swift and decisive progress, but naming aside why is this special-case organizational structure felt to be necessary and expected to be effective in this case? (And why not for other major priorities? What aspect of this one makes the difference?) * The RFC writes "It is the contention of this RFC that a complete guidelines for unsafe code are far too big a topic to be fruitfully addressed in a single RFC. Therefore, this RFC proposes the formation of a dedicated strike team" -- but I don't see how these are connected. There's no reason in principle why the effort couldn't be structured as a multi-RFC process as described without a dedicated strike team, or for that matter why a strike team couldn't have creating a single "big bang" RFC as its objective. |
|
@glaebhoerl The intent is that the strike team will include members not currently on subteams, and hopefully act in consultation with academics and other experts. As @nikomatsakis says, the lang team is expected to be heavily involved in some of the higher-level aspects, but we need people who can devote significant time to working out the details as well, and don't have the resources on the lang team alone. (I agree that the way the RFC explains this isn't very clear.) FWIW, I'm also a bit uneasy about the expectation that the artifacts here will end up going through the normal RFC process as well. I think we should try to get some clarity on who and how the decisions are going to be made. Separate concern: as someone who's spent some time on formal memory models (the concurrency side of C/C++11), I have significant respect for the problem space -- there are many open research problems in memory models, and many mistakes made over the course of years-long efforts by myriad experts. I think we need to go about this in a humble and open-ended way, with an emphasis on incremental, conservative gains. I think @nikomatsakis has done a good job of pushing in this direction by delineating the scope and highlighting some intermediate artifacts, but I'm hoping that we can reach further clarity on that front in this RFC thread. |
I would be open to changing this, but I still think it's a good idea. I think there are a lot of people who pay attention to RFCs, but don't follow the minute details -- they would probably want to know that a larger decision is on the cusp of being made. On the other hand, maybe we can just advertise that another way, but it seems like we have an existing RFC channel, so why not use it? One counter argument might be that we won't actually be ready to settle on a "high-level approach" (for example) until the detailed approach is nearly done, at which point there will be a lot of resistance to changing -- but that seems ok to me. If crucial flaws are found, great, we can fix them -- and if not, then we can continue moving forward. |
Yes, that is expected and the point. |
|
Will there be a stabilisation period for changes to the unsafe code guidelines? |
I think that makes a lot of sense, especially since existing code may well depend on subtle details in the way unsafe code is expected to be used. While we can likely make changes to undefined behavior compatibly in theory, we definitely should make sure we've thought through the way any changes to the way unsafe code is intended to be used will affect existing code. |
It probably makes sense to try and follow the process for features as much as possible -- this would imply an FCP for the "RFC", and then a secondary stabilization period. In the interim, I would expect that we'll make strides on modifying the compiler to take advantage of these new guidelines when optimizing, as well as surveying code for compliance, so that we can have a good feeling for how things are working out. |
|
Nominating for FCP. |
aturon
added
the
T-core
|
lgtm. I think this would be improved with some language about the conditions for disbanding the strike team; once these things are accomplished, the team's work is done. |
|
@brson is it? I look at C++, and their "strike teams" are never finished -- they have a team for gamedev, a team for the memory model, a team for everything. It seems to work out pretty well for them. |
Once there's a spec covering the memory model, I don't see what significant ongoing work there will be that can't be folded into the existing project structure. Whether the team is expected to exist forever or to have a finite purpose and then end, I would like it to be addressed. |
|
@brson Nowhere is the intention of this team to create a specification, unless this team is supposed to start the Rust specification. There is no Rust specification. (barring my personal project which is empty, because I haven't upstreamed any local changes yet) |
Thanks for the correction @ubsan. Please consider my previous comment to apply to whatever documentation this team is going to produce. |
|
Like @brson, I assumed that the purpose of this team was indeed limited in duration. That is, the team exists for the purpose of doing the sprint work to produce the initial documents described within. After that, smaller questions can presumably be resolved by the normal RFC process -- which would of course include input from the strike team members! |
|
After thinking more about the difference in meaning between 'team', 'subteam', and 'strike team', I do find it attractive for us to get to a place where many teams are flourishing in some official capacity. It wouldn't be a bad thing - it would be really great - for the teams page to be filled with many, many active contributors. The bigger Rust gets (and it's going to get really big) the more people need to be empowered to make decisions. But still I am inclined to push back on expansions of the bureaucracy, and want us to make those changes carefully. |
|
@brson I think the current bureaucracy is inefficient in part because some people are doing a lot of jobs at once. If we could just have more people doing less... We know that there are people in the community who want to help, but their skills aren't really fully utilized since everything needs to go through six people (and from personal experience, it just feels kind of hopeless when you're in that position). Edit: not just six people. Six people who are also in charge of compilers, libraries, tooling and infrastructure, community, and moderation, depending on the person. @eddyb - lang and compiler (I'm referring to my own experience here, dealing with the lang team; I'm not sure if other people with different teams have the same experience, but I know at least one other has had this experience with the lang team). |
aturon
added
final-comment-period
|
This RFC is entering its final comment period. The main point on which we need to reach final consensus is the precise "success conditions" (and whether the team is disbanded). This question intersects considerably with the ongoing discussion around refinements to the RFC process, but if possible we shouldn't block getting going on this team on those broader questions. |
It seems to me that the "success conditions" would be producing the various documents cited in the RFC. That is, the team exists to produce the initial version of those documents. I'm not sure what I think about longer-lived "subsubteams" yet -- I go back and forth -- but I do feel pretty sure that this RFC wouldn't be the right place to establish such a thing. I feel like that's creating permanent structure is a more fundamental change more, akin to #1068, and hence worthy of being discussed separately. |
team with a specific purpose
| The unsafe code guidelines team is intended as a temporary strike team | ||
| with the goal of producing the documents described below. Once the RFC | ||
| for those documents have been approved, responsibility for maintaining | ||
| the documents falls to the lang team. |
There was a problem hiding this comment.
I'd argue the docs team is a better team for this (even if they don't yet exist).
There was a problem hiding this comment.
I guess for now it makes more sense since the doc doesn't exist like you said. 😉
|
@ubsan: We really need a spec and then csn define what are common and what are accepted variance for porting. |
|
Huzzah! The @rust-lang/core team has decided to accept this RFC. If this stuff is of interest to you, you probably want to subscribe to this internals category: https://internals.rust-lang.org/t/about-the-unsafe-code-guidelines-category/3706 |
Centril
added
A-unsafe
Incorporate a strike team dedicated to preparing rules and guidelines for writing unsafe code in Rust (commonly referred to as Rust's "memory model"), in cooperation with the lang team. The discussion will generally proceed in phases, starting with establishing high-level principles and gradually getting down to the nitty gritty details (though some back and forth is expected). The strike team will produce various intermediate documents that will be submitted as normal RFCs.