Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Allow type inference for const or static #3546

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
114 changes: 114 additions & 0 deletions text/0000-const-type-inference.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,114 @@
- Feature Name: const_type_inference
- Start Date: 2023-12-21
- RFC PR: [rust-lang/rfcs#3546](https://github.com/rust-lang/rfcs/pull/3546)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

Allow type inference for `const` or `static` when the type of the initial value is known.

# Motivation
[motivation]: #motivation

Rust currently requires explicit type annotations for `const` and `static` items.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to write a little bit about why Rust is like this currently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this should have a longer explanation of Rusts "rule" of "no inference in signatures", how this RFC is breaking it and why this is okay.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great suggestion! I actually don't know why the design was made that way. Maybe someone from the Rust team can help explain?

The "type is missing in const" error was emitted from the parser so my guess would be that it was just difficult to infer types when consts were implemented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's like this currently because it was decided that all public API points should be "obviously semver stable" rather than "quick to type".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for explaining this. I've incorporated it into the RFC.



In simple cases, explicitly writing out
the type of the const seems trivial. However, this isn't always the case:

- Sometimes the constant's value is complex, making the explicit type overly verbose.
- In some cases, the type may be unnameable.
- When creating macros, the precise type might not be known to the macro author.
- Code generators may not have enough information to easily determine the type.

This change aims to make Rust code more concise and maintainable, especially in scenarios where the types of
const items are complicated or not easily expressible.

Neo-Zhixing marked this conversation as resolved.
Show resolved Hide resolved

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

You may declare constants and static variables without specifying their types when the type can be inferred
from the initial value. For example:

```rs
const PI = 3.1415; // inferred as f64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally prefer that the actual type of numeric or float types be known rather than picking arbitrary defaults (e.g. i32 or f64). I'm not too keen on it in a local context either tbh but there it's mitigated by the compiler being able to infer the real type from the surrounding code most of the time.

const PI = 3.1415; // error
const PI = 3.1415_f64; // inferred as f64

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer more consistent behavior with let bindings. So let's make a simple vote here:
🎉: const PI = 3.1415; // error
🚀: const PI = 3.1415; // inferred as f64

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a big issue for me either way it's just that a few times I've only later realised a type has been unexpectedly made i32. But it's easily fixed and more of an annoyance than a problem per se. It doesn't help that an i32 is very rarely what I want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it follows the normal rust inference default types then it's at least no worse than what let does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it's worse in the sense that let can use future code to infer the type, so mostly this is a non issue there unless there's a lot of generics involved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly I would most like if the const was of {float} type but people aren't ready for that conversation maybe

static MESSAGE = "Hello, World!"; // inferred as &'static str
const FN_PTR = std::string::String::default; // inferred as fn() -> String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

technically the const would have the function item's type instead of a function pointer type.
https://doc.rust-lang.org/reference/types/function-item.html

Copy link
Author

@Neo-Zhixing Neo-Zhixing Dec 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually a good point - I guess there's not much point to coerce the function item's type into function pointer type for const items. But should we coerce for static items? That way you get to reassign the static items with functions of the same signature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused about why a person would want it as a static at all, so perhaps we shouldn't allow it at all in the first version of this.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Lokathor maybe they just use the const as a quick switch between two cfg implementations?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense as a const but little sense as a static

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when the type is a ZST, like function item types, at runtime, const and static are essentially interchangable. when the type is a function pointer, unless wrapped in something with interior mutability, static is basically just a const with a stable address, IIRC LLVM will still constant-propagate the value to most uses, since it's marked read-only so LLVM knows the value won't change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing implicit coercions into an unknown target type sounds very confusing. If the right-hand side is String::default, then the resulting type should be the actual type of the expression, the function item ZST.

```

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation


The type inference for `const` and `static` will leverage Rust's existing type inference mechanisms. The compiler will infer the type exclusively based on the RHS. If the type cannot be determined or if it leads to ambiguities, the compiler will emit an error, prompting the programmer to specify the type explicitly.


Today, the compiler already gives hint for most cases where the const or static item is missing a type:

```
802 | const A = 0;
| ^ help: provide a type for the constant: `: i32`
```


```
error: missing type for `const` item
--> file.rs:27:26
|
27 | pub const update_blas = SystemStage { system: test_system, stage: vk::Pipeli...
| ^ help: provide a type for the constant: `: render_pass::SystemStage<for<'a> fn(ResMut<'a, AsyncQueues>)>`
```

The implementation should only need to carry over this information and set the type correspondingly
instead of emitting an error.


# Drawbacks
[drawbacks]: #drawbacks

- Potential Loss of Clarity: In some cases, omitting the type might make the code less clear,
especially to newcomers or in codebases where explicit types are part of the documentation style.
It is my belief that this is a choice better left for the developers as in the case of `let` bindings.
Neo-Zhixing marked this conversation as resolved.
Show resolved Hide resolved
- Anything else?

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

- Impact of Not Doing This: Rust code remains more verbose than necessary, especially in complex scenarios, and macro authors face challenges with type specifications.
- Alternative: Allowing the naming of function types as in [#3476](https://github.com/rust-lang/rfcs/pull/3476) may help resolve some of the cases where type inference is needed.

# Prior art
[prior-art]: #prior-art

In [RFC#1623](https://github.com/rust-lang/rfcs/pull/1623) we added `'static` lifetimes to every reference or generics lifetime value in `static` or `const` declarations.


# Unresolved questions
[unresolved-questions]: #unresolved-questions

Should we allow assignment of unnameable types? For example,
```rs
let A = |a: u32| {
Neo-Zhixing marked this conversation as resolved.
Show resolved Hide resolved
123_i32
};

```

```
error: missing type for `const` item
|
28 | const A = |a: u32| {
| ^
|
note: however, the inferred type `[closure@render_pass.rs:28:11]` cannot be named
|
28 | const A = |a: u32| {
| ___________^
29 | | 1_i32
30 | | };
| |_^
```

If this significantly complicates the implementation, we can leave it outside the scope of this RFC.
Neo-Zhixing marked this conversation as resolved.
Show resolved Hide resolved