Newtype deriving

[aochagavia]

Rendered

See also the discussion on rust-lang/rust#19597

cc @aturon @huonw

[abonander]

These wrapper types are tuple structs, and tuples already have default implementations for all the ops. The auto-derived impls for ops on tuple structs could trivially be implemented in terms of regular tuples, though it would need a lot of the same machinery and would only differ in the method bodies, unless there is a way to make a tuple struct desugar to a regular tuple.

[reem]

There are a lot of edge cases not covered by this RFC - what about traits which make references to Self? This can cause a lot of problems which are difficult to resolve - for instance, how is an implementation for Clone generated (a simple case, but others are not as simple)? What about a trait which has an associated type bounded with SomethingMentioning<Self>?

[abonander]

Another thought: since macro syntax supports patterns, the boilerplate of implementing ops for tuple structs could trivially be implemented as a contextual macro. I'll work on an example later.

Though, deriving the ops for a struct where its fields implement the op in question should work the same way as how the rest of the derivable traits are implemented, though it would have to assume a RHS and Result of Self.

[pnkfelix]

See also discussion on RFC #186 , which was postponed with tracking issue #261 (the titles of both are a little bit misleading; its not just about a keyword, but rather about feature much like the one described here).

(Update: of course this is slightly different, in that it is proposing leveraging the macro/attribute system to derive the desired implementations here, which is more along the lines of what I wanted to see happen for the "newtype" feature request.)

[aochagavia]

@reem Could you give a concrete example of a problem when a trait refers to Self?

Clone is actually an easy one. As of today, you can write #[deriving(Clone)] and it just works. This RFC won't change that.

UPDATE: I see now that the implementation of traits with generic arguments is not trivial as I thought when I wrote the RFC. I will think about it and try to improve the description of the design.

[aochagavia]

@cybergeek94 Are you sure tuples already have default implementations for all the ops? It doesn't seem to work for me.

[Manishearth]

@aochagavia I and @eddyb came across issues with Self traits in our auto_deriving design. There are a bunch of caveats in the RfC which we used to restrict what could be autoderived, applying those will make your problem easier but then it's also not so useful.

Restricting the RfC to the ops works as well.

[Manishearth]

Show can be derived via #[deriving(Show)]

[aochagavia]

While this is true, maybe you are only be interested in the wrapped value (e.g. showing "2.0" instead of "Centimeters(2.0)"). In that case it is useful to be able to derive Show.

[alexcrichton]

Thanks for the PR @aochagavia! As @pnkfelix mentioned this issue is currently being tracked in #261 for the concept of having a newtype also export all of the underlying traits. At this time features like this sadly aren't making the cut for 1.0 as we're trying to stabilize the language and the libraries in preparation.

I'm going to close this RFC for now, but I encourage you to continue discussion on the issue if you'd like so we can hopefully reach a solution for this after 1.0. Thanks again for taking the time to write this up though!