Can't compile type with lifetime bound in certain order

[frewsxcv]

This compiles:

fn lol<'a>() -> Box<Iterator<Item=()> + 'a> {
    unimplemented!()
}

fn main() {
}

This doesn't:

fn lol<'a>() -> Box<Iterator<'a + Item=()>> {
    unimplemented!()
}

fn main() {
}

Error:

rustc 1.16.0-nightly (1a2ed98d3 2017-01-13)
error: expected `,` or `>` after lifetime name, found `+`
 --> <anon>:1:24
  |
1 | fn lol<'a>() -> Box<'a + Iterator<Item=()>> {
  |                        ^
  |
note: did you mean a single argument type &'a Type, or did you mean the comma-separated arguments 'a, Type?
 --> <anon>:1:21
  |
1 | fn lol<'a>() -> Box<'a + Iterator<Item=()>> {
  |                     ^^^^

error: aborting due to previous error

[frewsxcv]

cc @rkruppe

[hanna-kruppe]

The two snippets above are slightly different in where the lifetime applies (Iterator vs. Item). This is shorter and doesn't have such a difference:

type A<'a> = Box<Display + 'a>;
type B<'a> = Box<'a + Display>;

[petrochenkov]

I'm actually working on this right now (I started redoing #37511, but the scope has grown).
Ideally, anything acceptable as a bound list (the part of T: 'a + ?Sized + Trait + for<'a> Trait2<'a> after :) should be accepted as a (trait object) type as well (at parse time).
There are some ambiguities however and the compiler has a bunch of parsing quirks to address them right now. Not accepting lifetimes as first elements in a type sum is one of them.

[petrochenkov]

So, #40043 landed without a fix for this issue (see #40043 (comment) and below).
@nikomatsakis @withoutboats and @solson were mildly-against/mildly-for/undecided with regards to this change, so it is not implemented yet, but may be implemented in the future.

Arguments for:

• (technical) Bounds in other contexts can start with a lifetime bound - fn f<T: 'a + Trait>() {}, fn f() -> impl 'a + Trait, but bounds in trait objects should start with a type and Box<'a + Trait> is not permitted, this is an inconsistency in the grammar.
• (technical) 'a + Trait is syntactically unambiguous and can be trivially supported.
• (philosophical) If A + B is supported, then B + A should be expected to work as well.

Arguments against:

• (philosophical) 'a + Trait is not an idiomatic style, Trait is usually the most important component and goes first.
• (philosophical) If Box<'a> is not supported, then Box<'a + Trait> shouldn't be as well.
• (philosophical) 'a is parsed as a lifetime and not as a type, but 'a + is parsed as a type (but rejected later by a semantic check), this looks strange, trailing +s look strange in general though.