<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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 id="AppleMailSignature"><br></div><div id="AppleMailSignature"><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px;"><li style="box-sizing: border-box;"><span style="background-color: rgba(255, 255, 255, 0);">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;">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;">lowercaseValues</code> convention a syntactic requirement, as is done in ML and Haskell.</span></li></ul><div>I see that as a good viable alternative.</div></div><div><br>On 06 May 2016, at 06:34, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>To keep progress going on this, I collected my thoughts from March's discussion into a draft proposal:</span><br><span></span><br><span><a href="https://github.com/apple/swift-evolution/pull/299">https://github.com/apple/swift-evolution/pull/299</a></span><br><span></span><br><span>-Joe</span><br><span></span><br><blockquote type="cite"><span>On Mar 9, 2016, at 11:23 AM, Tanner Nelson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hello Swift Evolution members,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I would like to propose making `.self` After a Type optional when referencing Types in expressions.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Here is a demonstration of the current inconsistency. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>```swift</span><br></blockquote><blockquote type="cite"><span>func test<T: Any>(type: T.Type, two: String) {</span><br></blockquote><blockquote type="cite"><span> print(type)</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>func test<T: Any>(type: T.Type) {</span><br></blockquote><blockquote type="cite"><span> print(type)</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>test(Int.self)</span><br></blockquote><blockquote type="cite"><span>test(Int)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>test(Int.self, two: "")</span><br></blockquote><blockquote type="cite"><span>test(Int, two: "") //Expected member name or constructor call after type name</span><br></blockquote><blockquote type="cite"><span> ^~~</span><br></blockquote><blockquote type="cite"><span>``` </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This has been confirmed as a bug, and the report can be seen here <<a href="https://bugs.swift.org/browse/SR-899">https://bugs.swift.org/browse/SR-899</a>>.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>After a Twitter conversation with Joe Groff on the Swift team (<a href="https://twitter.com/jckarter/status/707287663586324481">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></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- Cleaner API</span><br></blockquote><blockquote type="cite"><span>- Consistent requirement is less confusing to developers</span><br></blockquote><blockquote type="cite"><span>- Disambiguation challenges should not result in more verbose code unless absolutely necessary</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Here are some preliminary ideas for how this could be implemented:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- Require spaces around less than expressions and no spaces around generics</span><br></blockquote><blockquote type="cite"><span>- Require spaces around infix operators and no spaces around generics</span><br></blockquote><blockquote type="cite"><span>- Remove less than overload for comparing a type</span><br></blockquote><blockquote type="cite"><span>- (Your idea here)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>A draft of an evolution document that provides more background can be viewed here <<a href="https://github.com/apple/swift-evolution/pull/197">https://github.com/apple/swift-evolution/pull/197</a>>. It has been preempted by a need for discussion in this mailing list. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I am looking forward to hearing your feedback on this proposal.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank you,</span><br></blockquote><blockquote type="cite"><span>Tanner Nelson</span><br></blockquote><blockquote type="cite"><span><a href="http://github.com/tannernelson">http://github.com/tannernelson</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>