rfcs
rfcs copied to clipboard
rust-lang
type inference for consts/statics
We shouldn't require types for consts and statics unless necessary. const FOO = "foo"; or static bar = 42; should just work. I propose that we try to infer based only on the RHS, i.e., we do not look at uses of consts/statics. Type error if we can't infer based on that. Although this would break the rule that items must be fully annotated, it would make static/const more consistent with let.
Ambivalent. I’m not using consts or statics compared to lets and I therefore don’t really find it to be a pain point to have specify a type of these.
I think type being specified might be better, since it is clear at the first sight what the type of const or static is. Similarly how’d you want to know what the type of function/method is. Having type specified is not as important for things that currently have an optional type (e.g. lets), because they can’t become a part of, or influence, public interface.
Dunno. You can do this in C++, but it's usually frowned upon (example) Maybe type inference should be allowed, but only on private constants/statics. (I had one weaker suggestion in the past - https://github.com/rust-lang/rfcs/issues/406 (somewhat outdated with regards to arrays), it still leaves interfaces explicit.)
(On a related note it would be extra nice to have generic constants inferring their type on their use, like const A<T: __PrimitiveInt__> = 10;)
I think at very least lifetime elisions of references in statics is a good idea. It feels very silly to write static FOOBAR: &'static str = "localhost:8080/foo" with the word static appearing twice.
I think at very least lifetime elisions of references in statics is a good idea.
#1623 has now been submitted proposing lifetime elision for statics.
With respect to type inference of consts/statics (which is orthogonal and complementary to elision of the 'static lifetime), I had basically the same thought as @nrc in the OP: that it should be supported as long as the RHS consists exclusively of introduction forms (that is, literals), and doesn't reference any other const or static items. In this case the type of the RHS is "obvious" (true is always bool and "hello" is always &'static str and Foo { ... } is always Foo), and the explicit type annotation can be thought of as strictly redundant.
(There are a few wrinkles, like defaulting, notably for numeric literals, and polymorphic values like Option::None. These could just be conservatively still-not-inferred as well, at least at first.)
I think that doing type inference will risk hurting locality of the code. With elision, the effect is quite limited, whereas with full inference, you can have spooky action at a distance where the errors reported may be quite far away from the actual culprit.
Not sure if you are agreeing or disagreeing or not even responding to me at all. :)
I agree that full inference would have those negative effects, which is why I think we should have the "literals only" restriction which, I believe, would avoid them.
@glaebhoerl so you'd want the full type for B in the following snippet?
static A = &[&["Hello", "Rust"], &["Foo", "Bar"]];
static B : ... = &[&A, &A]
Right.
(Modulo elision of 'static, which again is orthogonal and complementary - as the example demonstrates.)
What if we inferred types for consts and statics, even based on use, but only within function bodies, leaving top-level type declarations alone?
I'd like to see this as well. I regularly find myself having to specify types in const declarations that the compiler should have no problem inferring.
I just noticed that https://github.com/rust-lang/rfcs/pull/2010 is not linked to anywhere on this issue, which is pretty weird since that appears to be the last big discussion where new things were learned and problems raised that led to the current stalemate. For future readers, the biggest surprise was summarised by niko as follows:
based on the data that @schuster gathered, it looks like enabling
i32fallback would basically always pick the wrong type for simple things likeconst FOO = 22. This means you would still have to annotate cases of simple integer literals, and yet those appears to be the vast majority of constants!
based on the data that @schuster gathered, it looks like enabling i32 fallback would basically always pick the wrong type for simple things like const FOO = 22. This means you would still have to annotate cases of simple integer literals, and yet those appears to be the vast majority of constants!
- Writing int types for const/static when they shouldn't be i32 is not a big deal, but there are many cases where the type CAN (and should) be inferred, often when arrays or structs are used, like this:
pub const COL_RED_1 : Col = COL_RED .brightness(BRIGHTNESS_LOW); // const-fn
pub const COL_RED_2 : Col = COL_RED .brightness(BRIGHTNESS_MID);
pub const COL_GREEN_1 : Col = COL_GREEN .brightness(BRIGHTNESS_LOW);
pub const COL_GREEN_2 : Col = COL_GREEN .brightness(BRIGHTNESS_MID);
pub const COL_BLUE_1 : Col = COL_BLUE .brightness(BRIGHTNESS_LOW);
pub const COL_BLUE_2 : Col = COL_BLUE .brightness(BRIGHTNESS_MID);
pub const COL_YELLOW_1: Col = COL_YELLOW.brightness(BRIGHTNESS_LOW);
pub const COL_YELLOW_2: Col = COL_YELLOW.brightness(BRIGHTNESS_MID);
The return type of the .brightness() const-fn is known to the compiler so none of these constants would have needed an explicit type. Keep in mind that const-fns will become much more widely used as they become more capable.
- What also occurs frequently are dependency chains of constants like this:
pub const PUSH_ENCODER_START: usize = 0;
pub const ROWS_START: usize = PUSH_ENCODER_START + 8;
pub const TOP_GROUP_0: usize = ROWS_START + 16;
pub const TOP_GROUP_1: usize = TOP_GROUP_0 + 1;
pub const TOP_GROUP_2: usize = TOP_GROUP_0 + 2;
pub const TOP_GROUP_3: usize = TOP_GROUP_0 + 3;
pub const STORE: usize = TOP_GROUP_0 + 4;
pub const LEARN: usize = STORE + 1;
pub const EDIT: usize = STORE + 2;
pub const EXIT: usize = STORE + 3;
pub const PRESET_PREV: usize = STORE + 4;
pub const PRESET_NEXT: usize = PRESET_PREV + 1;
pub const BOTTOM_GROUP_0: usize = PRESET_NEXT + 1;
pub const BOTTOM_GROUP_1: usize = BOTTOM_GROUP_0 + 1;
pub const BOTTOM_GROUP_2: usize = BOTTOM_GROUP_0 + 2;
pub const BOTTOM_GROUP_3: usize = BOTTOM_GROUP_0 + 3;
pub static FX_STATES: [usize; 8] = [STORE, LEARN, EDIT, EXIT, BOTTOM_GROUP_0, BOTTOM_GROUP_1, BOTTOM_GROUP_2, BOTTOM_GROUP_3];
With type inference it would be enough to annotate the first one as usize, and the types for all the others (incl. the array) could have been omitted! (Also it's annoying to have to count the size of static arrays before writing their type.)
- Due to lack of type inference for const/static I often find myself using a
letbinding in a function where (semantically) I should be using a function-local static/constant (when writing code in a hurry). Type inference would encourage using more function-local static/constants by reducing the inconvenience.
So I would really like to see type inference for const/static be added (not just function-local).
Another one I run into regularly is fixed-sized arrays, where I have to explicitly specify the type including the number of entries. I'd like to omit that number.
@Ixrec It seems to me that for const items, the type could be held abstract / polymorphic in those cases as {integer} (or the most general type) and not pick a specific concrete type.
@Centril There is also the case where the crate that defines a constant doesn't use it in its own code, but exports it, so it can't be inferred (so it would be a compile-time error "type needs to be specified").
@Boscop That's fine; You can do it for non-pub items then. However, you could potentially hold the type abstract in the crate and so it could work again.
The macro is clever but I wouldn't use it because it makes the code harder to read (also for others). I'd prefer to have this built-in..
@Centril It should still infer the type of pub constants who are used in the same crate. Type annotation should only be required when the pub constant can't be inferred because it's only exported, not used in the same crate. I use pub for a lot of constants (like those above) that are only used in the same crate, in neighboring modules (they could be pub(crate) but that's more to type so I usually don't do it, unless I publish a crate and want to hide them) and I would want inference to work for them, too.
Is there per se anything that stops us from having type inference for static/const regardless of context? And why we should treat const/static differently from mut
I'd like this to enable consts containing anonymous types, which are currently impossible.
I'd like this to enable consts containing anonymous types, which are currently impossible.
That's not required to support this case:
// 1.41.0-nightly (2019-11-24 412f43ac5b4ae8c3599e)
#![feature(impl_trait_in_bindings)]
const VERSION: impl std::fmt::Display = 42;
fn main() {
println!("{}", VERSION);
}
Output:
42
Errors:
Compiling playground v0.0.1 (/playground)
warning: the feature `impl_trait_in_bindings` is incomplete and may cause the compiler to crash
--> src/main.rs:2:12
|
2 | #![feature(impl_trait_in_bindings)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
Finished dev [unoptimized + debuginfo] target(s) in 0.87s
Running `target/debug/playground`
Oh, nice! If that's on the path to stabilization then it's indeed a better solution for me.
One thing that is missing from the discussion so far is that sometimes types are unnameable.
For example, for once_cell RFC we want to write
statict DATA: Lazy<String, _> = Lazy::new(|| "hello world".to_string());
but there's no way to spell the type of the closure. More generally, -> impl Trait is impossible to use for a static.
As for the general ergonomics argument, I have data that not having type explicitly specified is annoying for ides, as it prevents an ide from ignoring the body of static/const.
I also have a personal opinion that statics and consts are comparatively rare constructs, so ergonomics wins here are at best marginal. I am also annoyed by needing to specify the lenghts of the arrays in statics, but this happens extremely rarely and, well, having a length in there is useful when reading the code, as you don't have to count lines manually to get a feel for how large is the thing.
More generally,
-> impl Traitis impossible to use for a static.
I don't follow why my comment almost immediately above yours does not apply:
#![feature(impl_trait_in_bindings)]
use once_cell::sync::Lazy;
static DATA: Lazy<String, impl FnOnce() -> String> = Lazy::new(|| "hello world".to_string());
fn main() {
println!("Hello, world!");
}
warning: the feature `impl_trait_in_bindings` is incomplete and may cause the compiler to crash
--> src/main.rs:1:12
|
1 | #![feature(impl_trait_in_bindings)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
warning: static item is never used: `DATA`
--> src/main.rs:5:1
|
5 | static DATA: Lazy<String, impl FnOnce() -> String> = Lazy::new(|| "hello world".to_string());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Perhaps you could expand on exactly what the problem is?
@shepmaster argh, sorry, I've read the thread here from the start, but apparently I've missed all the comments after https://github.com/rust-lang/rfcs/issues/1349#issuecomment-443589793 somehow =/
So yeah, sorry for repeating what was already said: https://github.com/rust-lang/rfcs/issues/1349#issuecomment-558233617
And yeah, allowing imp Trait in constants fixes that.
I just noticed that #2010 is not linked to anywhere on this issue, which is pretty weird since that appears to be the last big discussion where new things were learned and problems raised that led to the current stalemate. For future readers, the biggest surprise was summarised by niko as follows:
based on the data that @schuster gathered, it looks like enabling
i32fallback would basically always pick the wrong type for simple things likeconst FOO = 22. This means you would still have to annotate cases of simple integer literals, and yet those appears to be the vast majority of constants!
I think this might just be a self-fulfilling prophecy, in the sense that you're only going to find simple consts because any complicated type is too annoying to type out. That's how I ended up in this thread, and what I ended up doing, anyway.
