+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.
Austin > On May 6, 2016, at 12:04 AM, David Hart via swift-evolution > <[email protected]> wrote: > > 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: > > making the UppercaseTypes, lowercaseValues convention a syntactic > requirement, as is done in ML and Haskell. > I see that as a good viable alternative. > > On 06 May 2016, at 06:34, Joe Groff via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> To keep progress going on this, I collected my thoughts from March's >> discussion into a draft proposal: >> >> https://github.com/apple/swift-evolution/pull/299 >> <https://github.com/apple/swift-evolution/pull/299> >> >> -Joe >> >>> On Mar 9, 2016, at 11:23 AM, Tanner Nelson via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hello Swift Evolution members, >>> >>> I would like to propose making `.self` After a Type optional when >>> referencing Types in expressions. >>> >>> 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. >>> >>> Here is a demonstration of the current inconsistency. >>> >>> ```swift >>> func test<T: Any>(type: T.Type, two: String) { >>> print(type) >>> } >>> >>> func test<T: Any>(type: T.Type) { >>> print(type) >>> } >>> >>> test(Int.self) >>> test(Int) >>> >>> test(Int.self, two: "") >>> test(Int, two: "") //Expected member name or constructor call after type >>> name >>> ^~~ >>> ``` >>> >>> This has been confirmed as a bug, and the report can be seen here >>> <https://bugs.swift.org/browse/SR-899 >>> <https://bugs.swift.org/browse/SR-899>>. >>> >>> After a Twitter conversation with Joe Groff on the Swift team >>> (https://twitter.com/jckarter/status/707287663586324481 >>> <https://twitter.com/jckarter/status/707287663586324481>) it is determined >>> that this requirement is due to difficulty disambiguating generics `Foo<T>` >>> vs infix less-than operations `Foo < T`. >>> >>> I propose to allow Types to be used in expressions without needing to >>> explicitly reference `.self`. The motivation for this is as follows: >>> >>> - Cleaner API >>> - Consistent requirement is less confusing to developers >>> - Disambiguation challenges should not result in more verbose code unless >>> absolutely necessary >>> >>> Here are some preliminary ideas for how this could be implemented: >>> >>> - Require spaces around less than expressions and no spaces around generics >>> - Require spaces around infix operators and no spaces around generics >>> - Remove less than overload for comparing a type >>> - (Your idea here) >>> >>> A draft of an evolution document that provides more background can be >>> viewed here <https://github.com/apple/swift-evolution/pull/197 >>> <https://github.com/apple/swift-evolution/pull/197>>. It has been preempted >>> by a need for discussion in this mailing list. >>> >>> I am looking forward to hearing your feedback on this proposal. >>> >>> Thank you, >>> Tanner Nelson >>> http://github.com/tannernelson <http://github.com/tannernelson> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
