[swift-evolution] [Deferred] SE-0090: Remove .self and freely allow type references in expressions

[Joe Groff]

> On May 25, 2016, at 9:31 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md
> 
> The review of "SE-0090: Remove .self and freely allow type references in expressions" ran from May 17…23, 2016. The proposal has been *deferred* from Swift 3.
> 
> The community and core team all want this proposal (or something like it) to succeed, but the core team identified several serious implementation concerns with the proposal:
> 
> - Disambiguating type vs expression cannot be done in cases where there is no contextual type available or when that type is “Any”.  For example, in the case of "let x = [Int]” it isn’t clear whether this is an array value that contains the metatype for Int, or whether it is a metatype value for the type “[Int]”.  Similar problems exist with tuple literals, including the degenerate case of “let x = ()” which can either be the type of the empty tuple type or an empty tuple value.
> - As written, the proposal has a defaulting rule that fall back to the container literal when a type literal cannot be formed.  The core team prefers that the compiler treat truly ambiguous cases (where a subexpression could be considered to be either a type or a value) to be ambiguous.
> - Resolving ambiguous cases requires some syntax to disambiguate between the cases, which we don’t have.  This syntax should be part of the proposal.
> - Having the constraint solver determine whether a subexpression is in a type or expression context is conceptually beautiful, but it introduces significant complexity into the type checker and puts more pressure onto the constraint solver.  The core team would prefer to see the already planned optimizations and simplifications go into the constraint solver before this happens.  This would allow us to more accurately gauge the cost of this design in practice.
> - The goal of removing the “Int.self” syntax is a great one, but can be done at any point (beyond Swift 3) at little cost: the goal is to obsolete the T.self syntax, not to repurpose it to mean something else.  This means that we can continue to accept it as deprecated syntax for a very long time with little cost to the community.
> 
> The core team would definitely like to circle back to this proposal after Swift 3 is out the door, but would recommend that such a proposal be accompanied with a prototype implementation, to validation that the chosen approach can work in practice.
> 
> Thank you to Joe Groff and Tanner Nelson for this proposal!

Thanks for the discussion. For the next time we pick this up, I've revised SE-0090 in response to the above feedback:

https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

-Joe