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

[David Hart]

I strongly agree for the removal of .self. I remember it being a great source of confusion when I first learned Swift.

> On 10 Mar 2016, at 00:03, Tanner Nelson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> "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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Mar 9, 2016, at 2:28 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> on Wed Mar 09 2016, Brent Royal-Gordon <swift-evolution at swift.org <mailto: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 <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`.
>>>> 
>>>> 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>
> _______________________________________________
> 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/20160310/d30e6e25/attachment.html>