[Pitch] Parse expressions after 'as' and 'is' instead of just types


(Joe Groff) #1

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


(Timothy Wood) #2

+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:


(David Sweeris) #3

+1

- Dave Sweeris

···

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


(Matthew Johnson) #4

+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


(Leonardo Pessoa) #5

+1

···

-----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 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


(David Hart) #6

+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


(Thorsten Seitz) #7

+1

-Thorsten

···

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?

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #8

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?

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #9

+1

···

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?

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #10

+1

···

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?

--
-Dave


(Dan Appel) #11

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dan Appel


(Adrian Zubarev) #12

+1 Missed this one for a long time :slight_smile:

···

--
Adrian Zubarev

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #13

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


(Matthew Johnson) #14

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:

-Joe


(Joe Groff) #15

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dan Appel