Optimize generics to a dynamic dispatch for size

[orowith2os]

Generic currently generate two similar functions to do something - for some cases, this isn't desired, like in "all I care about is size" cases. For this, it seems reasonable for the compiler to instead check the input types at runtime and figure out what to do based off of that. I'm not quite sure how much it would help, but it would help nonetheless.

So, for a theoretical example:

fn convert_to_string<T: ToString>(input: T) -> String {
    input.to_string()
}

Given two inputs, an i32 and a f64 in this example, it would get turned into:

// The compiler will probably mangle these so they don't conflict, but that's a different topic
fn convert_to_string(input: i32) -> String {
    input.to_string()
}
fn convert_to_string(input: f64) -> String {
    input.to_string()
}

But, if the compiler were to be told to optimize it as much as possible for size, this would instead get turned into something like:

fn convert_to_string(input: i32 or f64) -> String {
    match typeof(input) {
        i32 => input.to_string(),
        f64 => input.to_string(),
    }
}

Obviously, the example code is a bit weird and isn't valid, but the idea is there. Instead of creating two different functions, make one that matches on the types at runtime. The point here is to work without traits, which is why I did not suggest converting generics that rely on traits to a dynamic dispatch instead.

This would also be useful with variadic generics, I think.

[marcospb19]

Maybe a duplicate of Related to #77960.

[orowith2os]

@marcospb19 maybe? Assuming #77960 works without traits too, it would probably be.

You can easily optimize generics that rely on traits to something computed at runtime, but not ones that don't use traits. That's why I made this request.

[DasLixou]

Without the background in expose-fn-type RFC, the code that the compiler would generate could probably also look like this:

// Callee side
enum Input {
    A(i32),
    B(f64),
}
fn convert_to_string(input: Input) -> String {
    match input {
        Input::A(a) => a.to_string(),
        Input::B(b) => b.to_string(),
    }
}
// Caller side
convert_to_string(Input::A(0i32));

This would possibly be already possible with a proc macro attribute 🤔.

But with the background of the RFC, we may have other reasons for a type_of! macro, but then there's the question how this would work with for example closures...

[marcospb19]

@orowith2os

but not ones that don't use traits

Sorry, I got confused because your example uses the trait ToString, could you give a more concrete example without traits involved?

[orowith2os]

You can just get rid of the traits in the example; iirc I put them in there after some quick discussions and it was noted that this would be feasible at first only for those that use traits.

[LunarLambda]

@orowith2os

but not ones that don't use traits

Sorry, I got confused because your example uses the trait ToString, could you give a more concrete example without traits involved?

Vec<T>::push. No trait bounds, so the only thing known about T is it's size and alignment, so it could be type erased into memcpy + pointer add. Maybe this is already done for Vec (it has some specializations under the hood), but any function that just moves unbounded Ts around (containers, iterators) could benefit.

Edit: I think this only works for types that don't need Drop or ones that take Drop types but never call drop (do those exist?)

[marcospb19]

IDK if rustc supports variable length arrays.

fn example(t: T) {
    // 1. VLA
    let array: [T; 8] = ...; // Variable size in runtime
    
    // 2. Variable memory layout
    let tuple = (0, t, 100);
    &tuple.1; // What's the offset to access this? Variable in runtime
}

[DasLixou]

IDK if rustc supports variable length arrays.

fn example(t: T) {

    // 1. VLA

    let array: [T; 8] = ...; // Variable size in runtime

    

    // 2. Variable memory layout

    let tuple = (0, t, 100);

    &tuple.1; // What's the offset to access this? Variable in runtime

}

When looking at my enum representation, this can be fairly easy answered. The Offset is the biggest of all used types for T