type inference for consts/statics

[nrc]

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.

[nagisa]

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.

[petrochenkov]

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 - #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;)

[sfackler]

Dup of #296?

[withoutboats]

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.

[mbrubeck]

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.

[glaebhoerl]

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.)

[llogiq]

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.

[glaebhoerl]

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.

[llogiq]

@glaebhoerl so you'd want the full type for B in the following snippet?

static A = &[&["Hello", "Rust"], &["Foo", "Bar"]];
static B : ... = &[&A, &A]

[glaebhoerl]

Right.

(Modulo elision of 'static, which again is orthogonal and complementary - as the example demonstrates.)

[durka]

What if we inferred types for consts and statics, even based on use, but only within function bodies, leaving top-level type declarations alone?

[joshtriplett]

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.

[Ixrec]

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 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!

[Boscop]

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!

1. 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.

2. 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.)

3. Due to lack of type inference for const/static I often find myself using a let binding 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).

[joshtriplett]

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.

[Centril]

@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.

[Boscop]

@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").

[Centril]

@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.

[durka]

@joshtriplett There's a macro for that. It shouldn't be necessary though, I agree.

[Boscop]

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.

[DoumanAsh]

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