I'm researching best approach for writing business app code like typically done in JVM languages etc. I'm not a fan of OOP, and I really dislike SpringBoot style automagic DI. However abstracting away external components behind an interface, and constructor-passing DI are really great for larger apps.

In the past when doing trait as an interface for multiple implementations for DI, I would go for type SharedConnection = Arc<dyn Connection + Send + Sync + 'static>) kind of thing, and I'm happy to finally find a crate that can get rid of some of that boilerplate.

However not long ago, I've read https://jmmv.dev/2022/04/rust-traits-and-dependency-injection.html#good-solution-newtype, and I think a NewType is even better, it's just I never wanted to put an effort writting out all that stuff.

Would supporting this pattern fall under the goals of this crate?

Going even further, I wonder if supporting things like struct Newtype(Arc<RwLock<dyn Trait + Send + Sync + 'static>>) would be possible.

I tried the following with autoimpl. Note that MyGreatType doesn't implement Deref.

use impl_tools::autoimpl;

struct MyGreatType<T: ?Sized>(Box<T>);

#[autoimpl(for<T: trait + ?Sized> MyGreatType<T>)]
trait MyGreatTrait {
    fn my_great_method(&self);
}

I got the following error:

or[E0308]: mismatched types
 --> src/main.rs:7:25
  |
5 | #[autoimpl(for<T: trait + ?Sized> MyGreatType<T>)]
  | --------------------------------------------------
  | |              |
  | |              this type parameter
  | arguments to this function are incorrect
6 | trait MyGreatTrait {
7 |     fn my_great_method(&self);
  |                         ^^^^ expected type parameter `T`, found struct `MyGreatType`
  |
  = note: expected reference `&T`
             found reference `&MyGreatType<T>`
note: associated function defined here
 --> src/main.rs:7:8
  |
7 |     fn my_great_method(&self);
  |        ^^^^^^^^^^^^^^^

While this is far from the worst error message you could give here, I think it could be better. For example, when rustc encounters a missing trait bound, like here:

use std::ops::Deref;

struct MyGreatType<T: ?Sized>(Box<T>);

trait RequiresDeref: Deref {}

impl<T> RequiresDeref for MyGreatType<T> {}

It gives a super helpful error message:

error[E0277]: the trait bound `MyGreatType<T>: Deref` is not satisfied
 --> src/main.rs:7:9
  |
7 | impl<T> RequiresDeref for MyGreatType<T> {}
  |         ^^^^^^^^^^^^^ the trait `Deref` is not implemented for `MyGreatType<T>`
  |
note: required by a bound in `RequiresDeref`
 --> src/main.rs:5:22
  |
5 | trait RequiresDeref: Deref {}
  |                      ^^^^^ required by this bound in `RequiresDeref`

It'd be great if autoimpl could report something like that.

Summary The #[cfg(..)] attr is used to conditionally compile something. If a trait item is conditional, then its re-implementation should be too.

Are there any other attrs which should be forwarded?

To Reproduce

#[impl_tools::autoimpl(for<T: trait> &T)]
trait MyTrait {
    #[cfg(feature = "foo")]
    fn do_foo(&self);
}

There are instances in the std library where a Debug implementation forwards to a single field, e.g. the impl for File. We don't currently support forwarding for Debug, but I think we could support this, e.g.:

# use impl_tools::autoimpl;
#[autoimpl(Debug using self.0)]
struct Thing<T: std::fmt::Debug>(T);

PR adds:

• Attrs expanded by impl_scope now require an explicit grouping token, just like #[proc_macro_attribute]
• impl_default now supports a where clause

Changelog for 0.2.0:

• Added impl_scope!
• Added #[impl_default]

A new macro ported from kas-macros:

use std::fmt;
fn main() {
    let world = "world";
    let says_hello_world = impl_tools::singleton! {
        struct(&'static str = world);
        impl fmt::Display for Self {
            fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
                write!(f, "hello {}", self.0)
            }
        }
    };
    assert_eq!(format!("{}", says_hello_world), "hello world");
}

Something like this:

#[autoimpl(for<T: trait> &T)]
trait Foo {
    /// A useless method
    fn foo();
}

previously expanded to this:

#[automatically_derived]
impl<T: Foo> Foo for &T {
    /// A useless method
    fn foo() {
        <T as Foo>::foo()
    }
}

The doc-comment should definitely not be copied to the impl, nor should other attributes such as #[inline].

Generic associated types are merged into rustc nightly, and assuming no further issues will reach stable at 1.65.0.

This PR fixes support for GATs (and also attributes on trait consts/methods/types). This PR does not depend on nightly or 1.65.0, but adds an extra test which is only run on rustc ≥ 1.65.0.

#[autoimpl] is revised for extensibility. Some revisions to extensibility of impl_scope!.

README and CHANGELOG updated.

Pending some testing, this is ready to go for v0.3.

This is part 1 of 2 (part 2 will revise #[autoimpl]). Changes:

• Move implementation to a new crate, impl-tools-lib, and revise the API slightly. This allows users to write their own versions of impl-tools to supporting whichever #[autoimpl] trait rules and impl_scope! attribute rules they choose.
• New ScopeAttr trait as the basis for impl_scope! attribute rule plug-ins.
• More documentation.

This does not use valid Rust syntax for field initialisers, nevertheless it works within impl_scope:

impl_scope! {
    #[impl_default]
    struct Person {
        name: String = "Jane Doe".to_string(),
        age: u32 = 72,
        occupation: String,
    }
}

TODO: some tidy up of this PR before merging.

Currently #[autoimpl] supports three modes of operation:

1. On structs, impl traits targetting many fields (e.g. Clone, Debug)
2. On structs, impl traits targetting one field (e.g. Deref)
3. On traits, impl for certain types supporting Deref to another type which supports the trait

Each has special syntax: (1) supports ignore self.a, self.b; (2) supports using self.foo; (3) supports for<'a, T>.

Now, derive(Clone) etc. supports enums. This has nothing to do with derive and everything to do with the impl for Clone, which uses a low level interface. #[autoimpl] uses a much higher-level interface, such that we parse the target struct/trait and confirm fields mentioned by ignore / using exist before even touching code specific to Clone, Deref etc.

So, the question is, if we let #[autoimpl] support enums, then what syntax should be supported and what restrictions should we have?

E.g. should we support ignoring like this?

#[autoimpl(Debug ignore self.1)]
enum X {
    A(i32, ()),
    B(f32, ()),
}

If so, should we require that each enum variant has a tuple form such that self.1 is valid?

Should we support this, where fields mentioned by ignore may not apply to all variants?

#[autoimpl(Debug ignore self.x, self.y)]
enum E {
    A,
    B(i32),
    C { a: i8, x: () }
    D { a: u8, y: () }
}

Should we allow this?

#[autoimpl(Deref using self.foo)]
enum Y {
    A { foo: Foo },
    B { foo: Foo, x: f32 },
}

And thus this (custom Target syntax is supported by #26):

#[autoimpl(Deref<Target = Foo> using self.foo)]
enum Y {
    A { foo: A }, // require: A: Foo
    B { foo: B, x: f32 }, // require: B: Foo
}