Skip to content

Latest commit

 

History

History
904 lines (673 loc) · 27.6 KB

0000-derive-bound-control.md

File metadata and controls

904 lines (673 loc) · 27.6 KB
Raw
  • Feature Name: derive_bound_control
  • Start Date: 2018-02-26
  • RFC PR: (leave this empty)
  • Rust Issue: (leave this empty)

Summary

This RFC gives users a way to control trait bounds on derived implementations by allowing them to omit default bounds on type parameters or add bounds for field types. This is achieved with the two attributes #[derive_no_bound(Trait)] and #[derive_field_bound(Trait)].

The semantics of #[derive_no_bound(Trait)] for a type parameter P are:

The type parameter P does not need to satisfy Trait for any field referencing it to be Trait

The semantics of #[derive_field_bound(Trait)] on a field are that the type of the field is added to the where-clause of the referenced Trait as: FieldType: Trait.

Motivation

The deriving mechanism of Rust allows the author to prototype faster and reduce pain by significantly reducing boilerplate in many cases. Deriving also allows readers of code to easily see when a bunch of simple delegating impls are defined instead of reading such boilerplate as manual impls.

Unfortunately, there are many cases where deriving fails to produce the code intended by manual implementations. Either the impls produced are too restrictive by imposing bounds that shouldn't be there, which is solved by #[derive_no_bound(..)], or not enough bounds are imposed. When the latter is the case, deriving may fail entirely. This is solved by #[derive_field_bound(..)].

The crate serde provides the attribute #[serde(bound = "T: MyTrait")]. This can be used solve the same issues as in this RFC. This RFC proposes a common mechanism to be used for all derivable traits in the standard library, as well as in custom derive macros. By doing so, a common language is given to users who can now use this method regardless of what trait is being derived in all of the ecosystem.

Guide-level explanation

Removing bounds in derive with #[derive_no_bound]

Let's consider a simple new-type around an Arc<T>:

#[derive(Clone)]
struct MyArc<#[derive_no_bound] T>(Arc<T>);

or, to apply #[derive_no_bound] to all type parameters, which is in this case equivalent:

#[derive(Clone)]
#[derive_no_bound]
struct MyArc<T>(Arc<T>);

The resulting impl will be of the form:

// There is no bound T: Clone!
impl<T> Clone for MyArc<T> { /* .. */ }

We see that #[derive_no_bound] on T is an instruction to the derive macro for Clone that it should not add T: Clone. This applies to any trait being derived and not just Clone. This works since Arc<T>: Clone holds regardless of whether T: Clone or not.

But what if you want to differentiate between the deriving behavior of various traits? Let's derive another trait, PartialEq, but still use #[derive_no_bound(..)]:

#[derive(Clone, PartialEq)]
struct MyArc<#[derive_no_bound(Clone)] T>(Arc<T>);

We can equivalently write:

#[derive(Clone, PartialEq)]
#[derive_no_bound(Clone)]
struct MyArc<T>(Arc<T>);

Here, a meaningful PartialEq for MyArc<T> requires that T: PartialEq. Therefore, we don't want that bound to be removed from the impl of PartialEq for MyArc<T>. Instead, we use #[derive_no_bound(Clone)] and the resulting impls will be:

// As before:
impl<T> Clone for MyArc<T> { /* .. */ }

// And `T: PartialEq` is there as expected!
impl<T: PartialEq> PartialEq for MyArc<T> { /* .. */ }

Let's consider this scenario in action with a real world example and create a wrapper around a trait object of Strategy in the crate proptest:

#[derive(Clone, Debug)]
pub struct ArcStrategy<#[derive_no_bound(Clone)] T> {
    source: Arc<Strategy<Value = Box<ValueTree<Value = T>>>>
}

// Debug is required as seen in these snippets:
pub trait ValueTree { type Value: Debug; }
pub trait Strategy: Debug { type Value: ValueTree; }

In this case, the generated code will be:

impl<T> Clone for ArcStrategy<T> { /* .. */ }
impl<T: Debug> Debug for ArcStrategy<T> { /* .. */ }

We have so far considered a single type parameter. Let's now add another. We consider a Refl encoding in Rust:

use std::marker::PhantomData;

