Warn when lifetime parameters are unused.

[thestinger]

UPDATE: Updating this issue to reflect current thinking, which is that inference should issue a warning when a lifetime parameter is inferred to be bivariant (which implies that the parameter is unused).

ORIGINAL: It's sometimes necessary to specify a lifetime on an object that doesn't contain borrowed pointers, because lifetime dependencies can be required for safety outside of Rust's borrowed pointer system. A dummy borrowed pointer member is a workaround, but wasteful.

@nikomatsakis

[catamorphism]

Nominating for milestone 3, feature-complete

[graydon]

accepted for feature-complete milestone

[nikomatsakis]

@thestinger why not just use &'v T in the iterator types, and convert to unsafe pointers as needed? I am nervous about the implicit variance associated with unused lifetime parameters.

[Kimundi]

This seems to work now:

struct Foo<'a>;

[Kimundi]

...but there seem to be issues: #10703

[nikomatsakis]

To expand on my previous comment, which was quite terse --

I see four options:

Option 1. Leave things as they are. This means that unused lifetime parameters are a bit of a footgun, because people seem to expect them to behave in a contravariant fashion (as described by @thestinger and in #10703).

Option 2. If inference finds that a lifetime parameter is bivariant (effectively, unused), default to contravariant, which seems to be what people expect. This means that a lifetime "can only get shorter", much like the lifetime 'a in the type &'a Foo. I am a bit nervous about this in that there is an undocumented assumption -- that the lifetime parameter will behave a certain way -- that can easily be changed.

For example, if I have struct Foo<'a> { x: int } and then I change this to struct Foo<'a> { x: int, y: fn() -> &'a int } then Foo goes from being contravariant with respect to 'a to covariant. This is of course always a danger in inference but somehow it seems dangerous to me that adding additional fields can "flip" the role of a lifetime parameter in this way. I guess it's because it is clear that the user had some kind of role in mind for that lifetime parameter that was represented by the field x but the type checker is not aware of that role -- e.g., the parameter 'a was supposed to be the lifetime of the array that x is an index into or something. This means that the field x "wants" 'a to be contravariant but the type checker doesn't know it. What's scary to me is that the inference will get the desired result up until an additional use 'a is added -- at that point, it should be generated invariant, but it will generate covariant instead.

Option 3. Report an error for bivariant lifetime parameters. This is unfortunate in that one can imagine legitimately wanting a bivariant lifetime parameter in some unusual cases. (The same is true of the previous case)

Option 4. Add the ability to specify variance explicitly, and then report an error for bivariant lifetime parameters. This seems reasonable but requires people to know what "variance" means. I imagine a syntax like +'a (covariant), -'a (contravariant), ='a (invariant), and *'a (bivariant).

All of this applies equally to type parameters, incidentally.