proc bounds and closure lifetimes are parsed incorrectly

[Kimundi]

<kimundi> If you have a function that takes a reference to a closure the lifetime specifier becomes confusing
<kimundi> fn foo(&|T| -> U), fn foo(&'a |T| -> U) and fn foo(&'a 'a |T| -> U) are all valid, and in the second one you can't tell which one of both the lifetimes is supposed to belong to
<nmatsakis> kimundi: this is parser bug, 'a |T| shouldn't parse
<nmatsakis> it should be |T|:'a

<nmatsakis> the parser may well be wrong
<nmatsakis> maybe got overlooked

<kimundi> well, if I change to that syntax I get compile errors
<kimundi> this works: impl<'a> StringPrefixMatch for 'a |$self_anon| -> bool
<kimundi> this doesn't: impl<'a> StringPrefixMatch for |$self_anon|:'a -> bool
<kimundi> I get a "'static is the only valid region allowed here" error

<nmatsakis> kimundi: I think it's just a parser bug
<nmatsakis> kimundi: yes, I can understand why that would occur
<kimundi> why?

<nmatsakis> kimundi: basically because some cleanup is needed
<nmatsakis> we are interpreting |...|:K with K as a list of bounds , which is correct,
<nmatsakis> but we currently haven't implemented support for arbitrary lifetimes in bounds,
<nmatsakis> which is wrong,
<nmatsakis> and instead we have special case treatment for closures,
<kimundi> Ah, so it only accepts the 'static bound there
<nmatsakis> which kind of fit ok with the old syntax,
<nmatsakis> but in the newer one we really should be just using general lifetimes in bounds

[Kimundi]

cc @nikomatsakis

[pnkfelix]

cc me

[pnkfelix]

Note in particular that attempting to make 'a |T| -> U a type expression leads to ambiguities when parsing a generic instantiation where you are trying to pass a closure type as the type parameter, like Foo<'a |T| -> U>, because the parser will eagerly treat the Foo<'a prefix as a lifetime parameter being passed to Foo, and thus it expects a comma next.

(An easy work-around for the type being is to use a type declaration like
type closure<'a, T, U> = 'a |T| -> U;
and then you can instantiate Foo on the type closure<'a, T, U>.)

[flaper87]

cc @flaper87

[nikomatsakis]

Another parser issue: something like proc:Send doesn't parse

[nikomatsakis]

Nominating.

[pnkfelix]

Assigning 1.0, P-backcompat-lang

[emberian]

cc me

[nikomatsakis]

For reference, I believe the syntax ought to be:

T = '|' ( id : T ) * '|' [ ':' K ] [ '->' T ]
  | 'proc' '(' ( id : T ) * ')' [ ':' K ] [ '->' T ]
  | ...
K = TraitReference | Lifetime 

[nikomatsakis]

Except of course that parameter lists are comma-separated

[alexcrichton]

I'm assuming that with that syntax you can also have multiple K values +-separate? Would I be correct in these translations:

'a || => ||: 'a
||: 'static => ||: 'static
'a ||: Send => ||: 'a + Send

[nikomatsakis]

yes, except that ||: 'a + Send is kind of inherently contradictory. I imagine Send should imply 'static, but I'm not quite sure what needs to be done in the code to make that happen. cc #10296

[alexcrichton]

Hm, so one thing I just realized is that the lifetimes don't necessarily translate to a bound on the environment, but they could also serve to connect arguments together. For example:

||: 'a // environment is bounded by 'a
<'a> |&'a Foo| -> &'a int // 'a used to connect parameters

Currently, the lifetime introduction syntax (<'a>) causes problems in generics because << is one token instead of two. This could be fixed in the parser, but I wanted to ensure that this was the syntax that we wanted before modifying the parser.

[nikomatsakis]

@alexcrichton right, I expect that <'a> can be used in the way you show. You can of course combine these: <'a> |&'a Foo|: 'b -> &'a int

[nikomatsakis]

the problem of parsing << incorrectly is something we also have for && and >> -- we've hacked it for >>