I'd like to see #[derive]'ing being discussed in this RFC, it's notably absent from it and shouldn't be an afterthought in my opinion.

Namely, there should be a canonical/conventional mechanism for deriving a "const trait impl" from/for an ADT.
Whether such an impl would be (unconditionally) const, conditionally const, or either depending on a "flag" would be a point for discussion.

It should be quite obvious why you'd want to const-derive a trait and why #[derive] itself shouldn't derive "conditionally const trait impls" by default.

As for the concrete design, there should be a canonical/conventional way to signal to the (built-in or user-defined) derive macro that a "const" trait impl is requested.

As @petrochenkov noted in rust-lang/rust#118580 (comment), rust-lang/rust#118580 (comment) and rust-lang/rust#118580 (comment) there are three extensible candidates:

1. Leveraging helper attributes. At call sites, that might look like

   #[derive(One, Two)]
   #[one(const), two(const)]
   …

   I guess. At def sites, it would just look like

   #[proc_macro_derive(One, attributes(one))]
   pub fn derive_one(_item: TokenStream) -> TokenStream { … }

   That design wouldn't require any additional changes to the language.

2. Giving derive macros a second input stream. At call sites, that might look like

   #[derive(One(const), Two(const))]
   …

   At def sites:

   #[proc_macro_derive(One)]
   pub fn derive_one(_item: TokenStream, _arg: TokenStream) -> TokenStream { … }

   Note that the one-argument form would still exist for backward compatibility. This arity-based dispatch is very much possible for proc macros. See e.g., PR Provide a way for custom derives to know if they were invoked via #[derive_const] rust#118580. Of course, we could choose to do something different here but in any case I'd prefer if we didn't force a new edition for this.

3. Passing another input stream via "global data" (which is what e.g., Span::call_site() uses under the hood). At call sites, that might look like

   #[derive(One(const), Two(const))]
   …

   At def sites:

   #[proc_macro_derive(One)]
   pub fn derive_one(_item: TokenStream) -> TokenStream {
      let _arg/*: TokenStream */ = extra_input_stream();
      …
   }

For context, the compiler currently features the placeholder syntax #[derive_const] under the experimental feature derive_const. Obviously, that syntax is quite awkward and non-extensible (to other potential effects or data in general we might want to pass to proc macros in the future).

I think the derive syntax should reflect the bound syntax: #[derive(const Trait)].

It should be quite obvious... why #[derive] itself shouldn't derive "conditionally const trait impls" by default.

Perhaps you could elaborate on this. I can think of some reasons, but I want to be sure I've thought of all the reasons.

I think the derive syntax should reflect the bound syntax: #[derive(const Trait)].

For a related syntax discussion, see:

• Unsafe derives and attributes #3715

For a related syntax discussion, see #3715

unsafe is a property of the derivation operation there, while const is a property of the resulting derived impl here. The syntaxes for each should be different, to reflect that distinction.

It should be quite obvious... why #[derive] itself shouldn't derive "conditionally const trait impls" by default.

Perhaps you could elaborate on this. I can think of some reasons, but I want to sure I've thought of all the reasons.

Yes, of course. For the sake of argument, let's assume that this RFC establishes the convention for derive macros to generate const trait impls either always or just by default.

1. It would create a medium-term divide in the ecosystem: The large corpus of derive macros written by users before the hypothetical stabilization of feature const_trait_impl would naturally continue to generate non-const trait impls until migrated (which takes time) contrary to the ones created after it. This could be perceived as confusing by newcomers and frustrating by seasoned Rust devs.
2. If not made an edition item, it would implicitly and practically irrevocably alter the public API of all library crates which expose types to which built-in derive macros (from core / std) were applied as suddenly said crates would promise more (conditionally) const impls which they can't go back on without a major version update.
3. (Conditionally) const trait impls obviously come with more requirements therefore "less can be derived (by default)". Think less about type parameters and more about the types of priv/pub fields which — from a probability perspective — likely only impl the trait in question "non-const-ly".
4. Assuming that there's no opt-out (unlikely, I admit), going forward there would no longer be a canonical / conventional way to derive non-const trait impls (which are convenient and obviously allow for greater leeway wrt. the evolvement of the implementation) forcing users to write those impls by hand (possibly error prone) or to create their own conventions and mechanisms.
5. Assuming that there's an opt-out, then deriving would still no longer mirror manual impls wrt. constness since constness is notoriously opt-in. That would also mean finding new syntax that's unlike anything preexisting (think #[derive(nonconst Trait)] or similar).

Feel free to correct me on / contest any of these points, some of these might be a bit weak or even irrelevant. I threw this together quickly, so yeah.

We're sticking with the already implemented #[derive_const(Trait)] syntax and leaving it to future RFCs after unsafe derives are finalized to come up with something better

derive_const only works for built-in derive macros though, are you saying that we won't support user-defined const-derives in the foreseeable future (rust-lang/rust#118304 (blocked by design concerns or rather total lack of design))?

Note: A lot of the discussion around the language design is happening on Zulip, under the t-lang/effects stream. The latest major proposal discussion can be found at https://rust-lang.zulipchat.com/#narrow/channel/328082-t-lang.2Feffects/topic/All.20that's.20old.20is.20new.20again. It would be nice if before commenting on this RFC one could check if this topic has been discussed on the Zulip stream before :) When there appears to be a consensus forming from community members + the lang team, the proposal should then be updated.