const-evaluation

[nikomatsakis]

Summary

Const-evaluation, language team impact

Links

• Repository rust-lang/const-eval
• Zulip stream t-compiler/const-eval

[nikomatsakis]

• Oli working on skill-tree to help plan next steps for const-eval
  • loop and while (not for) is the next candidate for stabilization.
    • Main blocker was questions around qualification à la if and match.
    • Having if and match w/o loop and while will push people to use recursion for loops in a const context (I believe this happened with C++’s constexpr).
    • Having no for loops, which would require const trdait methods, is painful though.
• Inline const { … } expressions (and patterns)
  • Inline const expressions and patterns rfcs#2920
  • Do we allow code inside a const { … } to depend on generic parameters?
  • Does unsafe { const { … } } allow unsafe operations inside the inline const?
    • See unsafe blocks do not apply to array length expressions they contain rust#72359 for background
  • Do we allow const { … } in fallible patterns?

[nikomatsakis]

• RFC 2342, "Allow if and match in constants"
  • Stabilization PR
  • Oli wants to tie to stabilization to loops (see below).

[nikomatsakis]

• RFC 2344, "Allow loop in constant evaluation
  • Stabilization proposal
  • Currently we have a limit on the amount of time we can spend in const-eval, but the only way to override it is with a nightly feature.
    • See Tracking issue for const_eval_limit: configurable, per-item instruction limit for CTFE rust#67217 for the current implementation (a crate-global attribute).

[nikomatsakis]

• #71824, Check for live drops in constants after drop elaboration
  • This is enabled by moving const-checking after drop elaboration
    • Additional precision in what is availible
    • Concern: This makes drop elaboration more of the public facing languge/”spec”
  • Drop elaboration removes most frivolous Drop terminators. It seems silly to duplicate this work during const-checking.
  • Allows Option::unwrap to become (unstably) const: Can't implement a const Option::unwrap because of "destructors cannot be evaluated at compile-time" error. rust#66753
  • Does this want its own feature gate, or wrap into above? (nominated below)

[nikomatsakis]

Update from meeting:

• Check for live drops in constants after drop elaboration rust#71824 has been merged.

[nikomatsakis]

2020-06-22:

• Have the Review const evaluation skill-tree and unsafe questions #18 design meeting this week about the skill tree and unsafe and so forth.

[ecstatic-morse]

const_if_match and const_loop stabilization PR merged (rust-lang/rust#72437). On track for stabilization in 1.46.

[nikomatsakis]

2020-07-06:

• No updates we are aware of :)

[nikomatsakis]

2020-08-3:

• No updates

[joshtriplett]

2020-08-10:

• No updates

[nikomatsakis]

2020-08-31:

No updates.

[nikomatsakis]

2020-09-21:

We have entered the "const evaluatable" check that allows you to have array sizes beyond [u8; N] (e.g., [u8; N+1]), but still lots of work before that would be considered possible on stable.