Eventually you'll be able to write
const create_string_pair: impl Fn(u32, String) -> Pair<u32, String> = crate::create_pair;
at the top level, which creates a way to alias monomorphizations of functions.
We already want to be able to do
use Trait::method, because we'd like to be able to expose a free
fn default<T: Default>() -> T that's just
pub use Default::default.
Being able to
use monomorphizations of types/functions is also interesting from another point of attack: compile work reuse.
We'd love for crates providing generic types to be able to precompile some monomorphizations of the abstractions and let downstream reuse those compilation artifacts rather than re-monomorphizing the same application of type parameters in every downstream crate. If a library provider can
[pub] use a generic type as a concrete one, that provides a lightweight way to create (and expose) a concrete monomorphization of the generic type for the compiler to reuse in dependents.
use wouldn't replace
used name would have to be "fully" applied and not have any more generic parameters left (except for
Self in the case of trait methods).
type would still be uniquely useful for type aliases that are still (partially) generic.
That said, I think we could also benefit from a
fn analogue for
type where it would be possible to write something to the effect of
fn create_numbered_pair<T> = create_pair<usize, T> the same way you can with
type (which I believe even does the same for the implicit tuple struct constructor function now as well).