Newtype support about auto_impl HOT 9 CLOSED

Oh wow, it's been a while. I wonder what happened to that side-project and where I left it 😅

from auto_impl.

Hi there! Certainly an interesting idea!

When it comes to the blanket impl with the From<T> + Deref<Target = T> trait bounds, it has the same disadvantage as the blanket impl for F: Fn(...) we currently use for closures. Namely, that no other impls are allowed (with specializations, some others are allowed, but it's still pretty restricted). So I actually don't think that such an impl would be really useful. In particular, hardly useful before specialization is stable.

On the other hand, I could certainly imagine having user-defined/arbitrary types. Like #[auto_impl(Box, MyType)]. But there are a few problems with this: how do we access the inner type? Most newtypes just look like struct Foo<T>(T) so we could use .0 to access the actual type. But that doesn't always work. So maybe require all newtypes to implement Deref and potentially DerefMut? Two more problems with that: (a) many newtypes shouldn't implemented the Deref traits as that partially destroys the advantages gained by creating a newtype in the first place, and (b) what about moving out of the newtype? With .0 we could move out of it and thus also automatically implemented methods with a self receiver. If we go the Deref path, we cannot. Additionally, how do we know if DerefMut is implemented (and thus if we can implement methods with &mut self receiver)? We can't check this in the proc macro so the user would have to specify that.

So one could imagine giving the user a bunch of syntax to configure the impl for the newtype. Like #[auto_impl(custom(MyType, & = deref, &mut = deref_mut))] or something like that. Letting the user specify how the inner type can be accessed.

But, and I mentioned this before somewhere, I think this crate shouldn't be complex enough to suite every use case. I think this is a 95%-of-cases crate. Having to learn a new syntax on how to specify the inner type accessors for my newtype is not really worth it IMO. In that case it's usually faster to just write the impl yourself.

So all in all, I'm absolutely not sure yet if this is a useful feature in this crate. I can see the use cases, but I can't think of a solution that is really useful and does not raise the complexity of this crate by much.

And just in case you didn't know those: there is newtype_derive and derive_more. But yes, those won't help with your own traits.

from auto_impl.

And just in case you didn't know those: there is newtype_derive and derive_more. But yes, those won't help with your own traits.

Yes, I know about them, but I want something that would work for own traits. Newtype pattern is pretty much the standard solution for implementing extra third-party traits on third-party types while at the same time doesn't give any machinery to forward existing trait implementations, and crate like this one could solve that easily. I wanted to implement such macro myself, but found out about this crate literally yesterday and wanted to ask if we could join forces first so that I don't have to reimplement everything from scratch :)

But there are a few problems with this: how do we access the inner type? Most newtypes just look like struct Foo(T) so we could use .0 to access the actual type. But that doesn't always work. So maybe require all newtypes to implement Deref and potentially DerefMut? Two more problems with that: (a) many newtypes shouldn't implemented the Deref traits as that partially destroys the advantages gained by creating a newtype in the first place, and (b) what about moving out of the newtype? With .0 we could move out of it and thus also automatically implemented methods with a self receiver. If we go the Deref path, we cannot. Additionally, how do we know if DerefMut is implemented (and thus if we can implement methods with &mut self receiver)? We can't check this in the proc macro so the user would have to specify that.

These are all good questions I've been thinking about too. But, as you said, this crate doesn't have to try to accomodate every possible case, so I'd go with the simplest solution supporting just newtypes implementing Deref + DerefMut + bidirectional From, which should allow calling any methods and would still covert 90% of usecases - in my experience, more often than not newtypes are created just to work around coherence rules and implement third-party trait for another third-party type and not to hide the internal value.

Also, as I already mentioned above, these constraint would already cover smart pointers, so this crate won't even have to deviate much from its original goal, it would just become more generic and extend to more types with the same generated code.

from auto_impl.

Newtype pattern is pretty much the standard solution for implementing extra third-party traits on third-party types [...]

Orphan rules ... 😒

join forces first so that I don't have to reimplement everything from scratch

That sounds like a good idea!

So right now, we're trying to get a new version of this crate uploaded to crates.io. This is the priority for now and should be done soonish. After that, I didn't plan on working on this crates as much anymore (so many other projects :<). But I'm still here for code review and discussing potential features.

Could you write down your exact proposal with a bit more details? In particular, are you suggesting generating a blanket impl (for T) or somehow use the name of the wrapper type? It's probably best if you just give an example of the written code and what code would be generated.

And it would be worth collecting a list of use cases for newtypes. The orphan rule solution might be a big one, but I think there are a few other important use cases as well.

from auto_impl.

I could play on a fork and make a PR if that helps?

from auto_impl.

Sure, if you already want to play with the code: go ahead. I thought about first discussing what we want, but already trying things out can help a lot! However, please don't invest a lot of time in implementing a solution you like without talking with us about that solution beforehand. Just in case we don't agree with the solution, we don't want you to waste your time :)

from auto_impl.

Well in the worst case I can always go back to original plan and publish it as a separate crate later in case our views don't align. For now just trying to solve some specific cases I run into in myself all the time.

from auto_impl.

Coming back through some triage. In the intervening years the impl-tools project has sprung up which I think should support this use-case through its more programmatic #[autoimpl] syntax.

from auto_impl.

Come back to it 4 years later and close all the issues in the name of “triage”.

from auto_impl.