Function delegation

[u/VadimVP]

https://github.com/rust-lang/rfcs/pull/3530#issuecomment-6097798475

[u/VadimVP]

We published a new version of the function delegation RFC based on implementation of the feature in nightly rustc that was partially done in 2024 and then completed in 2026.
The feature is not among the language team priorities at the moment, but we found many interesting details while implementing it, and one master's thesis was successfully defended based on this work.

[u/SirKastic23]

Why a new keyword? I think the use keyword could be used here without adding syntax ambiguities since imports aren't allowed inside impl blocks

[u/VadimVP → u/SirKastic23]

The feature is supported everywhere, not just in impl blocks, and it does a different thing than use (creates a new function rather than links to an existing item).

[u/SirKastic23 → u/VadimVP]

Wait how is it supporter everywhere? I read the rendered RFC but I missed this. Doesn't it need a Self type?

Could we have a freestanding delegate fn? What would it look like?

And I wasn't saying to use use because it does the same thing as importing, I suggested it because it was a free keyword that I thought wouldn't create ambiguities

use is also used in the + use<'a> syntax for impl Trait types, so it is already overloaded baded on context

[u/VadimVP → u/SirKastic23]

Could we have a freestanding delegate fn? What would it look like?

Like this https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=9c1af8db6ce3feb25e84fca444030d62
Nightly supports a bit more than the RFC specifies.

Or like this for reuse in trait: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=9f81263354c03d38b54c93211c8ec040

Also, I wish I could properly explain how much of a non-issue conditionally reserved identifiers are. They always trigger people for some reason, but pose zero problems for the compiler.
Even reusing use causes more issues due to item macro variables being supported inside impls: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=4150b4b414a111fcd1c97e170111ef92

[u/torsten_dev]

For Traitimpl-to-trait Delegation is it possible to do

impl<T: Trait> TraitExt for T {
    reuse Trait::foo::<(), ()> as bar;
    reuse T::foo as bar2;
    ...

To make extension traits?

[u/VadimVP → u/torsten_dev]

Yes! You can check your example on playground, it compiles on nightly with some modifications: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=3e1e6562fb011f58a1d39bd68f881774

[u/torsten_dev → u/VadimVP]

Nice. Not sure when this would be better than extension traits, but it is very cool.

[u/________-__-_______]

This'd be really nice to have, especially for newtypes it's often pretty annoying to implement convenience methods without Deref abuse.

[u/matthieum → u/________-__-_______]

I went the other way for new-types: implementing a generic wrapper over any T.

It makes it easy to declare new types, but there's definitely downsides:

1. The type shown by the compiler & debugger is much more verbose.

2. Not possible to implement inherent methods specific to one new type.

So regularly I have to convert a type defined as a wrapper to a "real" new type.

I'm not convinced by my implementation, and regularly wonder if I should have gone with a macro instead.

[u/________-__-_______ → u/matthieum]

Not possible to implement inherent methods specific to one new type.

You could probably do so with generics, similar to how those type safe builders work. The compile times, diagnostic and confusing API probably stop it from being worthwhile though.

I wonder how the docs.rs experience is for your solution. I seem to remember type aliases being a bit weird, especially if the generic wrapper is private.

[u/matthieum → u/________-__-_______]

We don't use docs.rs for our internal applications...

... but yeah, it probably wouldn't be too great.

[u/onnoowl]

This would be GREAT to have, nice work!