/// A proof term that `S` and `T` are the same type (type identity).
/// This type is only every inhabited when `S` is nominally equivalent to `T`.
#[derive(Copy, Clone, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)]
#[derive_no_bound]
pub struct Id<S: ?Sized, T: ?Sized>(PhantomData<(*mut S, *mut T)>);

// ..

This will generate the following impls:

impl<S: ?Sized, T: ?Sized> Copy       for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Clone      for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Debug      for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Hash       for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> PartialEq  for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Eq         for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> PartialOrd for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Ord        for Id<S, T> { /* .. */ }

In this case in particular, we've reduced a lot of clutter as well as unnecessary typing.

Why do we need to be able to remove bounds on different parameters independently? Because their behavior may diverge. Let's consider such a type where this is the case:

#[derive(Clone)]
struct Foo<#[derive_no_bound] S, T> {
    bar: Arc<S>,
    baz: T,
}

The generated code in this case is:

impl<S, T: Clone> Clone for Foo { /* .. */ }

With an even more complex scenario we have:

#[derive(Clone, PartialEq)]
struct Foo<#[derive_no_bound(Clone)] S,
           T,
           #[derive_no_bound(Clone, PartialEq)] U> {
    bar: Arc<S>,
    baz: T,
    quux: PhantomData<U>
}

and the generated code is:

impl<S, T: Clone, U> Clone for Foo { /* .. */ }
impl<S: PartialEq, T: PartialEq, U> Clone for Foo { /* .. */ }

#[derive_no_bound] is not #[derive_ignore]

Consider the case of Filter<I, P> as in:

/// An iterator that filters the elements of `iter` with `predicate`.
#[derive(Clone)]
pub struct Filter<I, P> {
    iter: I,
    predicate: P,
}

This type provides the impl:

impl<I: Debug, P> Debug for Filter<I, P>

Notice in particular that P lacks the bound Debug. To derive Debug instead, you might want to reach for #[derive_no_bound] on P in this case as in:

#[derive(Clone, Debug)]
pub struct Filter<I, #[derive_no_bound] P> {
    iter: I,
    predicate: P,
}

This however, does not work! Why? Because #[derive_no_bound] on P means that:

The parameter P does not need to satisfy Trait for any field referencing it to be Trait

It does not mean that:

Ignore the field predicate

Therefore, deriving Debug will not work as above since the deriving mechanism of Debug will try to generate an impl which does not work:

impl<I: Debug, P> Debug for Filter<I, P> {
    fn fmt(&self, f: &mut Formatter) -> Result<(), Error> {
        f.debug_struct("Filter")
         .field("iter", &self.iter)
         .field("predicate", &self.predicate) // <-- Not OK!
         .finish()
    }
}

Instead the proper impl:

impl<I: Debug, P> Debug for Filter<I, P> {
    fn fmt(&self, f: &mut Formatter) -> Result {
        f.debug_struct("Filter")
            .field("iter", &self.iter)
            .finish()
    }
}

Adding bounds on field types with #[derive_field_bound]

To gain more exact control of the bounds put on impls generated by deriving macros you can also use the #[derive_field_bound(..)] attribute.

A simple example is:

#[derive(Clone, PartialEq, PartialOrd)]
struct Foo<S, T> {
    #[derive_field_bound]
    bar: Bar<S>,
    baz: Baz<T>
}

This will generate the following impls:

impl<S: Clone, T: Clone> Clone for Foo<S, T>
where Bar<S>: Clone { /* .. */ }

impl<S: PartialEq, T: PartialEq> Clone for Foo<S, T>
where Bar<S>: PartialEq { /* .. */ }

impl<S: PartialOrd, T: PartialEq> Clone for Foo<S, T>
where Bar<S>: PartialEq { /* .. */ }

We can also apply this to a specific trait impl:

#[derive(Clone, PartialEq, PartialOrd)]
struct Foo<S, T> {
    #[derive_field_bound(Clone)]
    bar: Bar<S>,
    #[derive_field_bound(Clone)]
    baz: Baz<T>
}

This will generate the following impls:

impl<S: Clone, T: Clone> Clone for Foo<S, T>
where Bar<S>: Clone, Baz<T>: Clone { /* .. */ }

impl<S: PartialEq, T: PartialEq> Clone for Foo<S, T> { /* .. */ }

