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

[Tanner Nelson]

"our type system is sufficiently stronger than that other language..."

I was just writing a response that said exactly this. It's really impossible in Swift to be unknowingly sending the wrong types around. 

If the agreement seems to be leaning toward figuring out a way to remove `.self`, what would the next steps be to start concretely seeing which implementations might work / be realistic?

> On Mar 9, 2016, at 5:57 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Mar 9, 2016, at 2:28 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Wed Mar 09 2016, Brent Royal-Gordon <swift-evolution at swift.org> wrote:
>> 
>>>> I would like to propose making `.self` After a Type optional when referencing Types in expressions.
>>> 
>>>> 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`.
>>> 
>>> My understanding from previous Twitter discussions is that the primary
>>> reason for this feature is to keep you from writing `Foo` where you
>>> meant `Foo()`. That is, it's a deliberate design, meant to keep you
>>> from making mistakes. I suspect that you will have to overcome *that*
>>> impulse, not just any narrow parsing issue.
>> 
>> That is correct.  Before 1.0, Swift used to work without ".self"; we
>> started requiring ".self" because one of the Swift designers
>> with experience in other languages that didn't require ".self" said that
>> it was a persistent source of confusion for users.
>> 
>> Personally, I've always disliked what ".self" did to my source code, but I
>> have no basis on which to argue with that other designer's experience.
> 
> As the designer in question, I've come around to this as well; our type system is sufficiently stronger than that other language that I think the consequences of accidentally typing `let x = Int` when you meant `let x = Int()` are far easier to understand. However, `.self` is also a bit of load-bearing duct-tape that currently supports some other parsing aspects of Swift's syntax. We have a bunch of type sugar syntax that's overloaded with expression syntax, such as Int?, [Int], [String: Int], and (String, Int); we currently handle this by special-casing the sugar forms when they appear as the LHS of a member lookup or function call. We could address that problem by treating it more like an overload resolution problem, and say that applying `[]`, `[:]`, `?`, or `(,)` to type references always favors building a type reference over forming an array/dictionary/optional/tuple. There's also the lower-level parsing problem with generic parameter brackets that Tanner mentioned in his leading email. We stole the same trick that C# uses to disambiguate `Foo<T, U>(x)` from `(Foo < T), (U > (x))` without relying on name lookup; we assume that a type reference in an expression is always the root of a member lookup or constructor call, and that 'x > (y)' is sufficiently unlikely given the low relative precedence of >, that we can look ahead after we see a '<' to find a '>.' or '>(' token pair and favor the parse as a generic parameter list in those cases. If we're going to break the invariant that type references in expressions are always followed by a member lookup or constructor call, we'll need an alternative disambiguation scheme.
> 
> -Joe
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/6a11c40c/attachment.html>