[swift-evolution] Making `.self` After `Type` Optional

[Austin Zheng]

+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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160506/6ca8baf6/attachment.html>