Create a types team by jackh726 · Pull Request #3254 · rust-lang/rfcs · GitHub

clarfonthey commented 10 days ago

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.

@clarfonthey:

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!

nikomatsakis commented 9 days ago

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.

nagisa commented 9 days ago

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.