RFC: enable derive(From) for single-field structs

[Kobzol]

Previously discussed as Pre-RFC on IRLO.

Rendered

[clarfonthey]

Fully in support of this. A few things that probably should be elaborated:

• Generic single fields
• Transparent structs with extra zero-size fields like PhantomData

The transparent case, IMHO, is probably best left as a future extension, but it's an interesting case where Default impls on the extra fields would not be needed.

[Kobzol]

Fully in support of this. A few things that probably should be elaborated:

• Generic single fields
• Transparent structs with extra zero-size fields like PhantomData

The transparent case, IMHO, is probably best left as a future extension, but it's an interesting case where Default impls on the extra fields would not be needed.

PhantomData implements Default unconditionally for any T, so that would be fine. I agree it's best to leave it for "later" though.

Good point with the generics, I'll add a mention to the RFC.

[kennytm]

"For later" - perhaps it could recognize #3681 fields and automatically skip them as well.

#[derive(From)]
struct Foo {
    a: usize, // no #[from] needed, because all other fields are explicitly default'ed
    b: ZstTag = ZstTag,
    c: &'static str = "localhost",
}

// generates

impl From<usize> for Foo {
    fn from(a: usize) -> Self {
        Self { a, .. }
    }
}

OTOH we may still want the #[from] in the above case for uniformity if we want to support #[derive(From)] on all fields being defaulted

#[derive(From, Default)]
struct Foo2 {
    #[from] // <-- perhaps still want this
    a: u128 = 1,
    b: u16 = 8080,
}

[nielsle]

The crate named derive-new creates a new constructor, and it has several fancy options.

But perhaps this functionality belongs in a third party crate rather than the standard library.

[teor2345]

It might be worth noting here that impl From<Newtype> for Inner and impl Into<Inner> for Newtype have slightly different semantics. Using derive(Into) to mean impl From could be confusing for generic types where there is a coherence issue, even if it does imply an Into impl.

(I've had similar issues with the derive_more version.)

[kennytm]

the derive-macro's name does not necessarily correspond to the impl'ed trait name anymore since #3621 (currently named #[derive(CoercePointee)], which actually does impl CoerceUnsized + DispatchFromDyn.)

[Kobzol]

The #[derive(Into)] example is kind of hand-waving, I'm not sure if it's actually a good idea. I would like to avoid doing that in this RFC though, as that sounds like a separate can of worms, I explicitly tried to keep this RFC as simple as possible.

[teor2345]

the derive-macro's name does not necessarily correspond to the impl'ed trait name anymore since #3621 (currently named #[derive(CoercePointee)], which actually does impl CoerceUnsized + DispatchFromDyn.)

Understood! But my comment was more about the confusing semantics, than the exact name of the impl'd trait.

[tmccombs]

Honestly, for the impl From<NewType> for Inner case, I think I would prefer something like impl_from!(Newtype -> Inner) or a more generic impl_from!(Newtype -> Inner = |source| source.0) or impl_from!(Newtype -> Inner = self.0) (restricted to using fields of NewType)

Although it is a little annoying, to have to repeat the type of Inner.

[kennytm]

But my comment was more about the confusing semantics

I don't think there is any name more appropriate than #[derive(Into)] especially if this RFC is using #[derive(From)]. The final effect you get is still having an impl Into<Inner> for Self effectively, through the intermediate impl From<Self> for Inner + the blanket impl.

See JelteF/derive_more#13 for a brief discussion how derive_more still chooses to name it #[derive(Into)].

[joshtriplett]

I'd love to have a derive in the other direction, but full support for making that future work and not part of this RFC.

[Kobzol]

The crate named derive-new creates a new constructor, and it has several fancy options.

But perhaps this functionality belongs in a third party crate rather than the standard library.

While new constructors are pretty common, I would say that it's too opinionated for it to be included in the stdlib, as it's not a standard (library) trait like From is. In any case, that would be a separate RFC :)

[joshtriplett]

I think this proposal makes sense as written, and it's simple and straightforward.

Should we allow derive(From) on single-field structs, to impl From<FieldType> for Struct?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[matthieu-m]

A better alternative might be to support generating the other direction in the future through something like #[derive(Into)].

I very much encourage distinct syntax for distinct directions.

