<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 11:05 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Mar 10, 2016, at 9:19 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">For (A), we should look at the new places a generic type might appear in expressions:<br class=""><br class="">- By itself:<br class=""><br class="">let x = Foo< T ><br class="">bar() // following statement<br class=""><br class="">let y = Foo< T, U ><br class="">bar() // following statement<br class=""><br class="">This doesn't strike me as a huge problem to parse as a type reference, since 'a < b > c' is unlikely as an expression, and we don't have commas in the top level of the grammar, so 'a < b, c > d' is impossible as a top-level expression. Extending the lookahead rule to include `>;` or `> *token on next line*` as disambiguators is probably OK.<br class=""><br class="">- As a function parameter, or array or dictionary element:<br class=""><br class="">sizeof(Foo<T>)<br class="">load(Foo<T>, atOffset: 8)<br class="">let types = [Foo<T>, Bar<U>]<br class="">let factories = [Foo<T>: makeFoo, Bar<U>: makeBar]<br class=""><br class="">This is probably the most common use case for type references, and the easiest to support, since the parameters are always followed by a token that can't start an expression by itself. We could extend the current lookahead rule to ensure it includes `>)`, `>,` and `>:`.<br class=""><br class="">- As the parameter to an operator:<br class=""><br class="">++Foo<T> // prefix<br class="">Foo<T>++ // postfix<br class="">Foo<T>+Bar<U> // infix<br class="">Foo<T> + Bar<U><br class="">let foo = Bar<U><br class=""><br class="">This one's a bit interesting since `>+` or `>++` could be operators themselves. Applying operators to types might not be a compelling enough reason to block the other changes, though.<br class=""></blockquote><br class="">Well, comparison `>` is an infix operator. Could we treat generic parameter list `>` as a postfix operator? That is, require whitespace (or at least something that is neither operator nor identifier, like a parenthesis or dot) to its right but not its left? That would require looking all the way through the generic parameter list to the end, but we could bail early if we encounter something that can't be in a generic parameter list (as far as I can tell, that includes identifiers and dots, angle brackets and commas, and characters used in type shorthand).<br class=""></div></div></blockquote></div><br class=""><div class="">Possibly. However, treating `>` as a postfix operator would conflict with the current standard library formatting conventions, which prefer to split long generic parameter lists K&R-style like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func foo<</div><div class=""> T where...</div><div class="">>(</div><div class=""> args...</div><div class="">) {</div><div class=""> code...</div><div class="">}</div><div class=""><br class=""></div></blockquote>-Joe</body></html>