impl<S: PartialOrd, T: PartialEq> Clone for Foo<S, T> { /* .. */ }

We can simplify the definition above to:

#[derive(Clone, PartialEq, PartialOrd)]
#[derive_field_bound(Clone)]
struct Foo<S, T> {
    bar: Bar<S>,
    baz: Baz<T>
}

or if we want to do this for all derived traits:

#[derive(Clone, PartialEq, PartialOrd)]
#[derive_field_bound]
struct Foo<S, T> {
    bar: Bar<S>,
    baz: Baz<T>
}

A note on visibility

It is important to note that the following generated impl:

impl<S: Clone, T: Clone> Clone for Foo<S, T> where Bar<S>: Clone { /* .. */ }

only works if Foo<S, T> is at least as visible as Bar<S>. In particular, a Rust compiler will reject the impl above if Bar<S> is private and Foo<S, T> is pub.

Guidance to custom derive macro authors

The concepts in this RFC should be taught to derive macro users, by explaining how the attributes work with derivable traits in the standard library. These are fairly advanced concepts. As such, they should be deferred to the end of the book's explanation of Derivable Traits in the appendix section 21.3.

For users looking to implement custom derive macros, these concepts should be explained in conjunction with guides on how to implement these macros.

Ideally, the syn crate, or crates in the same space such as synstructure, should also facilitate handling of the proposed attributes.

Reference-level explanation

The attributes #[derive_no_bound(..)] and #[derive_field_bound(..)] for controlling how bounds are used by derive macros for standard library traits and should be used for those outside in custom derive macros.

#[derive_no_bound(..)]

Grammar

The attribute #[derive_no_bound(..)] can be placed on type definitions directly (struct, enum, union) or on formal type parameters. The attribute has the following grammar:

no_bound_attr : "#" "[" "derive_no_bound" no_bound_traits? "]" ;
no_bound_traits : "(" trait_list ","? ")" ;
trait_list : ident | ident "," trait_list ;

Semantics - on a formal type parameter

Formally: Assuming a formal type parameter P, and the attribute #[derive_no_bound(Trait)] on P for a given specific trait Trait, specifying the attribute #[derive(Trait)] shall NOT add a bound P: Trait to either the where-clause or directly where P is brought into scope (impl<P: Bound..>) in the impl<.., P, ..> Trait<..> for Type<.., P, ..> generated by a derive macro for Trait. This does not necessarily mean that the field which in some way references P does not need to implement the Trait in question.

When #[derive_no_bound(..)] contains a comma separated list of traits, these semantics will apply to each trait referenced but not other traits.

When #[derive_no_bound] is used (with no traits referenced), these rules will apply to all derived traits.

An example

Given the following type definition:

#[derive(Clone)]
struct Foo<#[derive_no_bound] S, T> {
    bar: Arc<S>,
    baz: T,
}

The generated impl is:

impl<S, T: Clone> // <-- S: Clone is missing
Clone for Foo { /* .. */ }

Semantics - on a type

When #[derive_no_bound(..)] is applied directly on a type, this is equivalent to specifying the identical attribute on each formal type parameter of the type.

An example

Consider a Refl encoding in Rust:

use std::marker::PhantomData;

#[derive(Copy, Clone, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)]
#[derive_no_bound]
pub struct Id<S: ?Sized, T: ?Sized>(PhantomData<(*mut S, *mut T)>);

The generated impls are:

impl<S: ?Sized, T: ?Sized> Copy       for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Clone      for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Debug      for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Hash       for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> PartialEq  for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Eq         for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> PartialOrd for Id<S, T> { /* .. */ }
impl<S: ?Sized, T: ?Sized> Ord        for Id<S, T> { /* .. */ }

#[derive_field_bound(..)]

Grammar

The attribute #[derive_field_bound(..)] can be placed on type definitions directly (struct, enum, union) or on their fields. Note in particular that they may not be specified on variants of enums. The attribute has the following grammar:

field_bound_attr : "#" "[" "derive_field_bound" field_bound_traits? "]" ;
field_bound_traits : "(" trait_list ","? ")" ;
trait_list : ident | ident "," trait_list ;

Semantics - on a field

