Add project group for const traits initiative

[compiler-errors]

This PR adds a project group for the "const traits" initiative.

@fee1-dead and a few others have gathered around an effort to enable const traits in the language (rust-lang/rfcs#2632). The RFC never landed, but work has been under experimentation (rust-lang/rfcs#2632 (comment)), and has gained speed especially recently since all of the work was ripped out and reimplemented under the new #![feature(effects)].

Adding this PG helps to acknowledge some of the people who work on this feature, and allows us to have a single ping group for important PRs, etc.

This PG is related to the keyword generics initiative (cc @rust-lang/initiative-keyword-generics) in that it's implementing a "const" effect, but I'd like for this to be under the stewardship of the compiler team (or ideally, types team, but that's not possible), since it's primarily focused around practical implementation work and implementation concerns (allowing users to implement and call const traits), rather than theoretical work of designing an over-arching feature of the language like the kw-generics initiative aims to do.

[compiler-errors]

IDK if this needs an MCP or anything

r? @wesleywiser @davidtwco

Also this is less "starting up a new project group" and more "reflecting the existing set of people working on a specific initiative". If this PG didn't exist, the work would still get done, but of course I'd be a bit sadder.

[yoshuawuyts]

The PR proposes to spin up a new initiative to cover the implementation of the #[feature(effects)] feature, under T-Compiler. This feature, and the last year+ of refactors in service of it, was done with the intent to enable experimentation with effect generics in the compiler. This means #[feature(effects)] has not only been built with an eye towards extending the const subset of the language, but was built considering future extensions to e.g. async, gen, and try as well.

Concerns

I worry that by formally creating a group which is solely responsible for a const generics feature, we may end up experiencing ambiguity over who is responsible for what part of the feature. On paper at least the effects initiative is currently responsible for both the design and experimentation with effect generics ¹. Though in practice of course @fee1-dead has been driving most of the implementation work for this, with the other members on this PR's charter helping out. With @oli-obk acting as a shared bridge back to the Effects Initiative.

By splitting custody of #[feature(effects)] between two separate initiatives I worry what happens in the case of a disagreement on how to progress. In the case that #[feature(effects)] was taken in a direction which conflicts with the Effect Initiative's goals, there would be no clear path to resolution. I believe we should prevent that, by ensuring both implementation and design are aligned at every step of the way.

This PR scopes #[feature(effects)] to only be about const generics, presumably not just implementation but design too. And relegates the Effects Initiative to only being about a theoretical future unifying design; not what's currently being implemented. To me this shows that we may already be experiencing communication issues, which wouldn't be helped by formalizing a further separation.

Alternative Proposal

I would like to put an alternative proposal forward: @fee1-dead, @fmease, and @compiler-errors formally join the Effects Initiative roster - and we find a shared slot to discuss implementation. If need be, for administrative purposes we can make it a joint initiative between T-Lang and T-Compiler ². That would provide an opportunity for both the lang and compiler side of the work to sync up between one another, without having to rely on @oli-obk as our sole go-between.

This may not be the only path forward we have to us, but to me this seems like a practical solution. I'm not particularly committed to this specific structure, but I want us to take potential conflicts here seriously. I believe we should take steps to proactively ensure we're communicating, and we don't end up in bad situations because we haven't been talking to one another.

Footnotes

1. To be precise here: experimentation with ~const Trait bounds was approved as part of the work on const generics. The ~trait bounds were removed as part of the generalization of the feature to cover other effects as well. The Effect Generics was never the group who obtained that approval, but we did make use of the existing approval to drive the refactoring of the work. If memory serves me well, Oli started this refactoring, which fee1dead ended up taking over and driving (very successfully). Given the overlap in membership between the effects initiative, T-compiler, and const generics it's a bit hard to provide exact attribution. ↩

2. I'm not sure whether we can do this yet, but imo organization structures should follow project needs - not the other way around. We already have precedent for this overlap via the T-Types - the difference here would be that the Effects Initiative is intentionally ephemeral and exists with the purpose of eventually being spun back down. ↩

[oli-obk]

it's primarily focused around practical implementation work and implementation concerns (allowing users to implement and call const traits), rather than theoretical work of designing an over-arching feature of the language like the kw-generics initiative aims to do.

I agree with this. the effects initiative is about the language level design, while this project group is for the implementation work in the type system. I don't believe there is much of an issue if the language design changes from what the impl does, and we need to adjust the impl. That part is mostly at the syntax and lowering level, and not what made implementing effects a hard thing

[yoshuawuyts]

Fair enough; Oli and I also talked offline a bit and we should be good for now with Oli serving as a bridge between both groups. Withdrawing my concern; excited for const traits!

[davidtwco]

This makes sense to me!

[fee1-dead]

experimentation with ~const Trait bounds was approved as part of the work on const generics

I don't think const traits is related to const generics. They are two separate initiatives, though I do agree that the naming can be confusing. The approval for experimentation is here

[fee1-dead]

And relegates the Effects Initiative to only being about a theoretical future unifying design; not what's currently being implemented. To me this shows that we may already be experiencing communication issues, which wouldn't be helped by formalizing a further separation.

I'm happy to chat about this on Zulip, and I agree that communication needs to be better. AFAIK, the implementation has been for const traits since the beginning, with the implementation design allowing it to be easier to implement other effects as well. Given the narrow focus of our current progress, and that no concrete proposals for how other syntaxes would work (like ~async), it appears to me that we're not just implementing the entirety of keyword-generics, and "implementing const traits with the design of effects/keyword generics in mind" seems closer to what we are actually doing.

Anyways, it would be nice if we continued this discussion elsewhere, since it is irrelevant to the formation of this project group for now.

[rylev]

It seems there was some discussion on whether this group should exist at all. It would be probably be better in the future for such discussion to happen elsewhere so that this repo can be used for more mundane particularities.

That being said, it seems that @davidtwco has approved this PR so it can be merged. I'll wait a bit to make sure I didn't misunderstand where this discussion landed.

[fmease]

Could somebody with the right set of permissions create a Zulip stream, #t-compiler/project-const-traits I guess? Thanks in advance :)