<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="">I strongly agree for the removal of .self. I remember it being a great source of confusion when I first learned Swift.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Mar 2016, at 00:03, Tanner Nelson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 5:57 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Mar 9, 2016, at 2:28 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Wed Mar 09 2016, Brent Royal-Gordon <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I would like to propose making `.self` After a Type optional when referencing Types in expressions.<br class=""></blockquote><br class=""><blockquote type="cite" class="">This has been confirmed as a bug, and the report can be seen here <<a href="https://bugs.swift.org/browse/SR-899" class="">https://bugs.swift.org/browse/SR-899</a>>.<br class=""><br class="">After a Twitter conversation with Joe Groff on the Swift team<br class="">(<a href="https://twitter.com/jckarter/status/707287663586324481" class="">https://twitter.com/jckarter/status/707287663586324481</a>) it is<br class="">determined that this requirement is due to difficulty disambiguating<br class="">generics `Foo<T>` vs infix less-than operations `Foo < T`.<br class=""></blockquote><br class="">My understanding from previous Twitter discussions is that the primary<br class="">reason for this feature is to keep you from writing `Foo` where you<br class="">meant `Foo()`. That is, it's a deliberate design, meant to keep you<br class="">from making mistakes. I suspect that you will have to overcome *that*<br class="">impulse, not just any narrow parsing issue.<br class=""></blockquote><br class="">That is correct. Before 1.0, Swift used to work without ".self"; we<br class="">started requiring ".self" because one of the Swift designers<br class="">with experience in other languages that didn't require ".self" said that<br class="">it was a persistent source of confusion for users.<br class=""><br class="">Personally, I've always disliked what ".self" did to my source code, but I<br class="">have no basis on which to argue with that other designer's experience.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">As the designer in question, I've come around to this as well; our type system is sufficiently stronger than that other language that I think the consequences of accidentally typing `let x = Int` when you meant `let x = Int()` are far easier to understand. However, `.self` is also a bit of load-bearing duct-tape that currently supports some other parsing aspects of Swift's syntax. We have a bunch of type sugar syntax that's overloaded with expression syntax, such as Int?, [Int], [String: Int], and (String, Int); we currently handle this by special-casing the sugar forms when they appear as the LHS of a member lookup or function call. We could address that problem by treating it more like an overload resolution problem, and say that applying `[]`, `[:]`, `?`, or `(,)` to type references always favors building a type reference over forming an array/dictionary/optional/tuple. There's also the lower-level parsing problem with generic parameter brackets that Tanner mentioned in his leading email. We stole the same trick that C# uses to disambiguate `Foo<T, U>(x)` from `(Foo < T), (U > (x))` without relying on name lookup; we assume that a type reference in an expression is always the root of a member lookup or constructor call, and that 'x > (y)' is sufficiently unlikely given the low relative precedence of >, that we can look ahead after we see a '<' to find a '>.' or '>(' token pair and favor the parse as a generic parameter list in those cases. If we're going to break the invariant that type references in expressions are always followed by a member lookup or constructor call, we'll need an alternative disambiguation scheme.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">-Joe</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>