To be fair, though, Rust really needs something morally like prvalues, to solve the heap initialization problem aka `Box::new([42; 10_000_000])`

▲ tialaramex 3 days ago | parent | next [-]

I think what you'd most likely do here is something like:

    const HUGE: usize = 10_000_000;
    let mut values = Box::<[i32]>::new_uninit_slice(HUGE);
    for k in 0..HUGE {
         values[k].write(42);
    }

    let values = values.assume_init();

Edited to fix early enter oops, typo in loop length that'd be caught if I'd tried this.

▲

phire 3 days ago | parent | next [-]

Only problem with that approach is that assume_init() is unsafe (because it depends on you getting the initialisation loop correct), and many people are (correctly) hesitant to use unsafe.

IMO, it would be really nice if the naive syntax was guaranteed to work, rather than requiring programmers to remember a new workaround syntax (new_uninit_slice() was only stabilised a year ago). This edge case is a little annoying because the naive approach will usually work for a release build, but then fail when you with back to a debug build.

	▲	tialaramex 3 days ago \| parent [-]
		Yes, sorry, too late to edit now but it should use an unsafe block for the assume and provide the safety rationale explaining why we're sure this is correct. I am sympathetic to desire to make it "just work" in proportion to how much I actually see this in the wild. Large heap allocations, initialized in place in a single sweeping action. It does happen, but I don't reach for it often. Often people say "Oh, well I will finish initializing it later but..." and now we're definitely talking about MaybeUninit 'cos if you've only half finished the Goose, that's not a Goose yet, that's a MaybeUninit<Goose> and it's crucial that we remember this or we're writing nonsense and may blow our feet off with a seemingly harmless mistake elsewhere.

▲

csmantle 3 days ago | parent | prev [-]

This will soon gets cumbersome if we're trying to construct some large struct literals (rather than arrays) directly on heap. Rust should be able to elide the unnecessary stack allocation here.

▲ steveklabnik 3 days ago | parent | prev [-]

Yes, it is possible that Rust will add more complexity here specifically, but also just in general. Just how it goes :)

▲

okanat 3 days ago | parent [-]

I am not so sure. A purely type-system-based API (in place initialization + MaybeUninit ?) or a new "static" Vec type can already solve most of the problems with Box::new([val; N]).

	▲	steveklabnik 2 days ago \| parent [-]
		Right, that's why I think it's possible, but not for sure. There are other ways than new value categories to solve these problems.