In particular, as noted in the Email(String) example, newtype wrappers are regularly used to enforce invariants, in which case the #[derive(From)] implementation is outright wrong.

On the other hand, going back to the inner type should never violate any invariant, and therefore #[derive(Into)] makes perfect sense for Email.

[scottmcm]

Unsure: is this really lang, @joshtriplett? It's an impl that could be done in a stable proc macro crate, AFAICT, which to me says that it's entirely libs-api (even if in actual implementation it'd be done inside the compiler today).

---

Personally I'm not concerned with "well this From might be wrong", because correctness is up to the caller to do properly (like how today derive(Clone) might be wrong if you're holding pointers or how derive(Hash) might be wrong if you implemented PartialEq manually.) I think in a hypothetical future with unsafe fields then perhaps this should fail, but that's not something this RFC would need to mention because there's no accepted RFC for that yet. (Though if it wanted to discuss that as future possibilities that would be nice-to-have.)

[traviscross]

As a comparable, we handled RFC #3107 (#[default]) as a dual lang/libs-api FCP. Probably I think that makes sense here as well (e.g., it maybe leads to #[from]). This perhaps touches on general "flavor of the language" matters, and also raises for us questions about whether we might like to solve the motivation here in some other language-directed way.

@rfcbot fcp cancel
@rustbot labels +T-libs-api

[rfcbot]

@traviscross proposal cancelled.

[traviscross]

@rfcbot fcp merge

(And I'll recheck the box for Josh.)

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• from-impl-direction-grander-picture (RFC: enable derive(From) for single-field structs #3809 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[scottmcm]

(quoting @BurntSushi above)

I find I am mostly convinced by #3809 (comment).

TBH, while I don't disagree with what I wrote earlier, the arguments about which direction of from is more useful does seem relevant to me.

If I have

#[derive(From)]
pub struct Even(u32);

Then the impl From<u32> for Even { … } is just wrong, but the impl From<Even> for u32 { … } would be correct and useful! The constructor-from is relatively rare and would often be wrong, where as the destructor-from is appropriate unless the newtype really needs to hide the internals. (But even if you're making a box-like type where From<MyBox> for *const () is probably a bad idea, it's probably at least not unsound the way that From<*const ()> for MyBox would be.)

Thus it does feel odd to me that we'd add this RFC's less-applicable case without having something for the more-applicable case (aka the derive(Into) or something). And if this isn't that common, it makes me wonder if it should be derive(FromInner) or something to allow potentially other meanings of derive(From) in future that would be more commonly applicable.

I also think this can just be a libs-api FCP.

I would be perfectly happy for libs-api to take over the FCP and thus I not have to decide one way or the other 🙃

[Kobzol]

The constructor-from is relatively rare

I think that depends a lot on your use-cases. In terms of the code I write, I use newtypes without additional invariants for something like 90% of use-cases. PullRequestId, UserId, TaskId, WorkerId, I almost always just need literally a new type, without any invariants. That's the case where this derive helps the most.

I agree that the other direction is also very useful, but I don't think we need to resolve that in this RFC, unless you can imagine a situation where #[derive(From)] would actually generate the other direction. Do you think that's feasible? (I don't, as it would behave in a completely way than all other built-in derives).

[scottmcm]

I guess looking at #3809 (comment) all of libs-api has checked their boxes, so I'll just abstain to allow their decision to land, and if they end up concerning anything because of discussion, that's up to them.

@rfcbot abstain

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tmandry]

Meh, I share the concerns raised by @RalfJung, @BurntSushi, and @scottmcm.

On one hand I want "obvious" things like this to make newtypes better. On the other, I'm not sure it meets that bar because many newtypes don't actually want this, and it takes up a big slice of linguistic space we could potentially redistribute to other meanings. Sometimes you want the inverse From impl (and only that one), sometimes you want both; sometimes you want Into because of orphan rules, etc.

Personally I'd rather see a slightly more "maximalist vision" that this fits into as a first step. That could take the form of a more expansive future possibilities section that covers the situations I listed above (or reasons why we shouldn't cover them).

EDIT: I could be convinced there are a bunch of newtypes out there where this derive is idiomatic and a good tradeoff. In my code it usually is not. One point I'll make in favor of the RFC is that this behavior seems like the most obvious one by far for #[derive(From)] with nothing else.

[tmccombs]

I agree that it would be nice to have the other direction as well, but I would find it very surprising if derive(From) created an impl for a struct other than the on it is an attribute for. derive(Into) is a little bit better, but it still seems surprising that it doesn't add an impl of Into, and then it prevents deriving tne Into trait itself in situations where that is necessary. Maybe, we could use derive Into, with an additional attribute to indicate Into is implemented indirectly by implementing From on the inner type. But then the more common case is more verbose, which doesn't seem great.

I wonder if instead of using the existing derive attribute, it would make more sense to create a new attribute for a generalization of this, where if you have a generic trait with a single type paramater, like A<T>, then something like #derive_on(C, A) on a type B could mean "derive an impl A<B> for C". Name subject to bikeshedding of course. Although that adds complexity, and would probably mean adding support for a different kind of derive macro (or maybe just pass some additional metadata to existing derive macros?).

Alternatively, it could use a derive macro with a new name that doesn't correspond to an existing trait.

[Kobzol]

Meh, I share the concerns raised by @RalfJung, @BurntSushi, and @scottmcm.

On one hand I want "obvious" things like this to make newtypes better. On the other, I'm not sure it meets that bar because many newtypes don't actually want this, and it takes up a big slice of linguistic space we could potentially redistribute to other meanings. Sometimes you want the inverse From impl (and only that one), sometimes you want both; sometimes you want Into because of orphan rules, etc.

Personally I'd rather see a slightly more "maximalist vision" that this fits into as a first step. That could take the form of a more expansive future possibilities section that covers the situations I listed above (or reasons why we shouldn't cover them).

EDIT: I could be convinced there are a bunch of newtypes out there where this derive is idiomatic and a good tradeoff. In my code it usually is not. One point I'll make in favor of the RFC is that this behavior seems like the most obvious one by far for #[derive(From)] with nothing else.

I think this RFC got bogged down with newtypes too much. It's just one use-case, but this derive is a general tool, used to reduce boilerplate for trivial From impls. Nothing less, nothing more. Some other derives can also be semantically wrong, but that's not the compiler's/language's concern (IMO).

I understand the desire to also explore the other direction of the impl, but I'd like to keep the RFC minimal, as I think that it stands on its own and it is useful even without the other direction (otherwise I wouldn't propose it). The only reason why it should be necessary to decide what to do about the other direction in this RFC would IMO be if the proposed derive was not forward compatible. Do you see that as being the case? I think that based on the current derives, we can't "afford" for derive(From) to do anything else than what I proposed here. We could still add derive(Into), derive(From(inner)) or something like that later, I just don't see how this proposal could not be forward compatible with these changes.

[RalfJung]

Single-field types are newtypes, so I don't see how this derive can be used for anything else?

[Kobzol]

I wouldn't classify it in that way. The newtype pattern is a (design) pattern; these always describe some motivation for why they are being used. For the newtype pattern, the motivation is to introduce a new element in the type system that is backed by an existing data type, to distinguish them in the type system even if they have the same in-memory representation. Potentially you can also add additional invariants to the inner data type (I'd argue these are two different patterns with different use-cases, which is also a part of the opposing viewpoints in this RFC, where some people use newtypes for the invariants, but others use it only for adding a new type system element).

But you can have code that looks in that exact same way (single-field struct), but it does not uphold the pattern, because it has a different motivation. This is also known from the classical GoF patterns, where multiple patterns can have exactly the same code signature, but different motivation for why they are being used. Sometimes a single-field struct is just a single-field struct, and you are not creating it for the reason of introducing a new element in the type system.

For example, recently I had a use-case where I had a struct with a lot of fields, and I wanted to have the option to use the struct literal constructor to initialize these fields (to avoid a new function that has 15 parameters), but I also didn't want these fields to be pub, because I needed them to be read-only after initialization. I solved it by wrapping that struct in another tuple struct, like this:

struct Config { paramA, paramB, paramC }

struct ReadOnlyConfig(Config);

let config = ReadOnlyConfig::from(Config { paramA: 1, paramB: 2, paramC: 3 }));

The motivation here was not to distinguish these two types in the type system, nor to add any invariants. I just wanted to combine struct literal initialization with private access to the fields.

