Skip to content

Tracking Issue for externally implementable items #125418

Open
Open
Tracking Issue for externally implementable items#125418
Assignees
m-ou-sejdonszelmann
Labels
B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-extern_item_impls`#![feature(extern_item_impls)]`T-langRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.

Description

@traviscross
traviscross
opened on May 22, 2024

View all comments

This is a tracking issue for the lang experiment on externally implementable items. This currently covers these proposals:

The feature gate for the issue is #![feature(extern_item_impls)].

Example of how to use what's implemented now

#![feature(extern_item_impls)]

#[eii(eii1)]
pub fn decl1(x: u64) 
// body optional (it's the default)
{
    println!("default {x}");
}

// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
    println!("explicit {x}");
}

fn main() {
    decl1(4);
}

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

  • Which exact alternative or alternatives should we adopt?

Related

Implementation history

cc @m-ou-se @Amanieu @tmandry @joshtriplett

Activity

  1. traviscross
    added
    T-langRelevant to the language team
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).
    F-extern_item_impls`#![feature(extern_item_impls)]`
    I-lang-nominatedNominated for discussion during a lang team meeting.
    on May 22, 2024

  2. m-ou-se commented on Sep 19, 2024

    @m-ou-se
    m-ou-se
    on Sep 19, 2024
    Member

    @jdonszelmann and I are currently implementing this, with a different syntax. Instead of using new syntax (e.g. extern impl fn ...) as in the RFC draft, we're using attributes instead:

    #[externally_implementable(thing_handler)]
fn do_thing();
    #[thing_handler]
fn my_thing_handler() {
    ..;
}

    This has a number of advantages. #[thing_handler] could be replaced by a proc_macro in semver-compatible versions of the crate, so we don't need to worry about providing conversion/upgrade mechanisms. It also makes it look identical to #[panic_handler] and #[global_allocator] attributes. It clarifies the naming and visibility issue: do_thing is the function to call, and #[thing_handler] is the attribute to override it, so they each have their own name and visibility. And it allows us to place unsafe in the attribute itself, to separate "unsafe to implement" and "unsafe to call".

    More updates soon!

  3. m-ou-se
    removed
    I-lang-nominatedNominated for discussion during a lang team meeting.
    on Sep 19, 2024

  4. Amanieu commented on Oct 1, 2024

    @Amanieu
    Amanieu
    on Oct 1, 2024
    Member

    Does this introduce a new global namespace for thing_handler? I would prefer if this was a proper path to an item within a crate since that properly takes care of things like multiple instances of the same crate with different major versions.

  5. m-ou-se commented on Oct 24, 2024

    @m-ou-se
    m-ou-se
    on Oct 24, 2024
    Member

    Does this introduce a new global namespace for thing_handler?

    Nope! It behaves the same as any other attribute (macro), as an item with a path.

  6. nikomatsakis
    moved this to Exploration in Lang team featureson Feb 21, 2025
  7. nikomatsakis
    added this to Lang team featureson Feb 21, 2025
  8. nikomatsakis
    self-assigned this
    on Feb 21, 2025

  9. nikomatsakis commented on Feb 21, 2025

    @nikomatsakis
    nikomatsakis
    on Feb 21, 2025 · Hidden as outdated
  10. nikomatsakis
    assigned
    m-ou-se
    and unassigned
    nikomatsakis
    on Mar 3, 2025

  11. 84 remaining items

  12. rust-timer
    added a commit that references this issue on Jul 15, 2026

    Unrolled build for #158723

    a43f3c2
  13. RalfJung
    added 2 commits that reference this issue on Jul 15, 2026

    Rollup merge of #158235 - cezarbbb:eii-metadata-opt, r=bjorn3

    362becd

    Rollup merge of #158723 - AsakuraMizu:windows-msvc-eii, r=bjorn3

    3d93532
  14. github-actions
    added 3 commits that reference this issue on Jul 16, 2026

    Rollup merge of #158535 - cezarbbb:eii-track-caller, r=bjorn3

    bd42037

    Rollup merge of #158235 - cezarbbb:eii-metadata-opt, r=bjorn3

    29aa91c

    Rollup merge of #158723 - AsakuraMizu:windows-msvc-eii, r=bjorn3

    424bed4
  15. JonathanBrouwer
    added 5 commits that reference this issue on Jul 25, 2026

    Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …

    f17b357

    Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …

    d5eaf28

    Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …

    4472851

    Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …

    d8557d1

    Rollup merge of rust-lang#159783 - AsakuraMizu:safe-eii-unsafe-impl, …

    d80d243
  16. rust-timer
    added a commit that references this issue on Jul 27, 2026

    Unrolled build for #159783

    4fcef24
  17. pull
    added a commit that references this issue on Jul 27, 2026

    Rollup merge of #159783 - AsakuraMizu:safe-eii-unsafe-impl, r=mejrs,J…

    8bf6341
  18. ghaaj
    added a commit that references this issue on Aug 7, 2026

    Auto merge of #146348 - jdonszelmann:eiiv3, r=lcnr,oli-obk

    e2d90d4
  19. flip1995
    added a commit that references this issue on Aug 17, 2026

    Auto merge of #146348 - jdonszelmann:eiiv3, r=lcnr,oli-obk

    047190a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-extern_item_impls`#![feature(extern_item_impls)]`T-langRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions