Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For generic structs, apply type bounds in impl rather than requiring on base #91

Closed
TedDriggs opened this issue Apr 25, 2017 · 5 comments

Comments

@TedDriggs
Copy link
Collaborator

TedDriggs commented Apr 25, 2017

If you run cargo expand on this code:

#[derive(Clone)]
pub struct Foo<T>(T);

fn main() {}

You'll see that the generated Clone impl has a type bound requiring that T: ::std::clone::Clone:

#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
pub struct Foo<T>(T);
#[automatically_derived]
#[allow(unused_qualifications)]
impl<T: ::std::clone::Clone> ::std::clone::Clone for Foo<T> {
    #[inline]
    fn clone(&self) -> Foo<T> {
        match *self {
            Foo(ref __self_0_0) => Foo(::std::clone::Clone::clone(&(*__self_0_0))),
        }
    }
}

fn main() {}

This may be possible for the generated builder impl as well: Inherent impl blocks are allowed to have trait bounds beyond what is declared on the base type. Doing so would better align to the standard library and would be slightly more ergonomic.

Implementation Considerations

  1. The Clone type bound should not be emitted when using the owned builder pattern.
  2. The Default type bound should not be emitted for generic fields with an explicit default expression.

Update: Turns out that the compiler is perfectly happy with duplicate type bounds:

// stuff elided...

pub struct Foo<T: ::std::clone::Clone>(T);
#[automatically_derived]
#[allow(unused_qualifications)]
impl<T: ::std::clone::Clone + ::std::clone::Clone> ::std::clone::Clone for Foo<T> {
    #[inline]
    fn clone(&self) -> Foo<T> {
        match *self {
            Foo(ref __self_0_0) => Foo(::std::clone::Clone::clone(&(*__self_0_0))),
        }
    }
}

That makes this quite a bit easier.

Update 2: The compiler makes another simplifying assertion:
It requires all generic type params implement Clone, rather than all field members' types.

#[derive(Clone)]
pub struct Lorem<T, U> {
    ipsum: T,
    sit: bool,
    dolor: Doubler<U>,
}

pub struct Doubler<T>(T);

impl Clone for Doubler<SomeUnstableThing> {
    fn clone(&self) -> Self {
        Doubler(SomeUnstableThing::new())
    }
}

In this code, it requires U: ::std::clone::Clone, rather than adding a where clause which would constrain the Doubler. This is a little surprising to me, but I suspect it makes life easier since it means there isn't a need to determine which fields reference the various generic types.

@TedDriggs
Copy link
Collaborator Author

See rust-lang/rust#26925 for rationale behind behavior of built-in traits. I'm comfortable with that behavior for Clone but not for Default so my fix will be limited to the Clone trait.

TedDriggs added a commit to TedDriggs/rust-derive-builder that referenced this issue Apr 25, 2017
* Builder impl block is now bounded for when generics implement Clone, rather than requiring that declaration on base type
* Updated unit tests in core
* Added integration test in derive_builder/tests
@colin-kiegel
Copy link
Owner

@TedDriggs Ok, cool. :-)

We don't ever emit T: Default bounds for generic builders. This means that we are not be to compile something like foo: T = Default::default() for a generic parameter T. I opened a ticket #93. ^^

@colin-kiegel
Copy link
Owner

colin-kiegel commented Apr 27, 2017

@TedDriggs Can we close this and track the remaining T: Default problem in #93?

EDIT: Or maybe keep it open until the next release... :-)

@TedDriggs
Copy link
Collaborator Author

My inclination is to close it and discuss T: Default in issue #93. There's a "milestone" field for issues that might be useful for tracking that this hasn't shipped yet.

@colin-kiegel colin-kiegel added this to the Unreleased milestone Apr 27, 2017
@colin-kiegel
Copy link
Owner

Released with 0.4.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants