Tracking issue for RFC 2203, "Constants in array repeat expressions"

[Centril]

This is a tracking issue for the RFC "Constants in array repeat expressions" (rust-lang/rfcs#2203) (feature gate: const_in_array_repeat_expressions).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Implementation history:

• Initial implementation: rustc/rustc_mir: Implement RFC 2203. #61749
• (this is incomplete)

Unresolved questions:

• Should we treat this as an explicit promotion context? That would allow calling arbitrary const fn, but poses the risk of breaking code that would otherwise work fine if we decide to promote when it would not have been necessary. The alternative is to rely on inline const expressions instead (Tracking Issue for inline const patterns (RFC 2920) #76001).
• Should we maybe not perform any promotion at all, and instead require a named const, literal, or explicit const {} block for the repeat expression?

[F001]

I had an investigation on this issue. I think removing below lines can achieve our goals. But I'm not sure whether it is enough.

rust/src/librustc_mir/borrow_check/nll/type_check/mod.rs

Lines 1232 to 1238 in 1eab9c5

	Rvalue::Repeat(operand, len) => if *len > 1 {
	let operand_ty = operand.ty(mir, tcx);
	let trait_ref = ty::TraitRef {
	def_id: tcx.lang_items().copy_trait().unwrap(),
	substs: tcx.mk_substs_trait(operand_ty, &[]),
	};

rust/src/librustc_typeck/check/mod.rs

Lines 4017 to 4025 in 1eab9c5

	if let Ok(count) = count {
	let zero_or_one = count.val.to_raw_bits().map_or(false, |count| count <= 1);
	if !zero_or_one {
	// For [foo, ..n] where n > 1, `foo` must have
	// Copy type:
	let lang_item = self.tcx.require_lang_item(lang_items::CopyTraitLangItem);
	self.require_type_meets(t, expr.span, traits::RepeatVec, lang_item);
	}
	}

And another question, given that this change should be guarded by a feature gate, how can we suggest user to enable this feature when a compile error occurs?

I'd appreciate it if somebody can write a mentoring instruction.

[eddyb]

See rust-lang/rfcs#2203 (comment) - I don't think we should implement this before the MIR borrowck becomes the default - while it may be possible, it's getting increasingly risky to do such things.
cc @nikomatsakis

[eddyb]

So I just realized that "constant" has been a red herring all along for this problem:
What const-checking has is "value-based reasoning", that is, a value like None::<T> contains no values of T, so T's properties (like Drop or the presence of interior mutability) do not apply to it.

For [expr; n] where we don't know that n <= 1, we've always required typeof(expr): Copy.
The accepted RFC would allow another option which is SomeFormOfConstant(expr).
However, this isn't as general as it could be and it doesn't tie into the Copy condition very well.

One example of a runtime repeated expression we could allow is [Ok::<i32, String>(rand()); n].
Or to expand it a bit, { let x = rand(); [Ok::<i32, String>(x); n] } - this is "obviously fine" because the user could write n of Ok(x), so inline ADT construction is always "inherently copyable".

I propose (a bit late) that we consider a value (dataflow) analysis, Copyable(expr), which works similar to the current value analyses used in const-checking, effectively "recursing" on ADT constructors, and using the following two rules when reaching leaves x of unknown values:

• typeof(x): Copy (the set of types currently allowed in [x; n])
• x is already a constant (by naming a constant or through the pre-existing promotion)

Another advantage of this is that it's not limited to [expr; n]: any copy could be satisfied through it!

cc @nikomatsakis @RalfJung

[RalfJung]

So I just realized that "constant" has been a red herring all along for this problem:
What const-checking has is "value-based reasoning", that is, a value like None:: contains no values of T, so T's properties (like Drop or the presence of interior mutability) do not apply to it.

Trying to recast what you are saying in my terms, we have Copy and "needs drop" as properties of types, but in fact these are properties of values. T: Copy merely says that all values of type T are copy. And a value is Copy if it can be duplicated because it doesn't have any ownership in it. Most of the time we only care about the type-level Copy because that's all the compiler knows, but e.g. the None value of type Option<T> is Copy for any T. Is that what you are saying?

I think that's a remark I already made somewhere else earlier this year but I have no idea where.^^

[eddyb]

Most of the time we only care about the type-level Copy because that's all the compiler knows, but e.g. the None value of type Option<T> is Copy for any T. Is that what you are saying?

Yes, except I only realized it can apply to all copies at the very end of writing my entire comment, so my reasoning may look quite roundabout. I suspect this might not even be the only place where we can generalize a type-based analysis to a value-based one (like const-checking has).

We could even mix this with polymorphism, by putting "refinement types" through generics.
(but that's riskier because of soundness implications that are harder to understand right now)

[nikomatsakis]

@eddyb hmm, interesting thought. So this is basically "doubling down" on the value-based reasoning we use for consts, and applying it here as well? I don't entirely hate that, particularly if we can kind of "reuse" the form of the rule from consts exactly.

[runelabs]

I ran into the following constraints with trying to use primitive array repeat in struct initialization. It seems there is no way to make a RHS expression with the default value None of an Option for [x; n] without implementing Copy or needing type ascription.
I read the previous open issues on type ascription, but with default() for Option it would be nice to just be able to easily use the default None value for repetition. I am using this for a no_std crate.

enum Wrap { ... }
struct MyStruct<'a> {
  arr: &'a mut [Option<Wrap>]
}
impl<'a> MyStruct<'a> {
  pub fn new(list: &'a mut [Option<Wrap>]) -> Self { Self{ arr: list} } }
}
// works fine, and is very ergonomic
let mut z = MyStruct{ arr: &mut [] }; 
// however the logical follow-up and equally ergonomic &mut [None;N] fails...

// all fine, Copy-trait not needed (*1)
let mut empty1: [Option<Wrap>;11] = Default::default();
let mut a = MyStruct{ arr: &mut empty1 };

// need type ascription, Copy-trait not needed (*2)
let mut empty2 = Default::default():[Option<Wrap>;11];
let mut b = MyStruct::new(&mut empty2);

// need type ascription, Copy-trait for Wrap
let mut empty3 = [Default::default();11]:[Option<Wrap>;11]; // (*3)
let mut empty4 = [Option::default();11]:[Option<Wrap>;11]; // (*4)
let mut empty5 = [None;11]:[Option<Wrap>;11]; // (*5)

// need type ascription, parenthesized expression ... but alas, lifetime fails when (expr)
let mut c = MyStruct{ arr: &mut ([Default::default();11]:[Option<Wrap>;11]) }; // (*6) , also parens expr
let mut d = MyStruct::new( &mut ([Default::default();11]:[Option<Wrap>;11]) ); // (*6b) , also parens expr

// need Copy-trait for Wrap
let mut e = MyStruct{ arr: &mut [Default::default();11] }; // (*7)
let mut f = MyStruct{ arr: &mut [None;11] }; // (*8)
let mut g = MyStruct::new(&mut [None;11]); // (*9)

All the cases from (*1) to (*9) try to accomplish similar initialization. Ideally, shouldn't they all work similarly?

I really want to use (*9), (*8) or (*7) - and not (*1) or (*2) which are not ergonomic.

None seems like a special repetition case not needing Copy. Similarly it is very awkward having arr: [Option<Wrap>;11] and not being able to use [None;11] for initializing it in a structure, but actually having to expand it all like [None,None,None,...]. It also does not feel natural to need type ascription for such basic initialization. Needing to declare const X: T = None; for a [X; N] also does not help in making Rust a more accessible programming language for newcomers. It requires reading up on this special case for Option repetition - instead of what should really just be a simple programming pattern similar to MyStruct{ arr: &mut [] } which is valid, immediately accessible and ergonomic.

[eddyb]

@nikomatsakis Indeed, I think we should double down on value reasoning in favor of ergonomics.
In my view, NLL is doing sort of a similar thing, albeit the analysis is relatively more complex.

---

Needing to declare const X: T = None; for a [X; N] also does not help in making Rust a more accessible programming language for newcomers

This is not required in the accepted RFC, you will be able to just write [None; N] inline.

It requires reading up on this special case for Option repetition -

Option is not special-cased, it just happens that None contains no non-copy data. None would be just as accepted as e.g. Ok(123) (for any Result<_, _> type, including non-copy ones).

As for your ascription questions: you can make these replacements in your code:

• Wrap and even Option<Wrap> -> _ (inference)
  • always try _ first when trying to specify a type (e.g. Vec<_> before Vec<T>)
  • in let x: _; and expr: _, the _ is redundant (inference works regardless)
• [expr; n]: [_; n] -> [expr; n] (the type ascription is also redundant here)
• Default::default(): T -> T::default() (or <T>::default if T isn't a path)
  • e.g. <[_; n]>::default()

Then your code looks like this (click to expand).

enum Wrap { ... }
struct MyStruct<'a> {
  arr: &'a mut [Option<Wrap>]
}
impl<'a> MyStruct<'a> {
  pub fn new(list: &'a mut [Option<Wrap>]) -> Self { Self{ arr: list} } }
}
// works fine, and is very ergonomic
let mut z = MyStruct{ arr: &mut [] }; 
// however the logical follow-up and equally ergonomic &mut [None;N] fails...

// all fine, Copy-trait not needed (*1)
let mut empty1: [_;11] = Default::default();
let mut a = MyStruct{ arr: &mut empty1 };

// need type ascription, Copy-trait not needed (*2)
let mut empty2 = <[_;11]>::default();
let mut b = MyStruct::new(&mut empty2);

// need type ascription, Copy-trait for Wrap
let mut empty3 = [Default::default();11]; // (*3)
let mut empty4 = [Option::default();11]; // (*4)
let mut empty5 = [None;11]; // (*5)

// need type ascription, parenthesized expression ... but alas, lifetime fails when (expr)
let mut c = MyStruct{ arr: &mut [Default::default();11] }; // (*6) , also parens expr
let mut d = MyStruct::new( &mut [Default::default();11] ); // (*6b) , also parens expr

// need Copy-trait for Wrap
let mut e = MyStruct{ arr: &mut [Default::default();11] }; // (*7)
let mut f = MyStruct{ arr: &mut [None;11] }; // (*8)
let mut g = MyStruct::new(&mut [None;11]); // (*9)

Further notes from looking at the result of that:

• [Default::default(); 11] and [Option::default(); 11] are no better than [None; 11]
• <[_; 11]>::default() works even today because it calls Option::default 11 times from the implementation of Default for [T; 11], so it never needs to copy an Option<Wrap>

@runelabs I hope I've clarified a few things and/or resolved most of your concerns.

[runelabs]

@eddyb Thanks, I hadn't thought of <[_; 11]>::default() . That is the "turbofish" notation?
It wasn't immediately intuitive to me as a replacement. The compiler suggested type inference when I was exploring options earlier, which led to looking at type ascription although it seemed unnecessary. As long as the [None;11] will be working with this RFC, I am a happy camper. From the RFC it seemed like it had to be a const declaration beforehand. Good it wasn't so 😄

[eddyb]

<T>::foo is "type-qualified path" syntax, which T::foo is a shorthand for (if T is not a trait).
Usually only foo::<T> is referred to as turbofish, the former would be more "reverse turbofish".

[eddyb]

Is the S-blocked label the right way to do this? I kind of want a "needs NLL" but not "fixed by NLL" label (cc @nikomatsakis).

[pnkfelix]

@eddyb hmm maybe we could/should just rename "fixed by NLL" to "needs NLL", which is ... strictly more general?

(Or is that label not a true generalization? I'm still musing over the english semantics here. I guess "fixed by NLL" implies that NLL is sufficient but not (necessarily) necessary, while "needs NLL" implies NLL is necessary but not (necessarily) sufficient...)

• I can't believe just wrote "necessarily necessary"

[Centril]

Discussed briefly on Zulip -- would we want to experiment with this on 2018 only to begin with?

[eddyb]

I left a comment elsewhere, I think it would be fine if this were restricted to Rust 2018: #54542 (comment)

[Centril]

cc @pnkfelix, @eddyb, @oli-obk, and possibly more people: Should we call this unblocked now and start on an implementation? I think it would be good to avoid too much pressure to stabilize uninitialized_array! and do the principled fix (this feature). :)

[RalfJung]

@oli-obk so, what do we do about the dropping thing? [expr; 0] behaves (or rather, should behave) differently depending on whether expr got promoted or not when the final value of expr needs dropping. So I think something in promotion analysis needs to reject things that need dropping. But I have no idea where the best place is to put that check -- in the Candidate::Repeat arm, or should we rather have it in validate_local or so?

[oli-obk]

I'm still unsure we should do this at all (as mentioned earlier). I would rather make a decision on that first before putting in more effort

[RalfJung]

You mean, supporting only Operand::Const, i.e., const literals and const blocks, and no promotion at all? Yeah that would of course also work.

[oli-obk]

Yes, that is what I mean. It would simplify a lot, and iirc that was always on the table.

[tmiasko]

Not checking for drop has an additional effect that enabling this feature gate changes the semantics of programs that already compile successfully (or is a separate bug?):

//#![feature(const_in_array_repeat_expressions)]

struct S(&'static str);

impl Drop for S {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

fn main() {
    // S is dropped or not depending on the feature gate.
    [&S("a"); 4];
}

[RalfJung]

@tmiasko ouch...

I am more and more convinced we should do what @oli-obk suggested: remove const_in_array_repeat_expressions and the corresponding code in promotion, and rely on const blocks instead.

[tesuji]

The feature const_in_array_repeat_expressions was removed in #80404.
Should this issue be closed or be replaced with something else ?

[oli-obk]

Ah good catch :D yea, this issue should be closed.

We removed this feature without replacement as the feature was extremely buggy and problematic and in the future we'll be able to use the inline_const feature to get the same behaviour albeit at a slight increase in verbosity.

[SimonSapin]

Should the accepted RFC be marked as "retracted" or something?

[scottmcm]

@SimonSapin Good call. I'll make a quick RFCs-PR and bring it up in the lang meeting tomorrow.

[bluss]

MaybeUninit::uninit_array's docs still link to this as a "future feature", seems like that mention should be removed