# Allow importing assoicated methods

**URL:** <https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131>\
**Category:** Uncategorized\
**Created:** [January 12, 2023, 3:55am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131 "2023-01-12T03:55:05Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![tvallotton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tvallotton/32/8153_2.png) [@tvallotton](https://internals.rust-lang.org/u/tvallotton)\
**Post date:** [January 12, 2023, 3:55am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/1 "2023-01-12T03:55:05Z")

</div>

Is there a reason not to allow importing associated methods from types and traits? Enums support importing constructors, which is similar. It would be nice to be able to do stuff like:

```rust
use Default::default; 
use std::MaybeUninit::uninit;

```

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [January 12, 2023, 4:12am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/2 "2023-01-12T04:12:28Z")

</div>

For enums, the constructor gives an alternative place to put generic arguments. E. g. you can write `None::<T>` or `Option::None::<T>` instead of `Option::<T>::None`. I suppose for a full “importing trait/type methods” feature, one might need a way to still be able to specify the generic arguments of the type, or the generic arguments and/or `Self` type of the trait, I suppose? Or maybe not...? If yes, it's less straightforward than with enum constructors, because methods can also already have some generic arguments for themselves. If I can import `String::new`, can I also import `String::default`, too, or only the more generic `Default::default`? Maybe I can even import `Foo::<Bar>::baz` for a specific instantiation (with `Bar`) of the generic argument(s)? All of this opens a lot of design space that someone would have to address, discuss, and propose best solutions for, before such a feature could be introduced and stabilized.

---

<div class="post-metadata">

**Author:** ![tvallotton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tvallotton/32/8153_2.png) [@tvallotton](https://internals.rust-lang.org/u/tvallotton)\
**Post date:** [January 12, 2023, 4:19am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/3 "2023-01-12T04:19:24Z")

</div>

Being conservative, I'd say you cannot import trait methods from structs, since they don't live in that namespace, only associated methods. Maybe that could be supported in the future, but I don't consider it very important as long as traits are supported. And I'd let `Self` be inferred, if it cannot be inferred, then it just cannot be used (like we do with `impl Trait`) and universal function call syntax is required, like in other places in the language.

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [January 12, 2023, 4:53am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/4 "2023-01-12T04:53:46Z")

</div>

FWIW, `use Default::default` is something that's been discussed a lot as something we'd _like_ to support. See various discussion in [#73001](https://github.com/rust-lang/rust/pull/73001) (impl) and [#73041](https://github.com/rust-lang/rust/issues/73014) (tracking issue) for `fn std::default::default`. @petrochenkov [says](https://github.com/rust-lang/rust/pull/73001#issuecomment-639121954) it should be a fairly minor compiler change.

Probably part of the reason progress has been sparse is that for the specific motivating case of `..default()` in FRU, the most invested have been exploring/pursuing more first-class field defaults as an alternative.

---

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [January 12, 2023, 4:54am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/5 "2023-01-12T04:54:31Z")

</div>

> [@tvallotton](#):
>
> Is there a reason not to allow importing associated methods from types and traits? Enums support importing constructors, which is similar. It would be nice to be able to do stuff like:
> 
> ```rust
> use Default::default; 
> use std::MaybeUninit::uninit;
> 
> ```

No reason whatsoever, except that it touches name resolution and hasn't been done yet, and there are relatively few people capable of doing it. (@petrochenkov being one of them, and thanks @CAD97 for the link.)

We should _absolutely_ support this.

---

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [January 12, 2023, 4:57am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/6 "2023-01-12T04:57:26Z")

</div>

> [@steffahn](#):
>
> For enums, the constructor gives an alternative place to put generic arguments.

I think, for a simple first pass, we could just _not support_ disambiguating this with turbofish or similar. (For a constructor, you'll still often be able to disambiguate on the `let` or similar.)

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [January 12, 2023, 4:59am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/7 "2023-01-12T04:59:59Z")

</div>

> [@josh](#):
>
> sufficiently hard in name resolution

At the very least, thankfully we do have

```plaintext
error[E0428]: the name `Name` is defined multiple times
 --> src/lib.rs:2:1
  |
1 | trait Name {}
  | ---------- previous definition of the trait `Name` here
2 | mod Name {}
  | ^^^^^^^^ `Name` redefined here
  |
  = note: `Name` must be defined only once in the type namespace of this module

```

so there's no namespace ambiguity shenanigans that need to be delt with; we're still only dealing with the single type/mod namespace for nonterminal names in the `use` tree.

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [January 12, 2023, 5:23am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/8 "2023-01-12T05:23:39Z")

</div>

Another thing that came to mind, though more of a fact than a hard problem to solve: Since enums already allow `use TypeName::*` to mean “import all _variants_ of `TypeName`”, and _changing_ this behavior to “import all variants _and associated items_” would be too much of a breaking change, a feature for importing associated items should disallow `*`, except for enums, where the existing behavior is preserved that `*` refers to enum variants only. Diagnostics can educate/help users when they try to use `*` on an enum and then expect to be able to call associated functions.

---

<div class="post-metadata">

**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\
**Post date:** [January 12, 2023, 10:00am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/9 "2023-01-12T10:00:27Z")

</div>

It is worth noting that if there is a way to declare the generics, it could be applied to `x.into::<T>()` as well. That exact syntax can't work, but _something_ surely can.

---

<div class="post-metadata">

**Author:** ![Miiao](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/miiao/32/9577_2.png) [@Miiao](https://internals.rust-lang.org/u/Miiao)\
**Post date:** [January 12, 2023, 10:30am UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/10 "2023-01-12T10:30:59Z")

</div>

You can create a static (without generics, unfortunately. I wanted to suggest function-aliases, but nobody gave a damn((( )

---

<div class="post-metadata">

**Author:** ![waffle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/waffle/32/14371_2.png) [@waffle](https://internals.rust-lang.org/u/waffle)\
**Post date:** [January 16, 2023, 12:14pm UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/11 "2023-01-16T12:14:30Z")

</div>

For some reference there is a proposal of this on RFC repo: [Support use Trait::method and/or Type::method? · Issue #1995 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/issues/1995) which I was planning to implement soon ™.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [April 16, 2023, 12:14pm UTC](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131/12 "2023-04-16T12:14:39Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.