Formally: Assuming a field F, either named or unnamed, of type FieldType, and the attribute #[derive_field_bound(Trait)] on F for a specific traitTrait, specifying the attribute #[derive(Trait)] shall add a bound FieldType: Trait in the where-clause in the impl<..> Trait<..> for Type<..> generated by a derive macro for Trait.

When #[derive_field_bound(..)] contains a comma separated list of traits, these semantics will apply to each trait referenced but not other traits.

When #[derive_field_bound] is used (with no traits referenced), these rules will apply to all derived traits.

An example

Given the following type definition:

#[derive(Clone, PartialEq, PartialOrd)]
struct Foo<S, T> {
    #[derive_field_bound(Clone)]
    bar: Bar<S>,
    baz: Baz<T>
}

The generated impls are:

impl<S: Clone, T: Clone> Clone for Foo<S, T>
where Bar<S>: Clone { /* .. */ } // <-- Note the where clause!

impl<S: PartialEq, T: PartialEq> PartialEq for Foo<S, T> { /* .. */ }

impl<S: PartialOrd, T: PartialEq> PartialOrd for Foo<S, T> { /* .. */ }

Semantics - on a type

When #[derive_field_bound(..)] is applied directly on a type, this is equivalent to specifying the identical attribute on each field of the type.

An example

Given the following type definition:

#[derive(Clone, PartialEq, PartialOrd)]
#[derive_field_bound(Clone)]
struct Foo<S, T> {
    bar: Bar<S>,
    baz: Baz<T>
}

The generated impls are:

impl<S: Clone, T: Clone> Clone for Foo<S, T>
where Bar<S>: Clone, Baz<T>: Clone { /* .. */ } // <-- Note!

impl<S: PartialEq, T: PartialEq> PartialEq for Foo<S, T> { /* .. */ }

impl<S: PartialOrd, T: PartialEq> PartialOrd for Foo<S, T> { /* .. */ }

Errors

An error should be issued if:

  1. #[derive_no_bound] is specified on a type definition without type parameters.

  2. #[derive_no_bound(Trait)] is specified on a type definition which does not derive Trait.

  3. #[derive_no_bound] is specified on a type definition which does not derive any trait.

  4. #[derive_field_bound] is specified on a type without fields.

  5. #[derive_field_bound] is specified on a field with a type which is less visible than the type which contains the field. If #[derive_field_bound] is applied on the type, then this rule applied for all fields of the type.

  6. #[derive_field_bound(Trait)] is specified on a field of a type definition which does not derive Trait.

  7. #[derive_field_bound] is specified on a field of a type definition which does not derive any trait.

  8. #[derive_field_bound(Trait)] is specified on a type definition and Trait is registered for deriving by a custom macro which specifies #[proc_macro_derive(Trait, attributes(<attr_list>))] where <attr_list> does not mention derive_field_bound. If #[derive_field_bound] is specified instead, then this applies to all traits derived. This also applies to #[derive_no_bound].

Deriving of standard library traits

Deriving any standard library trait will obey the semantics here specified.

Custom derive macros

All custom derive macros as encouraged to follow the semantics here specified so that a consistent experience is maintained in the ecosystem.

Structural equality

RFC 1445 and Rust currently adds the attribute #[structural_match] when a type definition has #[derive(PartialEq, Eq)] on it and all the fields of the type are also #[structural_match].

To use const as the pattern in a match arm, it has to be of a type that is #[structural_match]. If it is not, as in the example below:

fn main() {
    use std::marker::PhantomData;

    pub const BOO: PhantomData<u8> = PhantomData;

    match PhantomData {
        BOO => {}
    }
}

... an error will be emitted saying that:

error: to use a constant of type `std::marker::PhantomData` in a pattern, `std::marker::PhantomData` must be annotated with `#[derive(PartialEq, Eq)]`
 --> src/main.rs:7:9
  |
7 |         BOO => {}
  |         ^^^

With respect to #[structural_match] this RFC does two things:

  1. The "structural match check" will ignore #[derive_no_bound] and #[derive_field_bound].

  2. PhantomData<T> will be defined as:

#[derive(PartialEq, Eq, ...)]
#[derive_no_bound]
#[lang_item = "phantom_data"]
struct PhantomData<T: ?Sized>;

With this new definition of PhantomData<T>, the error above will not be emitted and the example program will be accepted.