(btw: #[derive(From)] would be quite useful here :) )

[RalfJung]

I would argue in that case you want to distinguish Config and ReadOnlyConfig in the type system, so I'd still call this a newtype. 🤷

---

But anyway, the real question is whether the way you use newtypes is common enough to justify this extension. The way I use the language, I don't think I'd use this feature more than once in a blue moon, and others have raised similar concerns.

In the RFC, you give evidence for this:

• There is this code search. A significant fraction of the results are for enums or multi-field structs though, so those have to be discounted. (I have no idea what this even does on a multi-field struct, but that does seem to be a thing.) But, most of the pages in the search result seem to have at least one single-field struct in it, so that's still on the order of 1k uses in the ecosystem.
• And then there's "In the analyzed 168 crates, 559 single-field tuple structs were found, and 49 out of them contained the From implementation from their field type." 49 occurrences in 168 crates does not strike me as a evidence for this being super common (the vast majority of single-field structs do not have a From). But, it's also not nothing.
• It does turn out we use newtypes like this in rustc, at least some of the time.

I don't have a good sense for how much potential use is "enough" to justify this as a core language feature. I admit this is already a lot more than I expected.

---

One point I'll make in favor of the RFC is that this behavior seems like the most obvious one by far for #[derive(From)] with nothing else.

Yeah, that's a good point. If we do eventually want to have a derive for the other direction (which I'd find a lot more useful), it would probably be quite confusing to call that derive(From)...

[Kobzol]

to justify this as a core language feature

This is overselling it a bit, I think. Even t-lang said that they don't consider this to be a big lang deal, and it's mostly "just" a t-libs-api concern. I view this as filling a gap in the combination of two existing features (derive and built-in traits), rather than introducing a new feature.

Anyway, the FCP has started, if someone wants to register formal complain, there's still time :)

[RalfJung]

Yeah fair, a core library (as in, libcore) feature would have been more accurate. :)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[BurntSushi]

Oops, I meant to register a concern here to reflect discussion above. Not sure if it's too late, but I'll try anyway.

@rfcbot concern from-impl-direction-grander-picture

[Kobzol]

Hmm, I wonder if this won't confuse the hell out of rfcbot :) No problem with the timing though, we can just delay merge or restart the FCP later.

Could you please clarify a bit on how would you like the end state of this RFC to look like? This RFC describes a complete (well, I hope, it looks simple, but maybe we'll run into some impl issues) design for From in direction A. I could add more thoughts about From in direction B to it, but unless we determine a final design that will incorporate both directions, it will be just hand-waving that might never get implemented or that will get changed anyway once/if we create a RFC for direction B. So I don't see much point in doing that just for the sake of it.

From my point of view, we can either:

1. Determine that #[derive(From)] does the obvious thing, and we don't see a way how it could not be forward-compatible, so we accept it and let it progress without blocking on the other direction. Or:
2. Determine a design for both directions at once, so that we are (almost) sure that there won't be any forward compatibility issues with the other direction. If we find that direction B is too hard to resolve or has too many trade-offs, we can go back to 1), or decide that we don't want to go forward with neither A nor B.

Please let me know if you want me to do 2), or if you want something else :)

[tmandry]

As I think about it more, it seems clear to me that we should support both derive(From) and derive(Into). The Into derive should actually write an impl of From in the inverse direction. (This is a strict superset of an Into impl in the expected direction unless you target an MSRV prior to 1.41, in which case you need to write the impl manually anyway.)

This vision seems small, clear, and interrelated enough that I would prefer to decide on it together, but this RFC is far along enough that it doesn't seem worth changing the scope. Given that, a future possibilities section for derive(Into) would be enough to resolve my part of the concern.

Unresolved questions
Direction of the From impl

Just noticed this and now I have a procedural concern: I don't see any reason an RFC should leave such a fundamental question unresolved! The RFC should resolve it instead of deferring more fundamental design discussion to stabilization. I think it should pick the direction it's written with; in other words, I think this section should be removed (EDIT: or moved to "rationale and alternatives").

[Kobzol]

Do you want me to keep "Generating From in the other direction" in the "Rationale and alternatives" section, or also remove it from there?

[Kobzol]

Moved the discussion of the From direction to Rationale and alternatives, and briefly mentioned #[derive(Into)] as a future possibility.