Trait for specifying a type parameter for Into::into There are occasionally times when it would be nice to be able to specify a type parameter for Into::into.

This doesn't happen very often&mdash;mostly just when you have a long-ish chain of method calls where the object type is changing. In that case, wrapping one part of the chain with T::from, or splitting it into multiple statements so you can specify the type in the variable binding would be kind of awkward.

I put together the following trait:

pub trait TypedInto {
    fn typed_into&lt;T&gt;(self) -&gt; T where Self: Into&lt;T&gt; { self.into() }
}

impl&lt;T&gt; TypedInto for T {}


And I can now specify the type for into:

let clip = clips::table.find(id).first::&lt;db::Clip&gt;(&amp;*conn)?
    .typed_into::&lt;models::Clip&gt;()
    .with_associations(&amp;*conn)?;


Am I going to regret using this? This is in the context of an application rather than a library, so I don't necessarily need to worry about anyone other than myself reading it. Is this a bad habit? Should I just be more verbose?
The most common way to handle type-hinting Into::into in stable Rust today is via temporaries. So for the use case you have here, I'd probably write something like:

let clip = {
    let clip: models::Clip = clips::table_find(id).first::&lt;db::Clip&gt;(&amp;*conn)?.into();
    clip.with_associations(&amp;*conn)?
};


But honestly, I don't think anyone will get up in arms about you using TypedInto. I know I've typed .into::&lt;Type&gt;() a couple times, and the common place you'd see the turbofish, .collect::&lt;Vec&lt;_&gt;&gt;(), is exactly this.



For this specific case, why don't you make a common db::T -> model::T conversion? It seems to be a common thing that happens, so making it explicit may be beneficial.



But that said, why don't we take a look at nightly feature gates? Because since 2015 the RFC for Type Ascription has been merged. It introduces an expr : ty syntax to the language meant to address cases like this. So rewriting your example to use type ascription,

let clip = ((clip::table.find(id)
    .first(&amp;*conn)? : db::Clip)
    .into() : models::Clip)
    .with_associations(*&amp;conn)?;


Unfortunately, the binding of type ascription, while the same as as, is lower than method call syntax (.), so the parenthesis are necessary (and rustfmt would probably not approve of the formatting I used here). There is a patch written which would cause type ascription to bind more tightly than method calls, but it was closed in favor of waiting to later RFC the change (which would be backwards compatible (probably)).

There has been some recent noise around the feature, since it would make working with Futures a lot easier (though impl Trait may also help as well). Stabilization (since it has been approved through RFC) is blocked on ensuring soundness and allowing &amp;[1, 2, 3] : &amp;[u8] to work, so if you'd love to see type ascription stabilize, you can help with one of those.