Missing naming convention for free conversions between owned Copy types

[Ralith]

This comes up a lot for me when using newtyped integers. I usually use as_... to convey that it's free, but this contravenes the C-CONV recommendations.

[BurntSushi]

I think this is perhaps covered by C-CONV, but is not easily summarized in the table. e.g.,

f64::to_radians() converts a floating point quantity from degrees to radians. The input is f64. Passing a reference &f64 is not warranted because f64 is cheap to copy. Calling the function into_radians would be misleading because the input is not consumed.

This also seems relevant:

Conversions prefixed as_ and into_ typically decrease abstraction, either exposing a view into the underlying representation (as) or deconstructing data into its underlying representation (into). Conversions prefixed to_, on the other hand, typically stay at the same level of abstraction but do some work to change one representation into another.

It might be the case that we change Expensive in the Cost column for the to_ row to Variable.

[Ralith]

Conversions prefixed as_ and into_ typically decrease abstraction, either exposing a view into the underlying representation (as) or deconstructing data into its underlying representation (into).

Specifically for the newtype unwrapping case, this would seem to argue for into_, which could be made consistent by removing the "non-Copy" qualifier from the table.