Tracking Issue for RFC 3591: useing a function from a trait

[clubby789]

This is a tracking issue for the RFC "Add support for use Trait::func" (rust-lang/rfcs#3591).
The feature gate for the issue is #![feature(import_trait_associated_functions)].

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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC
  • Implement use associated items of traits #134754
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

[crumblingstatue]

Might be worth noting that there is an orthogonal implementation of using a trait function through the unstable fn_delegation feature.

#![feature(fn_delegation)]

reuse Default::default;

fn main() {
    let s: i32 = default();
    dbg!(s);
}

Although my understanding is that this is just some kind of experiment, and will not be stabilized?
Might be worth taking a look at the implementation though.

[joshtriplett]

We were discussing this feature in a @rust-lang/libs-api meeting. We were wondering if the infrastructure that enables this feature would make it straightforward to provide a (separate) feature allowing use of an inherent function or associated constant/type from a concrete type.

[joshtriplett]

Also, separately from that: what's the status of this feature? Are there any blockers that aren't in the (currently empty) list at the top of this tracking issue? If not, could @rust-lang/lang get a stabilization report, please?

[fmease]

Also, separately from that: what's the status of this feature? Are there any blockers that aren't in the (currently empty) list at the top of this tracking issue?

We have the open PR #138712 that will slightly relax the feature and make it deviate from the RFC. All that's left is another review, then I'll likely approve it (as a T-compiler member). Details can be found over there.

[fmease]

We were wondering if the infrastructure that enables this feature would make it straightforward to provide a (separate) feature allowing use of an inherent function or associated constant/type from a concrete type.

Not in the slightest. The feature whose development is being tracked here is solely powered by name resolution and its impl basically only needed to lift some artificial restrictions.

Referencing a specific inherent associated item on the other hand always requires type checking routines (namely, type unification) because they are first identified by their self type which can be arbitrary and contain aliases that'd need to be normalized first (which requires type checking routines). Don't forget about bounds & where clauses on impls themselves which would need to be checked by the trait solver to weed out impls and to normalize aliases.

Furthermore, the current use syntax won't do (fn_delegation's reuse comes closer, see below), how else would you be able to disambiguate between impl Ty<A> { fn f() {} } and impl Ty<B> { fn f() {} } if not by generic arguments which aren't syntactically allowed in uses. How would you refer to inherent impls for dyn Trait?

This is T-types territory. Even then, it's incredibly hard to support for the same reason why inherent associated types haven't been implemented for more than a decade — which we can likely only support in a more limited form via HACKs: See #140247 most recently.

Note that we also have the feature fn_delegation (reuse …; in code) (rust-lang/rfcs#3530) with which one can do a lot more things but it also doesn't support inherent associated items and likely won't do so anytime soon.

[petrochenkov]

Note that we also have the feature fn_delegation (reuse …; in code) (rust-lang/rfcs#3530) with which one can do a lot more things but it also doesn't support inherent associated items and likely won't do so anytime soon.

Unlike in use imports, in delegation it should be quite realistic (there's an old semi-working prototype here), we are planning to implement it this year or in early 2026.

[fmease]

As long as you have Body (which you would have for reuse'd inherent assoc consts & fns) and lower the target via a FnCtxt instead of an ItemCtxt, everything should indeed be fine. The problem is ItemCtxts.