> On May 25, 2016, at 9:31 PM, Chris Lattner via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
