Custom operators can't end in < but should be able to

[alex-pinkus]

With the current setup, ending a custom operator in a < would create ambiguity with function type parameters. Take, for example, this case:

public func ??<V : Value>(optional: Expression<V?>, defaultValue: V) -> Expression<V> {
    return Expression(optional.inner() ?? defaultValue)
}

If my operator were allowed to end in <, this would be interpreted as implementing ??<, and would fail shortly thereafter since V: Value > is not expected here. Somehow the actual swiftc is able to look past this and the code compiles just fine.

I've hacked around this for now by excluding < from being a legal last character in custom operators. This is almost always fine, but is not correct at all. I can think of one way to fix this (there may be others):

1. Move the custom operator rule to externals -- see issue 5.
2. Add some marker rule in externals that flags that we're in a function declaration position, so that scanner.c can special case this.
3. When detecting a custom_operator in scanner.c, if we're in a function declaration, stay one character behind with mark_end.
4. When we reach the end, check the lookahead character. If it isn't (, then lop off the last character of the custom operator (i.e. return without calling mark_end again).

Is there a less weird and special-cased way to do it? Maybe!

[alex-pinkus]

I did this more simply in #41 by just redefining custom_operator as seq(CUSTOM_OPERATORS, optional("<")) and adding it to the conflict table. We're definitely going to need to move the custom operator to scanner.c, but not today.