mirror of
https://github.com/rust-lang/rust.git
synced 2025-02-23 20:34:06 +00:00
11c94a1977
Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec<i32> = Vec::new(); pub const fn bar() -> [Vec<i32>; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed. We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved). Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147 |
||
|---|---|---|
| .. | ||
| rustc | ||
| rustc_apfloat | ||
| rustc_arena | ||
| rustc_ast | ||
| rustc_ast_lowering | ||
| rustc_ast_passes | ||
| rustc_ast_pretty | ||
| rustc_attr | ||
| rustc_builtin_macros | ||
| rustc_codegen_cranelift | ||
| rustc_codegen_llvm | ||
| rustc_codegen_ssa | ||
| rustc_data_structures | ||
| rustc_driver | ||
| rustc_error_codes | ||
| rustc_errors | ||
| rustc_expand | ||
| rustc_feature | ||
| rustc_fs_util | ||
| rustc_graphviz | ||
| rustc_hir | ||
| rustc_hir_pretty | ||
| rustc_incremental | ||
| rustc_index | ||
| rustc_infer | ||
| rustc_interface | ||
| rustc_lexer | ||
| rustc_lint | ||
| rustc_lint_defs | ||
| rustc_llvm | ||
| rustc_macros | ||
| rustc_metadata | ||
| rustc_middle | ||
| rustc_mir | ||
| rustc_mir_build | ||
| rustc_parse | ||
| rustc_parse_format | ||
| rustc_passes | ||
| rustc_plugin_impl | ||
| rustc_privacy | ||
| rustc_query_system | ||
| rustc_resolve | ||
| rustc_save_analysis | ||
| rustc_serialize | ||
| rustc_session | ||
| rustc_span | ||
| rustc_symbol_mangling | ||
| rustc_target | ||
| rustc_trait_selection | ||
| rustc_traits | ||
| rustc_ty_utils | ||
| rustc_type_ir | ||
| rustc_typeck | ||