Can 'lifetime become a valid "trait object" type?

[petrochenkov]

I'm going to fix #39085 by accepting arbitrary bound lists as trait object types and trying to figure out future compatibility concerns.

Consider these examples:

#![feature(conservative_impl_trait)]

// Static anonymization via associated type
trait Tr {
    type A: Send; // We know only that A is Sized + Send
    type B: 'static; // We know only that A is Sized + 'static
    type C; // We know only that C is Sized
}

// Static anonymization via impl Trait
fn f() -> impl Send {} // We know only that returned type is Sized + Send
fn g() -> impl 'static {} // We know only that returned type is Sized + 'static
fn h() -> impl {} // We know only that returned type is Sized
// Fun fact: `h` is currently parsed successfully and rejected by a semantic check

// Dynamic anonymization via trait objects
fn i<'a>(arg: &'a Send) {} // We know that the argument is Sized + Send
fn j<'a>(arg: &'a 'static /*What?*/) {} // We know that the argument is Sized + 'static
fn k<'a>(arg: &'a /*WTF, I don't even. Also ambiguity.*/) {} // We know that the argument is Sized

fn main() {}

As you can see there are two interesting cases - the list is empty and the list contains a single lifetime bound.

I'm not seriously considering *nothing* becoming accepted as a valid type at parse time, but 'lifetime case is more ambiguous.
I don't see syntactic or semantic reasons to prohibit something like plain 'static from being used in impl Trait type or an object type, maybe it can even be useful sometimes? So far I'm going to structure the parsing code with this possibility in mind.

cc @nikomatsakis @eddyb

[nikomatsakis]

My preference would be to disallow it. I agree there is no particular reason to do so, but there is also little reason to accept it, and I would rather start out more conservatively and expand later. =)