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]> 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 > > -Joe > >> On Mar 9, 2016, at 11:23 AM, Tanner Nelson via swift-evolution >> <[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>. >> >> After a Twitter conversation with Joe Groff on the Swift team >> (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>. 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 >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
