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

Could Default be implemented for Field? #234

Open
misos1 opened this issue Jun 2, 2024 · 2 comments
Open

Could Default be implemented for Field? #234

misos1 opened this issue Jun 2, 2024 · 2 comments

Comments

@misos1
Copy link

misos1 commented Jun 2, 2024

So it would be possible to use lift_from and lift_into also with labelled generic.

@lloydmeta
Copy link
Owner

I'm not sure I understand how this could be implemented in a way that could be useful in the LabelledGeneric context.

Can you please either elaborate or send a PR with a test showing your proposal in action?

@misos1
Copy link
Author

misos1 commented Jun 4, 2024

I had in mind something like reverse transform_from where subset can be transformed into superset while filling the rest from default, something like this:

#[derive(LabelledGeneric, Default, Debug)]
struct A {d: i8, b: String, c: f32, a: i32}
#[derive(LabelledGeneric, Default, Debug)]
struct B {a: i32, b: String}
let (_, remainder): (<B as LabelledGeneric>::Repr, _) = into_labelled_generic(A::default()).sculpt();
let a: A = from_labelled_generic(into_labelled_generic(B {a: 1, b: "2".into()}).extend(remainder).sculpt().0);

Maybe transform_from and transmogrify could support that or there could be some other more "general" versions of these functions for that. And maybe there could be something which can flatten or unflatten nested structs. (Or even transform between structs where one is not a subset of another but they have just some common fields like struct A {a: i32, b: f32} and struct B {c: u8, a: i32}.)

Also maybe if the associated type for IntoLabelledGeneric trait was named little differently than Repr like for example IntoRepr then there would not be this clash and need to specify B as LabelledGeneric here. I also noticed that I can call sculpt on any struct X and it just returns (HNil, X), I wonder if this is functionally needed for something to work? Why is implementation for empty target (impl<Source> Sculptor<HNil, HNil> for Source) not specific about Source to be just HNil and nothing else to avoid such clutter? - Oh I see why it is in such a way, but maybe Source could be at least bound to the HList trait.

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

No branches or pull requests

2 participants