Pre-RFC: Elide type annotations from const and static Items

[kornel]

For integers I’d rather have Go-like untyped numbers: Pre-RFC: Untyped constants

[aturon]

It’d be great to see a larger suite of motivating examples where this helps, examples where elision won’t be allowed, and examples where elision is allowed but possibly dubious (in that it’s difficult for a human to discern the type). These will help us judge the tradeoffs involved.

I agree with others that, at the outset, we should not employ any inference fallback (both for numeric literals, but also ideally for trait input types as well).

[nikomatsakis]

Infer a type only if the type is completely determined by the right-hand side of the declaration. So 42i32 is fine, but 42 is not.

I’m not sure if we can do this easily, unless we just skip the “integer fallback step” in constants in general. This is probably backwards incompatible. Well, ok, I take that back. I suppose that we can have a special step for constants – basically, before we apply any type variable fallback (I don’t think this is specific to integers), we will check that the final type of the expression is fully determined, and does not contain any type variables. Seems plausible.

Still, I’m not sure how much I care about

pub const FOO = 22;

inferring to the type i32. I’m not sure how realistic it is that you export a constant that you don’t ever use…at worst you can issue a new semver or deprecate the existing constant and issue a new one.

[nikomatsakis]

So to answer the question we should probably coerce them to fn types and display that as the type in rustdoc?

This is sort of side-stepping the problem. Doesn’t mean it’s the wrong answer, but having a fn() is not entirely equivalent to a closure type, since (a) it has non-zero size and (b) calls to it are virtual calls. Point (a) might matter if you do something like Box::new(F), where const F = || 22;. In that case, if the type of F is a zero-sized closure, then Box::new(F) doesn’t actually allocate anything.

[nikomatsakis]

I agree with others that, at the outset, we should not employ any inference fallback (both for numeric literals, but also ideally for trait input types as well).

To clarify, do you mean that we would do no inference fallback at all? I was thinking that this is not backwards compatible, but I guess we could continue doing inference fallback for constants with an explicit type. Or we could use the rule I suggested – that before fallback, we check that the result type itself is fully inferred, rather than skipping fallback altogether.

Can you give an example of what you mean with respect to trait input types? Do you mean that we would modify the way that trait selection works?

[jschuster]

For integers I’d rather have Go-like untyped numbers: Pre-RFC: Untyped constants

That sounds like a recent RFC for polymorphic constants, which was postponed. My impression from that discussion is that while the idea is good, it would be better to have a separate syntax for those kinds of constants. So I think that might be an orthogonal issue to this one.

[jschuster]

Still, I’m not sure how much I care about

pub const FOO = 22;

inferring to the type i32. I’m not sure how realistic it is that you export a constant that you don’t ever use…at worst you can issue a new semver or deprecate the existing constant and issue a new one.

That’s a fair point, and the breakage would only happen if someone adds/removes an annotation in an already published crate, which I’m guessing would be a rare occurrence (but perhaps someone else knows better?). Consistency with let would certainly be nice.

before we apply any type variable fallback (I don’t think this is specific to integers)

Can you think of examples other than integers and floats? Those are the only valid const expressions I could find that have multiple possible typings, but I might have missed some.

I do think all such fallbacks in const/static items should follow the same principle, though, whether it’s to always use the fallback, or never, or whatever it may be. Like @aturon and @withoutboats, I lean towards option 1 because of backwards compatibility (and we could always loosen the rule later), but the inconsistency there in both the typechecker and the programmer’s mental reasoning might make option 3 a worthwhile solution instead.

[nikomatsakis]

Can you think of examples other than integers and floats? Those are the only valid const expressions I could find that have multiple possible typings, but I might have missed some.

I don’t think there are other cases today where uninferred type variables with fallback could end up in the final type, but I think there could easily be such cases in the future. For example, we’ve talked about user-specified forms of fallback (e.g., for custom allocators), and we’ve also floated ideas about changing how the fallback to ! works. (For example, I was considering that the type of Ok('a') perhaps ought to be Result<char, ?T> where ?T is a variable that falls back to !.)

In any case, the other thing to consider is something like this (which, even if it doesn’t work now, will work soon-ish):

const fn foo<T>(_: T) -> char { 'a' }
const X = foo(22);

Do we want to disallow 22 here from falling back to i32, even though the final type of X will be char either way?

[kornel]

There’s only one simplest syntax const FOO = 1, so both features can’t have it. AFAIK if Rust had Go-like constants then inference for integer constants wouldn’t even be needed, so that one syntax could be used for the most broadly applicable feature.

OTOH, if this simple syntax was taken for inference, then polymorphic constants would have to use a more complex syntax. Sadly, from the RFC that seems to be where Rust is heading. I’m not enthusiastic about that. While it is sort-of consistent with the rest of Rust (FOO<T: Integer>: T = 25), it’s IMHO ugly and brings complexity of generics and special traits to a thing that in other languages is just a “plain” simple number.

[jschuster]

It’d be great to see a larger suite of motivating examples where this helps, examples where elision won’t be allowed, and examples where elision is allowed but possibly dubious (in that it’s difficult for a human to discern the type). These will help us judge the tradeoffs involved.

Here are a few. If I think of other scenarios over the next few days I’ll try to add examples for them.

These examples should all allow their types to be elided:

const A: bool = true;
const B: i32 = 42i32;
const C: &str = "hello";
const D: (f32, f32) = (1.0f32, 2.0f32);
const E: [i64; 3] = [1i64, 2i64, 3i64];

// structs with explicit types on numeric arguments are definitely okay
struct Foo {
    a: i32;
}
const F: Foo = Foo { a: 5i32 };

// slightly modified from an example @withoutboats provided on IRC
struct SomeType {
    x: bool,
    y: bool,
}

const INPUTS: &'static [(&'static str, SomeType)] =
    &[("abc", SomeType { a: true, b: true}), ("def", SomeType { a: false, b: false}), ...];

Eliding types for string literals (as in C above) could be especially helpful for beginners to delay having to learn the nuances of Rust’s string-handling.

Type elisions on the following could do “the right thing” if fallback is used, but later changes to them could potentially cause issues that wouldn’t been immediately (although as @nikomatsakis points out, it’s unlikely a constant would be exported without being used AND have a type annotation added or removed):

const X: i32 = 5;
const Y: (f64, f64) = (1.0, 3.14);

The following examples would give the wrong type if fallback is used and their annotations are elided, although the typechecker would likely catch the issue, and programmers would likely expect the inferred types to differ from these annotations:

const Z: f32 = 2.5;
const W: [i16; 4] = [1, 2, 3, 4];
const V: (f32, f64) = (1.0, 5.4); // probably unlikely, but a possible unlikely case

Struct arguments are interesting, as well. For instance, consider these:

struct Foo {
    a: i32
}

struct Bar {
    a: i64
}

const F = Foo { a: 1 };
const G = Bar { a: 2 };

Both of those have a unique typing, so I think they should be acceptable. So to me, the main question around fallback is whether it should be used if the expression has multiple possible types (as in const N = 5).

In any case, the other thing to consider is something like this (which, even if it doesn’t work now, will work soon-ish):

const fn foo<T>(_: T) -> char { ‘a’ } const X = foo(22);

Do we want to disallow 22 here from falling back to i32, even though the final type of X will be char either way?

Hmm, that’s tricky. I’ll have to give generic const functions more thought.

[petrochenkov]

While it is sort-of consistent with the rest of Rust (FOO<T: Integer>: T = 25), it’s IMHO ugly and brings complexity of generics and special traits to a thing that in other languages is just a “plain” simple number.

(Duplicating what I wrote in the RFC comments) It’s better when impl Trait shortcut from RFC 1951 is used:

// "impl Integer" == "any Interger" here, not "some Integer"
const FOO: impl Integer = 25;

[nikomatsakis]

Hmm, that’s tricky. I’ll have to give generic const functions more thought.

Heh, I don’t think it’s particularly tricky. I think the answer is that we do want to accept such a thing, even if we are trying to be conservative. This is why I was specific about restricting unbound type variables (of any kind) from appearing in the output type before we apply fallback, but not from existing at all.

Currently, the type-checker works by first doing a “pre-pass” that collects constraints, then solving constraints that are yet unsolved, and then applying fallback for any variables that remain unbound. We could easily interject between these phases. I do however hope in the future plan to consider having these phases “bleed together a bit more”, in which case we might have to revisit these considerations.

[jschuster]

Oh, I see what you mean now. Yes, given that type-checking process, I think your proposed output type rule makes sense.

[jschuster]

@aturon Could you give an example of what you meant by fallback for trait input types? I don’t know what that would be.

[aturon]

Yes, sorry, that was pretty obscure. “Input” type refers to either Self or a type parameter for a trait (as opposed to an associated type). We will infer an input type in certain cases where we can narrow down possible impls such that there’s only one type to choose:

trait Convert<T> {
    fn convert(self) -> T;
}

impl<T> Convert<T> for T {
    fn convert(self) -> T {
        self
    }
}

impl Convert<u64> for u32 {
    fn convert(self) -> u64 {
        self as u64
    }
}

fn main() {
    let x = true.convert(); // type `bool` inferred, it's the only choice
    let y = 0u32.convert(); // error: cannot infer type, two possible choices
}

It’s going to be pretty rare, I think, for this kind of thing to show up in const exprs, but it could happen.

[jschuster]

trait Convert<T> { fn convert(self) -> T; }

impl<T> Convert<T> for T { fn convert(self) -> T { self } }

impl Convert<u64> for u32 { fn convert(self) -> u64 { self as u64 } }

fn main() { let x = true.convert(); // type bool inferred, it’s the only choice let y = 0u32.convert(); // error: cannot infer type, two possible choices }

It’s going to be pretty rare, I think, for this kind of thing to show up in const exprs, but it could happen.

Is there a fallback rule here, or is this just another example of requiring the expressions to be fully inferred? The problem with expressions with numeric literals is that if you remove the type annotation, the type may change (but still pass the typechecker) because fallback says “if the literal’s type is still unconstrained after inference, use the default of i32/f64”. I don’t see a similar kind of “default” rule here that would cause the type of x or y to change without a type annotation: each one can pass the typechecker only if it has a unique type.

[nikomatsakis]

It’s going to be pretty rare, I think, for this kind of thing to show up in const exprs, but it could happen.

I thought this might be what you mean. It would be pretty hard, at least with the current setup of type checking, for us to prevent the type of a const from being influenced by this sort of thing. It’s not like this is some sort of “fallback” step that occurs at a discrete point in time – we’d need like a modal switch.

[aturon]

It’s not like this is some sort of “fallback” step that occurs at a discrete point in time – we’d need like a modal switch.

Yeah, I was thinking about the Chalk model we’ve been talking about, which views this as more of a fallback. But this also seems very deep into the weeds and shouldn’t block getting an RFC together here.

[nikomatsakis]

Yeah, I was thinking about the Chalk model we’ve been talking about, which views this as more of a fallback. But this also seems very deep into the weeds and shouldn’t block getting an RFC together here.

It’s an interesting point, though, that this will be the first case where tweaks to our inference scheme have the potential to change your public API (though I would wager it’s a rather unlikely circumstance, but certainly not impossible). Still, as you say, I think we should move forward, but consider carefully when we decide to stabilize (we may have made progress in bringing chalk-like stuff to rustc by then, for one thing, or with the defaulting and fallback story).

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.