<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="">+1 to David's point. Given that Swift's naming conventions already diverge from C's (and we have things like 'Self' vs 'self'), it seems like enforcing this relatively uncontroversial best practice would be an overall win.<div class=""><br class=""></div><div class="">Austin<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 6, 2016, at 12:04 AM, David Hart 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=utf-8" class=""><div dir="auto" class=""><div class="">I understand why the alternative of changing the generic type parameter list symbols was rejected, to be consistent with other C based languages, but I don't understand why the following was rejected:</div><div class=""><br class=""></div><div class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px;" class=""><li style="box-sizing: border-box;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">making the <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">UppercaseTypes</code>, <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">lowercaseValues</code> convention a syntactic requirement, as is done in ML and Haskell.</span></li></ul><div class="">I see that as a good viable alternative.</div></div><div class=""><br class="">On 06 May 2016, at 06:34, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">To keep progress going on this, I collected my thoughts from March's discussion into a draft proposal:</span><br class=""><span class=""></span><br class=""><span class=""><a href="https://github.com/apple/swift-evolution/pull/299" class="">https://github.com/apple/swift-evolution/pull/299</a></span><br class=""><span class=""></span><br class=""><span class="">-Joe</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Mar 9, 2016, at 11:23 AM, Tanner Nelson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Hello Swift Evolution members,</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I would like to propose making `.self` After a Type optional when referencing Types in expressions.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Currently, to pass a Type to a function or method, it is sometimes required to add `.self` after the Type. This behavior is inconsistent as it is only required if the signature has more than one parameter. </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Here is a demonstration of the current inconsistency. </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">```swift</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">func test<T: Any>(type: T.Type, two: String) {</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""> print(type)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">}</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">func test<T: Any>(type: T.Type) {</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""> print(type)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">}</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">test(Int.self)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">test(Int)</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">test(Int.self, two: "")</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">test(Int, two: "") //Expected member name or constructor call after type name</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""> ^~~</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">``` </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span 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>>.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">After a Twitter conversation with Joe Groff on the Swift team (<a href="https://twitter.com/jckarter/status/707287663586324481" class="">https://twitter.com/jckarter/status/707287663586324481</a>) it is determined that this requirement is due to difficulty disambiguating generics `Foo<T>` vs infix less-than operations `Foo < T`.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I propose to allow Types to be used in expressions without needing to explicitly reference `.self`. The motivation for this is as follows:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Cleaner API</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Consistent requirement is less confusing to developers</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Disambiguation challenges should not result in more verbose code unless absolutely necessary</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Here are some preliminary ideas for how this could be implemented:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Require spaces around less than expressions and no spaces around generics</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Require spaces around infix operators and no spaces around generics</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- Remove less than overload for comparing a type</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">- (Your idea here)</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">A draft of an evolution document that provides more background can be viewed here <<a href="https://github.com/apple/swift-evolution/pull/197" class="">https://github.com/apple/swift-evolution/pull/197</a>>. It has been preempted by a need for discussion in this mailing list. </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I am looking forward to hearing your feedback on this proposal.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Thank you,</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Tanner Nelson</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="http://github.com/tannernelson" class="">http://github.com/tannernelson</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></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></div></body></html>