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?