Hey folks-- I've brought up the possibility several times of trying to stabilize a minimal version of specialization which only allowed specializing concrete types with no lifetimes, which I believe avoids all of the interesting soundness questions. It seems like there was some disagreement over whether or not this would be useful. I know I've personally wanted/needed specialization many times, and a minimal version like this would unblock many of my use-cases (e.g. making a performance-critical Vec<u8> trait impl fast as compared to a complex Vec<T: SomeTrait> impl, adding a base-case impl for a specific type where all other implementations delegate to that type, allowing casing on sealed traits over a small number of concrete types, etc.). @Joshua Liebow-Feeser and I would be interested in working on a proposal for something along these lines, but with the new working-group setup I'd like to make sure we're following the proper order of things WRT gathering working-group consensus and prioritization.

Are there others who would be interested in participating in this effort? Does this seem like something you'd be interested in prioritizing? (relative to other roadmap language features)

(this post really belongs in t-lang/wg-traits, but sadly that does not exist)

(cc @Aaron Turon and @centril who I believe have had thoughts about this in the past)

I'd like an informal specification of what exactly is to be stabilized. Bugs that exist wrt. those need to be closed and the checkboxes on the tracking issue need to be addressed in some way. The more expressive specialization needs to be cordoned off into a new feature gate or the limited subset needs to be cordoned off into a new one (like with min_const_fn). Moreover, I think that surface syntax changes are needed, e.g. with where specialize(T: Foo), and there's no way around an RFC on that.

One thing that would be nice is to disable #![feature(specialization)] and survey how many errors you get in the compiler & standard library

and then categorize by "would be supported" and "would not"

Here are a few thoughts in no particular order:

I support the general idea. Indeed, this was the "framing" of my max-min specialization post -- i.e., trying to find something minimal. The post even included a (relatively) simple concept of "always applicable" (not the more general, always applicable relative to base impl).

I think a good first step would be identify the concrete use cases, and then trying to see whether we can accommodate them with something like always applicable
- I haven't thought about this in a bit, but of course the question is whether we can implement the idea in the compiler's existing trait system or if we really want something more like chalk to handle it

I definitely this working group is the right place to be doing this. I also think this topic is misnamed, and we should instead organize it something like this (or perhaps just mix both into one stream):
- wg-traits/t-compiler
- wg-traits/t-lang

I think there is some room to expand our focus. In particular, we're very light on the "extending chalk" side of things. The main thing we're needing is some leadership there -- if @Taylor Cramer wants to provide it, I think pursuing specialization makes a lot of sense.

I would prototype the ideas in chalk to prove them out and provide the "official semantics", but I don't think that will be all that hard