Different static variables for different instances of a generic function

[hajifkd]

Currently, different instances of a generic function have an identical static variable.

For example, the following code

fn foo<T>() {
    use std::sync::{Once, ONCE_INIT};

    static INIT: Once = ONCE_INIT;

    INIT.call_once(|| {
        // run initialization here
        println!("Called");
    });
}

fn main() {
    foo::<i64>();
    foo::<i64>();
    foo::<isize>();
}

calls println! just once. This is because the entities of the static variable INIT are the same for each different instance of the generic function foo.
(Well, actually I have asked this in stackoverflow, but I only got a workaround to use HashMap essentially. Using dynamical way to dispatch static code sounds a bit uncomfortable. )

I feel this behavior of generic functions and static variables is counter-intuitive since each instances of generic functions have different name in assembly and thus they are different function.
Of course, I agree that changing it loses compatibility and may not be good, so I would like to ask whether there is any room to add a new syntax or something to allow for different instances of a generic function to have different static variables. I feel this is important especially when we "translate" some C++ template code into Rust.

[eddyb]

FWIW the Rust semantics are "if you can write outside a function, putting it inside a block expression will only change where you can refer to it by name and nothing else".

So you can embed entire modules in an expression - not only in functions but also array lengths, and they behave the same as outside, except name resolution can get a bit confusing in some cases.

[burdges]

I'd imagine you want polymorphic/generic statics for this :

    ...
    struct OnceAndPhandom<T>(Once,PhandomData<T>);
    static INIT: OnceAndPhandom<T> = (ONCE_INIT,PhandomData);
    INIT.0.call_once(|| {
        ...

Also, the polymorphic/generic consts proposed in #1945 look useful too, ala

pub const OK<E>: Result<(),E> = Ok(());

I wonder if this could be merged with #1945 but even if not that might give you ideas about what the RFC should look like.

[hajifkd]

@eddyb Okay, I agree that if we treat T as just like a argument or a variable, then as you said this result is consistent.
But, considering assembly and that different instances of a generic function have different name, the above code looks similar to something like

fn foo1() {
    static A: i64 = 1i64;
    println!("{}", A);
}

fn foo2() {
    static A: i64 = 2i64;
    println!("{}", A);
}

, where two As are completely independent. Anyway, I believe some kind of static dispatch system is useful.

@burdges Generic statics indeed seems to solve my problem as you wrote although I have no idea what should happen in the following example:

fn foo<T, S>() {
    ...
    struct OnceAndPhandom<T>(Once,PhandomData<T>);
    static INIT: OnceAndPhandom<T> = (ONCE_INIT,PhandomData);
    INIT.0.call_once(|| {
        ...
}

fn main() {
    foo<i64, usize>();
    foo<i64, f64>();
}

[SimonSapin]

This sounds like https://github.com/chris-morgan/anymap

[eddyb]

Okay, I agree that if we treat T as just like a argument or a variable, then as you said this result is consistent.

All you have to do for consistency is to move anything that can be written outside a function, outside.

[sanmai-NL]

@hajifkd: Can this issue be closed now?

[hajifkd]

Okay. I'm sorry to bother you.