Create a types team #3254
Create a types team #3254
Conversation
|
I would like to avoid bikeshedding since it's clear you've already thought about the name, but one potential issue naming it the "types" team, my immediate first thought is that they're just a subset of the libs team working on types in the standard libary. This feels oddly specific for a team, and after being explained what they do, it does make a lot of sense to me, so, this argument probably isn't that important, but I figured I'd mention it anyway. The only alternative I can think of that solves this problem while meeting the desired criteria is a "specs" team, but I figure you've already thought of the possibilities enough for this. |
|
the names "types", "traits", and "formality" have been considered (among a few others, but those are the main ones). See this zulip stream for some earlier discussion. I think the name "types" is the best compromise here to summarize what the team really cares about. To address the suggestion, the issue with the name "formality" -- and this also extends to "specs" -- is that the team will not be limited to the formal modeling and specification of types and the traits solver, but will also be involved in the implementation details (e.g. both working towards improving the existing trait solver, and working on what's next, whether that be chalk or something else!) That's a big reason that this team is (at least conceptually) a sub-team of both lang and compiler. On the other hand, team names need to be succinct, imo. There will inevitably be misunderstanding about the team's purpose, but the teams repo luckily lets us put a description that'll hopefully elaborate this further ("involved in the specification and implementation of the type system and trait solver", or something better than that), and also hopefully the team is active enough that people will know "T-types" when they see it mentioned! |
|
cc @rust-lang/compiler and @rust-lang/lang -- as currently envisioned, this team is a subteam of both these teams -- or intersects them, anyway. The idea is to take ownership (from lang) of drafting the "formal type rules + operational semantics" and to take ownership (from compiler) of the implementation side of things. But, just as the lang team decides "language policy" but the compiler team owns the implementation, the types team would have the same scope -- the goal is to formalize, validate, and implement the designs coming from lang team, not to drive the ship. |
nikomatsakis
added
T-lang
|
In my experience “the type system” has been a pretty unambiguous way to refer to most parts that the proposed team would be in charge of. borrowck feels like it has historically been a somewhat independent entity but that's not too difficult to adapt to. I think its going to be hard to come up with a better name. That said, if I had to pick between “type system team” and “types team”, I'd pick the former as it rolls off my tongue tad-a-bit easier than the alternative. |
Co-authored-by: Eric Holk <eric.holk@gmail.com>
The [types team](rust-lang/rfcs#3254) is the likely successor of the work. Note: I also added a `[[github]]` annotation to the wg defintion in the unlikely case that the wg is revived, since until now the permissions have been manually curated on GitHub.
text/0000-types-team.md
Outdated
|
|
||
| The types team is meant to build a base of maintainers for the formal side of Rust, both design and implementation. This has traditionally been an area with a very low "[bus factor]", both in terms of the compiler (few maintainers to the code) and the language design (few people who fully understand the entire space). Focusing a team on just Rust's "type system" will allow us to do targeted outreach and to help people to learn the background that is needed to contribute here. | ||
|
|
||
| Like the compiler team, the team's plays a "supportive" role. Its goal is to ensure both that Rust's type system has an efficient and correct implementation and that the type system (design and implementation) is able to scale to new demands and requirements. At this moment, Rust is suffering from a general paralysis in which new features (implied bounds, const generics, specialization, etc) are stalled for long periods of time due to a combination of an inflexible implementation, a lack of maintainers, and a general difficulty in reasoning about their interactions. |
There was a problem hiding this comment.
Maybe the sentence "At this moment..." would be better at the beginning of this paragraph.
There was a problem hiding this comment.
Hmm, maybe. I do agree that this sentence doesn't seem to "lead" anywhere though.
There was a problem hiding this comment.
I changed the order here a bit. Thoughts?
|
@rfcbot fcp merge I think this is ready to go! For now, we're running forward with the idea of this as a subteam of compiler/lang, so I've tagged the RFC with those two teams. |
|
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
added
proposed-final-comment-period
Co-authored-by: Josh Triplett <josh@joshtriplett.org> Co-authored-by: Santiago Pastorino <spastorino@gmail.com>
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
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. |
|
furiously smashes merge button Hooray! Thanks everyone and especially @jackh726 for moving things along and writing all the docs |
|
@oli-obk: hm, didn't we need to adjust the RFC number, etc first? or does that usually happen after the RFC is pushed? |
|
Yea, I performed this directly on master after the merge |
This RFC introduces the "type system team" or "types team". This team formally is a subteam of both the lang and compiler team. It's primary tasks are to define and maintain the design and implementation of Rust's type checker, trait solver, and borrow checker.
Rendered RFC
This RFC was authored in large part by @nikomatsakis and other mentions of the current traits working group (and future types team).
Prior discussion can be found on zulip, here and here.