#[derive(Debug)] by default

More generally, I don't think the answer to "X has been in limbo for Y years" is "give up on X and do Z instead". Rather, we should start with "why is X still in limbo?", because often there's a way to unblock it, or all our resources are busy with something that's even higher priority, so adding Z onto the pile now would only make everything worse without producing any short- or medium-term benefits for anyone.

I think this is exceptionally likely for "a new kind of macros", because we still have significant parts of procedural macros unstabilized, all of whatever MBE 2.0 is supposed to be in limbo itself, and the whole macro hygiene system in so much limbo that I don't think we ever even got a piece of documentation defining what "hygiene" is, and I'm still quite confused about it myself. I know I'm not working on any of this myself (although hopefully I will be soon), but it really seems like more feature proposals is the absolute last thing we need in this space.

With specialization, it's hard to know for sure, but it does seem clear that other big limbo features like const generics are making steady but serious progress toward something shippable, and I keep seeing PRs that imply "chalkification" is slowly happening, which I suspect is what's blocking most of it.

Though I do wish someone who can speak more authoritatively would give a clear statement on specialization. I know soundness problems were responsible for a lot of those 5 years, but I've also heard repeatedly that we currently know of a useful, sound subset of specialization that could be stabilized. Is it blocked on or part of the "invisible work" of chalkification? Are we simply putting all our resources into const generics, post-MVP async/await stuff, etc instead?

8 Likes

Also, if someone, like myself, who has no real experience in implementing a compiler/language, but, who believes they understand, at least at a high-level, what these sorts of things should look like and why they're useful, would like to help get this implemented, where would be the best place to start? How could they be of the most help?

1 Like

On this subject, I just noticed

It's not as decisive a step forward as the title might suggest, but the PR description lays out a pretty clear plan for what has to happen next in the short term, so that's something.

6 Likes

What about adding a simple sugar to accept #[derive(...)] on module-level, that'd just slap that thing on every struct and enum defined in that module? Or possibly crate_derive that does it for whole crate? And maybe add exclude_derive to exclude derives?

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.