This change does not move us from structural matching. A PhantomData<T> can be compared with another PhantomData<T> by doing a memcmp logically. This is so since a zero sized type does not exist in memory and so our logical memcmp would always return true. Thus, two PhantomData::<T>s are structurally equal, and therefore #[structural_match] safely applies. Note however that T != U => ! [PhantomData<T>: PartialEq<PhantomData<U>].

All type definitions with type parameters must use those parameters. In the end, all valid uses of #[derive_no_bound(PartialEq, Eq)] must at some depth involve either ignoring a field in PartialEq, in which case #[structural_match] does not apply, or must involve a PhantomData<T> for which #[structural_match] did apply safely.

Drawbacks

  1. It imposes expectations upon custom derive macro authors which they do not have time for. This can be mitigated by helper crates.

  2. Flexible deriving is a nice-to-have feature but does not enable users to express things otherwise not expressible. Arguably, the now-derivable impls should be implemented manually.

  3. The complexity of the derive system is increased.

Rationale and alternatives

The designs proposed by this RFC aims to make deriving cover impls that are not derivable today. The design has been considered against real world scenarios. Some trade-offs and choices are discussed in the Unresolved questions section.

As with any RFC, an alternative is to say that the status quo is good enough, but for the reasons mentioned in the motivation, steps should be taken to make the derive system of Rust more flexible.

One alternative design of this RFC would be to only permit the form #[derive_bound(<List of traits>, T: <Bound>)] and then call it a day since the form is strictly more general. However, this form is also less automating for a lot of cases.

Prior art

Haskell

The deriving mechanism of Rust was inspired by Haskell, a fact evidenced by the change in RFC 534 where #[deriving(..)] became #[derive(..)].

As Haskell does not have a feature similar to Rust's attributes, it is not possible to configure deriving mechanisms in Haskell. Therefore, there is no prior art there. The features proposed here would be unique to Rust.

The derivative crate

There is some prior art among crates in Rust. The crate derivative provides the ability to customize the deriving mechanisms of derivable standard library traits. We will now discuss the customizations in that crate compared to this RFC.

The attribute form #[derivative(Default(bound=""))] is supported by the #[derive_no_bound] attribute while the more general form is supported by the form #[bound(<List of traits>, T: <Bound>)], which is discussed as a possible extension of this RFC in the Unresolved questions. This more general form is also supported by the serde crate.

Unresolved questions

1. Should #[derive_no_bound] be permitted on fields?

Let's reconsider this example:

#[derive(Clone, PartialEq)]
struct Foo<#[derive_no_bound(Clone)] S,
           T,
           #[derive_no_bound(Clone, PartialEq)] U> {
    bar: Arc<S>,
    baz: T,
    quux: PhantomData<U>
}

We could also permit #[derive_no_bound(..)] on fields as well and reformulate the above snippet as:

#[derive(Clone, PartialEq)]
struct Foo<S, T, U> {
    #[derive_no_bound(Clone)]
    bar: Arc<S>,
    baz: T,
    #[derive_no_bound(Clone, PartialEq)]
    quux: PhantomData<U>
}

This is arguably more readable, but hinges on the semantics that bounds are added by performing name resolution on each field's type and searching for type parameters in those for usage. This behavior, while not very complex to encode using visitors from the syn crate, is not used by derivable traits in the standard library. Therefore, the experience would not be uniform across traits.

Such behavior will also handle type macros poorly. Given the type position macro Foo and type Bar:

macro_rules! Foo { () => { T } }
struct Bar<T>(Foo!())

macros have no way to expand Foo!(). Arguably, using type position macros are rare, but for standardization, a more robust approach is probably preferred. A possibly path ahead is to provide the API proposed in RFC 2320, in which case using the field based approach becomes more robust.

There's also the question of whether interpretations of #[derive_no_bound] on fields is legible and intuitive, which misunderstandings so far during development of this RFC has shown is not unlikely.

2. Should #[derive_field_bound] and #[derive_no_bound] be combinable?

Consider the following snippet:

#[derive(Clone, PartialEq, PartialOrd)]
struct Foo<T> {
    #[derive_field_bound]
    #[derive_no_bound(Clone)]
    field: Bar<T>
}

This could be interpreted as an instruction to provide the following impls:

impl<T> Clone for Foo<T> {..}
impl<T: PartialEq> PartialEq for Foo<T> where Bar<T>: PartialEq {..}
impl<T: PartialOrd> PartialOrd for Foo<T> where Bar<T>: PartialOrd {..}

This is currently not proposed as it is deemed unnecessary, but the mechanism should be considered.

3. Should #[derive_field_bound] be named just #[derive_bound]?

The latter is shorter, but less legible, wherefore we've opted to use #[derive_field_bound] at the moment.

4. Should the attributes not be prefixed with derive_?

Prefixing with derive_ is more legible and reduces the chance of conflict. But it is also more verbose, especially when applied on type parameters. The current thinking is that readability takes precedence over reducing possible verbosity. In any case, prefixing with derive_ is far less verbose than manually implementing the trait.

5. Permit field: Vec<#[derive_field_bound] Arc<T>>?

If so, #[derive_bound] is a more correct name. However, the current thinking is that this requires parsing changes while also looking weird. This may be a step too far - in such cases, manual impls are probably better. For these reasons, the RFC does not propose this mechanism currently.

6. Permit #[derive_bound(<List of traits>, T: <Bound>)]?

Last but not least, the crate serde allows the attribute #[serde(bound = "T: MyBound")] which replaces the where clause of the impl generated by serde. This attribute is described as follows:

Where-clause for the Serialize and Deserialize impls. This replaces any trait bounds inferred by Serde.

We could standardize this concept in the form of an attribute #[derive_bound(..)] put on types with a syntax permitting:

  • Replace bounds on impl of Clone and PartialEq with T: Sync
#[derive_bound(Clone, PartialEq, T: Sync)]
  • Replace bounds on impl of Clone with T: Sync + 'static
#[derive_bound(Clone, T: Sync + 'static)]
  • Replace bounds on all derived traits with T: Copy
#[derive_bound(T: Copy)]
  • No bounds on impl of Clone and PartialEq
#[derive_bound(Clone, PartialEq)]
  • No bounds on impl of Clone
#[derive_bound(Clone)]
  • No bounds on all derived traits:
#[derive_bound]

The syntax TyVar: Bound is however not allowed in attributes currently. Changing this would require a change to the attribute grammar to permit: ident ":" bound.

Another option is to quote the bound as "TyVar: Bound" as done by serde. This requires no larger changes, but is brittle, strange, and would require of syntax highlighters to understand #[derive_bound] specially. Therefore, a more permissible attribute syntax allowing subsets of bounds, expressions and types might be a good thing and can have positive effects elsewhere.

A real world example of how serde's attribute is used is:

#[derive(Debug, Clone, DeserializeState, Hash, PartialEq, Eq)]
#[serde(deserialize_state = "Seed<'de>")]
#[serde(bound(deserialize =
    "T: DeserializeState<'de, Seed<'de>> + Send + Sync + 'static"))]
pub enum List<T> {
    Nil,
     Cons(#[serde(deserialize_state)] ORef<(T, List<T>)>),
}

with #[bound], this is rewritten as:

#[derive(Debug, Clone, DeserializeState, Hash, PartialEq, Eq)]
#[serde(deserialize_state = "Seed<'de>")]
#[derive_bound(Deserialize,
    T: DeserializeState<'de, Seed<'de>> + Send + Sync + 'static)]
pub enum List<T> {
    Nil,
     Cons(#[serde(deserialize_state)] ORef<(T, List<T>)>),
}

7. Permit #[derive_no_bound()] and #[derive_field_bound()]?

If we consider the exact syntax #[derive_no_bound()], there are two interpretations that come to mind:

  1. Equivalent to #[derive_no_bound].
  2. Equivalent to "ignore the bound in an empty set of traits".

The 2nd interpretation is useful for macros, while the 1st may make more sense for a reader, which would just write #[derive_no_bound]. Since the 2nd interpretation is more useful, it is probably more appropriate. To avoid the confusion for users who write this manually, a warning could be issued which macros may supress.

8. Should the errors raised be warnings instead?

Some, or most of the errors in the errors section of the [reference-level explanation] could be warnings instead of errors to facilitate for macro authors. This decision can be deferred to stabilization instead, or even for post stabilization as errors of this kind can be lowered to warnings.