# 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:** 1\
**Showing post:** 2

<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.

---

_[View the full topic](https://internals.rust-lang.org/t/allow-importing-assoicated-methods/18131)._
