<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">+1</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">Joe Groff via swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">16/05/2016 06:06 PM</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">[swift-evolution] [Pitch] Parse expressions after 'as' and 'is'instead of just types</span><br><br></div>Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd expect, but does lead to problems when an 'as' expression appears as part of a comparison:<br><br> 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y><br><br>Looking to the future, many people have also expressed interest in the ability to do dynamic type checks against metatype values, not only static types, as in:<br><br> class Base {}<br> class DerivedA {}<br> class DerivedB {}<br><br> var x: Base.Type = DerivedA<br><br> DerivedA() as? x // succeeds<br> DerivedB() as? x // fails<br> <br>If we accept https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md, dropping the '.self' requirement to refer to type objects, then I think we should also change 'is' and 'as' to parse the expression grammar on their right-hand side, leaving it up to the normal expression disambiguation rule to handle angle brackets. This solves the '20 as Int64 < x' problem, and prepares us to support dynamic is/as queries in the future. (To be clear, designing dynamic queries should be its own discussion.) What do you all think?<br><br>-Joe<br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></body></html>