Rust

7966 readers

4 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

torcherist@programming.dev

Inferred types for function calls? (programming.dev)

submitted 11 months ago* (last edited 11 months ago) by catch22@programming.dev to c/rust@programming.dev

5 comments fedilink hide all child comments

Hello, I'm fairly new to Rust and came across this. Can someone explain to me how the following example is able to infer the constant value from the array length passed in? At this point, inferred type generation for function calls are a bit hand wavy, to me, does anyone know of a resource that breaks down all the different ways they can be used (for instance in this example I hadn't seen them used for consts) and what their limitations are in Rust? I often run across a 'this type can not be inferred' error without really knowing why not and just throw in the type to make it go away.

Any other examples people could point me to would be appreciated as well.

Thanks!

#[derive(Debug)]
struct Buffer<T, const LENGTH: usize> {
    buf: [T; LENGTH],
}

impl<T, const LENGTH: usize> From<[T; LENGTH]> for Buffer<T, LENGTH> {
    fn from(buf: [T; LENGTH]) -> Self {
        Buffer { buf }
    }
}

fn main() {
    let buf = Buffer::from([0, 1, 2, 3,5]);
    dbg!(&buf);
}

Edit: for some reason, the code markdown is hiding things inside of the <>'s (at least on my lemmy viewing client)

you are viewing a single comment's thread
view the rest of the comments

[–] calcopiritus@lemmy.world 0 points 11 months ago (2 children)

Since deadcream already told you the reason. I'm gonna explain a more generic way.

There are 2 important times: compilation time and run time.

At compilation time, everything that is constant, is known to the compiler, or can be calculated by it.

At run time, everything* is known.

Types have to be generated at compilation time**. This means that generics have to be also known at compilation time.

In this case. Both the "T" type of the buffer and its size "LENGTH" are generic, so they must be known at compile time. Compile time usually doesn't know about vales of variables, except if those variables are "const". Then it is known. A value literal is the same as a const variable.

So here, you provide a value literal ([0,1,2,3,4]) which is a fixed array, that is, both its "T" type (i32 by default) and length (5) are known at compile time. Buffer has all the information it needs to become a real type instead of a generic one. In this case, the type will be Buffer<i32, 5>

Things that are optimized out at compile time are not known at runtime, but yes at compile time. For example:

const A: i32 = 5;
const B: i32 = 5+1;

fn main() {
    dbg!(B)
}

Since A is never used (except to calculate B, which is const), A is probably optimized out. However, since B is used, there probably is a 6 somewhere in memory. Notice how I say probably since optimizations are optional. Or more optimizations may even remove the 6, and convert it to an ASCII "6" to be printed out.

**While this is always true trait objects (like Box) can act like some kind of runtime type, if you need that functionality.

[–] d_k_bo@feddit.org 0 points 11 months ago* (last edited 11 months ago)

I recommend using numbered footnotes (¹, ² etc.) or escaping the asterisk (\*) instead of using plain asterisks for footnotes, because the asterisk is also used in Markdown for emphasis and list items.

[–] catch22@programming.dev 0 points 11 months ago

I gather from your explanation, that in order to tell before hand whether or not a type will be inferred, you really need to examine the code and see how things are being handled, and optimized out. (And even then you still may not know) Interesting, thanks.