new RFC: static_lifetime_in_statics

[llogiq]

Adding 'static lifetimes to every reference or generics lifetime value in static or const declarations adds no value. So this PR suggests we allow to omit them.

Rendered

[nikomatsakis]

Seems like a reasonable idea; I've thought about proposing a change like this from time to time. There are in fact no other lifetime names in scope at all, so 'static is literally the only thing you could write -- except for within higher-ranked functions and objects.

The RFC is a bit incomplete in that it doesn't seem to spell out how this should interact.

Functions I think work today, so presumably they continue the same:

static foo: fn(&u32) -> &u32 = ...;  // for<'a> fn(&'a u32) -> &'a u32
static foo: &Fn(&u32) -> &u32 = ...; // &'static for<'a> Fn(&'a u32) -> &'a u32

For object types using <>, I presume it defaults to 'static:

trait SomeObject<'a> { ... }
static foo: &SomeObject = ...; // &'static SomeObject<'static>
static foo: &for<'a> SomeObject<'a> = ...; // &'static for<'a> SomeObject<'a>

[llogiq]

Exactly. I will extend the Detailed Design section to include your examples.

[nikomatsakis]

As I wrote, since 'static is the only name in scope, it's certainly not "unsound" -- other names are just a guaranteed compilation error. I'd just drop this sentence.

[llogiq]

Thank you @nikomatsakis for those detailed comments!

[ticki]

I know this might be a little controversial, but I am for allowing full type inference in statics and consts, since it adds a nice symmetry, and makes a lot of things more ergonomic.

[llogiq]

@ticki As I wrote in the Alternatives section, even with full type inference, having the default still allows us to declare the types thus documenting them without writing out all those 'static. On the other hand, if we only added type inference, the extra lifetime annotations would make writing and reading the types so cumbersome that users will likely have rustc infer them. So we should implement this issue especially if we'd later adopt inference.

[ticki]

Sure, I was merely noting. I do support this RFC.

[llogiq]

Full inference would be great. I do however wonder two things: First, will this change give us a good etnough solution for the majority of cases (with its vastly smaller complexity)? And second, would I want to do the inference for complex statics in my head (because I cannot simply read the type if it's inferred, though IDEs could probably help with that)?

Currently I think that on balance for simple cases writing the type is relatively cheap in terms of code size, whereas with more involved types (especially with types containing closures), I'd rather see them written down as documentation. But I may be wrong.

[nikomatsakis]

It would certainly be convenient for us to do inference, but I am wary: it
is a significant complication to the compiler and I'd not be inclined to
undertake it right now, particularly as we are still working out the
interaction of constants, types, and generics. It may be that once we've
worked through that, though, adding inference would be relatively
straightforward (I think that solving these questions nicely will require
us resolving constants more lazilly, and with some kind of live cycle
detection, which we could probably leverage to do type inference there
too).

However, as the RFC argues, even if we did type inference, I imagine some
people will want to write explicit types, and in those cases 'static
feels like a sensible default.

On Fri, May 20, 2016 at 2:37 PM, llogiq [email protected] wrote:

I think full inference would be great. I do wonder two things: First, will
this change give us a good etnough solution for the majority of cases (with
its vastly smaller complexity)? And second, would I want to do the
inference for complex statics in my head (because I cannot simply read the
type if it's inferred, though IDEs could probably help with that)?

Currently I think that on balance for simple cases writing the type is
relatively cheap in terms of code size, whereas with more involved types
(especially with types containing closures), I'd rather see them written
down as documentation. But I may be wrong.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1623 (comment)

[birkenfeld]

I think symmetry with function signatures and other items (public API is explicitly typed) is more important than symmetry with let bindings.

What I sometimes wish for is inference of the length for array types, i.e. being able to write const X: [T; _] = [...].

[ticki]

@nikomatsakis, I certainly agree that there are priorities, and it will likely increase complexity (although I can think of multiple ways to attack this). The change described in this RFC is relatively simple.

@birkenfeld, I disagree. static and const can both be thought of as global variables, and thus in the same class as let bindings.

[llogiq]

@ticki One difference between let bindings and static/const declarations is that the latter two can appear and be used anywhere in the code, whereas the former is confined to its scope. The locality is what changes the balance in favor or against inference, not the declaration semantics.

[ticki]

Yes, but the fundamental concept is the same: they're both value declarations associated with a particular identifier.

[birkenfeld]

@birkenfeld, I disagree. static and const can both be thought of as global variables, and thus in the same class as let bindings.

I don't dispute that. But there isn't only one "class" in which these things can be placed - and I happen to think that consistency within another class - item-level signatures - is more important.

[petrochenkov]

Yes, but the fundamental concept is the same: they're both value declarations associated with a particular identifier.

There are a bunch of "fundamental concepts" lying around here - global vs local, interface vs implementation detail. Not all of them make local variables and constants/statics look similar.

[llogiq]

@ticki I agree that the fundamental concept is the same. I just argue that this is beside the point, because unlike let bindings which have high locality, globals can be all over the place. Consider the following snippet:

static FOO = &[BAR];
// 100 lines of code here
static BAR = ... // whatever
// another 100 lines of code using BAR
.. x == FOO

and now let's say someone changes BAR. The error will appear with the FOO definition and use, though the change was somewhere else. With written types, the error will be at the declaration at fault.

[Ericson2314]

If we ever got contravariance back,

type Foo<'a> = fn(&'a Bar);
static BAZ: Foo = ...;
// BAZ: Foo<'static>

might be a bit weird. Otherwise I like this.

[llogiq]

I'm not sure if we can differentiate between function argument and reference lifetimes. If we could, defaulting only the latter while leaving the former generic would be the best solution.

[glaebhoerl]

The same issue already exists for lifetime elision so there's plenty of precedent.

[huonw]

Another thing that could allow non-'static lifetimes is associated constants, e.g.:

trait Foo<T> { const X: T; }

impl<'a> Foo<&'a u8> for &'a i32 {
    const X: &'a u8 = &0;
}

This doesn't seem particularly problematic on the face of it (especially given associated constants are unstable), but I haven't devoted much thought to it.

[llogiq]

@Ericson2314 @glaebhoerl @huonw I think that's the exact spot where we can strengthen the RFC: By defining the interaction between the 'static default and lifetime elision. My currently favorite solution would be to elide function lifetimes and default reference lifetimes to 'static. This distinction would be carried over into generics. For example, if we have

struct SomeInnerType<'a> {
    foo: &'a [u32]
}

struct SomeType<'a, 'b, 'c: 'a> {
    x: &'a SomeInnerTyp<'c>,
    y: Fn<'b>(&'b Foo) -> &'b Bar
}

we could make a static some_instance : &SomeType = .. which would actually be of type &'static SomeType<'static, 'a, 'static> (so some_instance.x would be a &'static SomeInnerType<'static>, whereas some_instance.y would be a Fn<'a>(&'a Foo) -> &'a Bar).

Note that this would make a difference based on the internals of SomeInnerType. I believe this is acceptable, because it appears to do the right thing in all cases I've come up with so far.

Am I right or did I miss some corner case? (Edit: Fixed the wrong type)

[arielb1]

@llogiq

You can't have for<'a> SomeType<'static, 'a, 'static> because SomeType is not a function or trait.

[notriddle]

Making all the lifetimes inside function pointer constants default to static would be a breaking change.

[TimNN]

@notriddle: If I understand the RFC correctly, it explicitly talks about your example (emphasis mine):

"The 'static default does not override lifetime elision in function signatures"

[notriddle]

I meant to reply to @llogiq. Sorry about the confusion.

[llogiq]

@notriddle The confusion is obviously mine. Thanks for helping to clear it up.

[llogiq]

Now I extended the Design section to hopefully clear up the confusion by describing interaction with a few other features.

[Ericson2314]

@nikomatsakis true. I guess my concern is we'd be providing sugar for something the user probably doesn't intend in that situation, but maybe it's better to be simple and consistent. We could instead just add a lint for inferred 'static in would-be contravariant position.

[donaldpipowitch]

That sounds nice. As a beginner I just stumbled over this a little bit.

[nikomatsakis]

Hear ye, hear ye! This RFC is now entering final comment period. The @rust-lang/lang team is currently inclined to accept the RFC.

The conversation focused on a few points of clarification (e.g., what happens to anonymous bound regions in a fn type signature). It was also pointed out that while 'static is a good default for statics and constants, it is not such a good choice for associated constants, which still require a fully explicit type (seems fine). It may also be a problem in the future if we add lifetime-parameterized modules, but in such a case we can simply disable the default in that context (or address in some other way).

[nrc]

+1

[nikomatsakis]

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

[Boscop]

@nikomatsakis

1. Can we at least allow lifetime elision for associated constants in the impls of traits? So that we don't have to name the lifetime in every impl, e.g.:

pub trait Endpoint {
	const ENDPOINT: &'static str;
	// ...
}

impl Endpoint for UserList {
	const ENDPOINT: &str = "user/list";
	// ...
}

impl Endpoint for UserEdit {
	const ENDPOINT: &str = "user/edit";
	// ...
}

2. Could we maybe also allow omitting the type for associated constants in the impls?