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

Tracking Issue for RFC 2528: type-changing struct update syntax #86555

Open
1 of 5 tasks
joshtriplett opened this issue Jun 22, 2021 · 6 comments
Open
1 of 5 tasks

Tracking Issue for RFC 2528: type-changing struct update syntax #86555

joshtriplett opened this issue Jun 22, 2021 · 6 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-type-changing-struct-update `#![feature(type_changing_struct_update)]` S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@joshtriplett
Copy link
Member

joshtriplett commented Jun 22, 2021

This is a tracking issue for RFC 2528 (rust-lang/rfcs#2528), type-changing struct update syntax.

The feature gate for the issue will be #![feature(type_changing_struct_update)].

There is a dedicated Zulip stream: #project-type-changing-struct-update

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

  • Type inference: when implementing this, we need to confirm that it won't adversely affect type inference.

"Further generalization" in the RFC would be the subject of future RFCs, not something we need to track in this tracking issue.

Implementation history

@joshtriplett joshtriplett added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-type-changing-struct-update `#![feature(type_changing_struct_update)]` labels Jun 22, 2021
@csmoe csmoe added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Jun 23, 2021
@joshtriplett joshtriplett added the S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. label Jul 27, 2022
@joshtriplett
Copy link
Member Author

It looks like this has been implemented; are there any further known issues or blockers with it?

@Rua
Copy link
Contributor

Rua commented Sep 18, 2022

I'm eagerly awaiting stabilisation of this feature! Is there anything that still needs to be done?

@crlf0710
Copy link
Member

crlf0710 commented Sep 18, 2022

It looks like this has been implemented; are there any further known issues or blockers with it?

Yes, i created #101970 to track it

@luojia65
Copy link
Contributor

luojia65 commented Mar 30, 2023

This feature would be useful in bootloader development when different stages of bootloading would handover structures with small modifications. For example, bootstrap module would provide main function like:

fn main(param: Parameters) -> Handover {
    // ....
}

where Handover share most of fields with Parameters, but only small subset of fields are changed in declaration. This will be ideal to express the way Rust ownership works in embedded: one peripheral is wrapped in a structure to show it cannot be initialized or dropped twice. Thus, the wrapper struct should be provided as-is in Handover. We can do like this:

fn main(param: Parameters) -> Handover {
    let serial = Serial::new(param.uart0, /* ... */);
    // ....
    Handover { serial, ..param }
    // instead of: Handover { serial, periph_1: param.periph_1, periph_2: param.periph_2, periph_3: param.periph_3, /* ... */ }
}

We can now avoid repeat passing peripheral fields in bootload stage handovering, where there would typically be dozens of peripheral fields whose ownerships are going to be transfered.

I'll express my idea in playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7fb79bb65cce97cc785b78d9aca1e656

In this way, type changing struct update syntax will have an obvious code size reduction, which will help a lot in embedded development.

@rodrimati1992
Copy link
Contributor

rodrimati1992 commented Mar 30, 2023

@luojia65 This feature is only for changing the generic arguments of the struct, e.g: going from Foo<Bar> to Foo<Baz>.

What you want sound like what's in the Rationales and Alternatives section of the RFC for this feature, except that it doesn't talk about going between structs with an intersection of fields.

@rcywongaa
Copy link

rcywongaa commented Mar 12, 2024

This would work nicely with the arg struct pattern to allow providing default arguments for functions that take closures
i.e.

struct Args<A: FnMut(), B: FnMut()> {
    pub a: A,
    pub b: B,
}

static NO_OP: fn() = ||{};
static DEFAULT_ARGS: Args<fn(), fn()> = Args { a: NO_OP, b: NO_OP };

// -- snip --

let arg = Arg {
  a: || println!("My non-default closure"),
  ..DEFAULT_ARGS
}
func_with_closure_args(arg);

(playground)
(SO question for more context)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-type-changing-struct-update `#![feature(type_changing_struct_update)]` S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants