Tracking Issue for externally implementable items

[traviscross]

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

• [RFC] externally implementable functions rfcs#3632
• [RFC] externally definable statics rfcs#3635
• Externally implementable traits rfcs#3645
• RFC: Existential types with external definition rfcs#2492

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

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

• Get alternate proposals.
  • Original proposal from @m-ou-se. [RFC] externally implementable functions rfcs#3632
  • Alternative proposal from @m-ou-se. [RFC] externally definable statics rfcs#3635
  • Alternative proposal from @Amanieu. Externally implementable traits rfcs#3645
  • Alternative proposal from @tmandry. [RFC] externally implementable functions rfcs#3632 (comment)
• Pick a design for the experiment.
  • Using attributes rather than new syntax: Tracking Issue for externally implementable items #125418 (comment)
• Implement the experiment.
  • First fix attributes so we can do name resolution in them: Attribute handling reworks compiler-team#796 (In progress!)
  • Implement externally implementable items using attributes. (In progress!)
• Verify proposals are consistent with:
  • Unsafe Extern Blocks rfcs#3484
• Write/update RFC based on experiment.
• Accept an RFC.
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add formatting for new syntax to the style guide.
  • See the nightly style procedure.

Unresolved Questions

• Which exact alternative or alternatives should we adopt?

Related

• [RFC] externally implementable functions rfcs#3632
• [RFC] externally definable statics rfcs#3635
• Externally implementable traits rfcs#3645
• RFC: Existential types with external definition rfcs#2492

Implementation history

TODO.

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

[m-ou-se]

@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!

[Amanieu]

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.

[m-ou-se]

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.