<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 9, 2016, at 3:03 PM, Tanner Nelson <<a href="mailto:me@tanner.xyz" class="">me@tanner.xyz</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">"our type system is sufficiently stronger than that other language..."</div><div class=""><br class=""></div><div class="">I was just writing a response that said exactly this. It's really impossible in Swift to be unknowingly sending the wrong types around. </div><div class=""><br class=""></div><div class="">If the agreement seems to be leaning toward figuring out a way to remove `.self`, what would the next steps be to start concretely seeing which implementations might work / be realistic?</div></div></div></blockquote></div><br class=""><div class="">I see two problems to solve:</div><div class=""><br class=""></div><div class="">A) Decide a grammar rule to distinguish the operator '<' from the generic parameter bracket, and</div><div class="">B) Decide a semantic rule to distinguish type "operators" like '[T]', 'T?', etc. from value operations.</div><div class=""><br class=""></div><div class="">For (A), we should look at the new places a generic type might appear in expressions:</div><div class=""><br class=""></div><div class="">- By itself:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">let x = Foo< T ></div><div class="">bar() // following statement</div><div class=""><br class=""></div><div class="">let y = Foo< T, U ></div><div class="">bar() // following statement</div><div class=""><br class=""></div></blockquote>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.<div class=""><br class=""></div><div class="">- As a function parameter, or array or dictionary element:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">sizeof(Foo<T>)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">load(Foo<T>, atOffset: 8)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let types = [Foo<T>, Bar<U>]</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let factories = [Foo<T>: makeFoo, Bar<U>: makeBar]</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote>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 `>:`.<div class=""><br class=""></div><div class="">- As the parameter to an operator:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">++Foo<T> // prefix</div><div class="">Foo<T>++ // postfix</div><div class="">Foo<T>+Bar<U> // infix</div><div class="">Foo<T> + Bar<U></div><div class="">let foo = Bar<U></div><div class=""><br class=""></div></blockquote>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.<div class=""><br class=""></div><div class="">For (B), as I mentioned before, it makes the choice between [T] becoming 'Array<T>' or becoming an array containing 'T' a bit of an overload resolution problem. In most cases we can probably favor the type sugar, either by argument type context or by syntactically recognizing `T` as a static type reference and favoring the type sugar interpretation over the array literal implementation. Doug or Joe Pamer probably have opinions here.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>