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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
If we accept swift-evolution/0090-remove-dot-self.md at master · apple/swift-evolution · GitHub, 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?
+1 -- I’ve definitely needed this before, and ended up having to escape out to Obj-C (which worked for my particular case, but maybe wouldn’t have if the type I wanted to check against was a Swift protocol?).
-tim
···
On May 16, 2016, at 2:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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:
On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
-----Original Message-----
From: "Joe Groff via swift-evolution" <swift-evolution@swift.org>
Sent: 16/05/2016 06:06 PM
To: "swift-evolution" <swift-evolution@swift.org>
Subject: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is'instead of just types
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
If we accept swift-evolution/0090-remove-dot-self.md at master · apple/swift-evolution · GitHub, 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?
+1 Seems like it could enable very powerful behaviour going forward
···
On 16 May 2016, at 23:06, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
Am 16.05.2016 um 23:06 schrieb Joe Groff via swift-evolution <swift-evolution@swift.org>:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
The dynamic check itself makes sense but it isn’t clear what type these expressions should return? It can’t be `DerivedA?` like it would in the equivalent static expression as the type is not known statically:
DerivedA() as? DerivedA // succeeds with value Optional<DerivedA>.Some
DerivedB() as? DerivedA // fails with value Optional<DerivedA>.None
···
On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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?
On Mon, May 16, 2016 at 2:07 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic
parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
on Mon May 16 2016, Joe Groff <swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
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?
Just to clarify: in your example, did you mean for DerivedA and DerivedB to
inherit from Base?
···
On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
+1
Sent from my iPhone
> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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:
>
> 20 as Int64 < y as Int64 // error, '>' expected to close generic
parameter list Int64<y>
>
> 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:
>
> class Base {}
> class DerivedA {}
> class DerivedB {}
>
> var x: Base.Type = DerivedA
>
> DerivedA() as? x // succeeds
> DerivedB() as? x // fails
>
> 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?
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Am 17. Mai 2016 um 16:25:10, David Hart via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:
+1 Seems like it could enable very powerful behaviour going forward
> On 16 May 2016, at 23:06, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
>
> 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:
>
> 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
>
> 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:
>
> class Base {}
> class DerivedA {}
> class DerivedB {}
>
> var x: Base.Type = DerivedA
>
> DerivedA() as? x // succeeds
> DerivedB() as? x // fails
>
> 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?
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Right, the static type of a cast like this would still have to be the upper bound type of the metatype value. (Unless we introduce some sort of path-dependent types to allow `x.Self` to be a type.)
-Joe
···
On May 18, 2016, at 12:54 PM, Matthew Johnson <matthew@anandabits.com> wrote:
On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
The dynamic check itself makes sense but it isn’t clear what type these expressions should return? It can’t be `DerivedA?` like it would in the equivalent static expression as the type is not known statically:
DerivedA() as? DerivedA // succeeds with value Optional<DerivedA>.Some
DerivedB() as? DerivedA // fails with value Optional<DerivedA>.None
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:
20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
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:
class Base {}
class DerivedA {}
class DerivedB {}
var x: Base.Type = DerivedA
DerivedA() as? x // succeeds
DerivedB() as? x // fails
The dynamic check itself makes sense but it isn’t clear what type these expressions should return? It can’t be `DerivedA?` like it would in the equivalent static expression as the type is not known statically:
DerivedA() as? DerivedA // succeeds with value Optional<DerivedA>.Some
DerivedB() as? DerivedA // fails with value Optional<DerivedA>.None
Right, the static type of a cast like this would still have to be the upper bound type of the metatype value. (Unless we introduce some sort of path-dependent types to allow `x.Self` to be a type.)
So `Base?` in this case? That makes sense. Thanks for clarifying.
···
On May 18, 2016, at 2:55 PM, Joe Groff <jgroff@apple.com> wrote:
On May 18, 2016, at 12:54 PM, Matthew Johnson <matthew@anandabits.com> wrote:
On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
Just to clarify: in your example, did you mean for DerivedA and DerivedB to inherit from Base?
Yeah, sorry about that.
-Joe
···
On May 16, 2016, at 5:49 PM, Dan Appel <dan.appel00@gmail.com> wrote:
On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
+1
Sent from my iPhone
> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
>
> 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:
>
> 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64<y>
>
> 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:
>
> class Base {}
> class DerivedA {}
> class DerivedB {}
>
> var x: Base.Type = DerivedA
>
> DerivedA() as? x // succeeds
> DerivedB() as? x // fails
>
> 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?
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution