uninitialized/zeroed statics/consts

[Zoxc]

There should be a way to create consts, statics and static muts which are partially or fully uninitialized or zeroed.

One way to do this could be to create built-in unsafe generic constants ZEROED and UNDEF.

@eddyb suggested to make the existing intrinsics usable in statics

A crude solution could be to allow the initializer in a static mut to be left out, which should cause zeroing all it's memory.

[arielb1]

All-bits-zero isn't special in Rust (up to dynamic drops, which are being removed). Allowing some kind of mem::uninitialized() would be nice, through.

[mahkoh]

Sounds like CTFE. See #322 for another proposal that suggested limited CTFE for intrinsic functions.

[arielb1]

@mahkoh

We do have a limited version of CTFE. Currently it is limited to arithmetic and constructors. mem::uninitialized() won't increase its complexity so much .

However, adding size_of would complicate things more, because constants can be a part of type-checking, and this would make type-checking depend on LLVM. Because recursion in structs is so limited, this would still be tractable, but if we add traits etc. it would be a major mess.

I'm talking about stuff like:

trait Tr { fn doit(&self); }
impl Tr for [uint, ..std::mem::size_of::<uint>()] {
    fn doit(&self) { println!("called uint"); }
}
impl Tr for [uint, ..12-std::mem::size_of::<uint>()] {
    fn doit(&self) { println!("called 12-uint"); }
}

fn main() {
    let s = [0,1,2,3u];
    s.doit(); // which .doit is called depends on architecture
}

We could get around this by treating such values as "abstract values", so that they don't interfere with type-checking, and only expand them in trans. Of course this would create 2 kinds of constexprs, but otherwise we would be getting into what seems to me like a pretty deep dependent type hole.

C gets away with this because it "executes" declarations one-by-one.

[eddyb]

@arielb1 you can already do that, using uint::BYTES or uint::BITS.

[arielb1]

uint was just a simple example, whose size is a well-known constant – you could put more complicated types there so we need to put trans::adt-s size calculation code into rustc.

[eddyb]

AFAIK, the size calculations are done by LLVM. We could have a LLVM context during type-checking, is there anything problematic with that? We should do that anyway instead of the hacks we've thrown around transmute.

[arielb1]

@eddyb

They are done via LLVM and a big part of trans. I'll prefer keeping them separate. Actually, if we allow calling trait methods in constexprs then we'll have a total dependent type mess, and I strongly prefer not to go there, so we need to stop somewhere.

[arielb1]

There is also the problem of struct -> constexpr recursion. Because there are only finitely many constants we can handle this with a DFS, but if we allow functions this could get more complicated.

[eddyb]

A big part of trans? I find it's quite isolated, compared to anything which deals with Block, for example.

if we allow calling trait methods in constexprs

Nobody said anything about that. You couldn't even use a size_of intrinsic or associated constant, with a non-concrete type parameter, as the length of an array (e.g. impl<T> Cast<T> for [u8, ..size_of::<T>()]) because the length has to be constant before monomorphization, though that may change at some point.

[gnzlbg]

Would it be possible to make mem::uninitialized a const fn ? (or mem::zeroed?)

[oli-obk]

@gnzlbg once rust-lang/rust#46882 is merged, that is a trivial addition! (imo even uncontroversial, since you can write an unsafe const fn yourself that does the same thing via unions).

union Foo<T> {
    t: T,
    u: (),
}
unsafe const fn uninitialized<T>() -> T {
    Foo { u: () }.t
}

[gnzlbg]

@oli-obk congrats on the merge of that PR :)

Any news about this? This issue comes up every now and then in stdsimd: rust-lang/stdarch#403 (comment)