Make the type-casting operator accept expressions on its right side

Hello everyone. This is my first contribution to Swift Evolution. In summary: It would be nice if the type casting operator accepted expressions on its right side.

So, basically, the type casting operator only accepts types and can't process expressions on its right side.

Having a class A, and a subclass of A, B:

class A {}
class B: A {}

And a function that returns the passed type:

func type<T: A>(t: T.Type) -> T.Type {
   return t
}

The following scenario works:

let b = B()
let a = (b as A)

However the following scenario doesn't:

let b = B()
let a = (b as type(A))

Having the “as” accept expressions on its right side would be really useful and could enable some truly great generic algorithm implementations.

Looking forward to what you guys think about this.

— Oscar Swanros | @swanros

+1 for the functionality, but I think it's part of the larger issue of "functions which can be evaluated at compile-time", which, IIRC, is presently considered out of scope (can't recall if that's just for phase 1 or Swift 4 altogether). I might be wrong, though. I'm sure someone who knows more than I do will be along shortly with a better answer.

- Dave Sweeris

···

On Jan 12, 2017, at 16:50, Oscar Swanros via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone. This is my first contribution to Swift Evolution. In summary: It would be nice if the type casting operator accepted expressions on its right side.

So, basically, the type casting operator only accepts types and can't process expressions on its right side.

Having a class A, and a subclass of A, B:

class A {}
class B: A {}

And a function that returns the passed type:

func type<T: A>(t: T.Type) -> T.Type {
    return t
}

The following scenario works:

let b = B()
let a = (b as A)

However the following scenario doesn't:

let b = B()
let a = (b as type(A))

Having the “as” accept expressions on its right side would be really useful and could enable some truly great generic algorithm implementations.

This makes a lot of sense to support. We previously had problems that the type grammar wasn't quite a subset of the expression grammar, which prevented us from doing this before, but most of those issues have been shaken out. The last bit of weirdness is the `.self` turd that still structurally supports some of the type/expr grammar ambiguities. We have a plan to address this (SE-0090: https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md\); that's been deferred since we don't think we can execute on it well with our current infrastructure, but that should improve with time. Once that's done, it would be naturally for the cast operators to accept an expression on their right side for dynamic type casts.

-Joe

···

On Jan 12, 2017, at 2:50 PM, Oscar Swanros via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone. This is my first contribution to Swift Evolution. In summary: It would be nice if the type casting operator accepted expressions on its right side.

So, basically, the type casting operator only accepts types and can't process expressions on its right side.

Having a class A, and a subclass of A, B:

class A {}
class B: A {}

And a function that returns the passed type:

func type<T: A>(t: T.Type) -> T.Type {
    return t
}

The following scenario works:

let b = B()
let a = (b as A)

However the following scenario doesn't:

let b = B()
let a = (b as type(A))

Having the “as” accept expressions on its right side would be really useful and could enable some truly great generic algorithm implementations.