Back to Questions
1.5k
views4
comments
Dynamic Type Test Operator
f#

Hi,
Dynamic type test operator is definitly the subject of great surprise for me. .

let printType(_ : 'T) =
printfn "Type:%s" typeof<'T>.FullName

type A = interface end // base interface
type A2 = inherit A //derived interface
type B() = class interface A end // class that implements interface

let a2 = {new A2}
let b = B()

printType a2 // Type:Program+A2
printType b // Type:Program+B

printfn "%O" (a2 :? A) // (1) compiles but gives a warning (prints True)
printfn "%O" (b :? A) // (2) doesn't compile 'Type constraint mismatch. The type A is not compatible with type B The type 'A' is not compatible with the type 'B''

// next statements are compiled without any issues and print True twice
printfn "%O" (box a2 :? A)
printfn "%O" (box b :? A)

According to the spec "6.8.3 Dynamic Type Test Expressions"
An expression of the form expr :? ty is a dynamic type test expression. Here ty must be an atomic type,
formed
For example:
((1 :> obj) :? int)
((1 :> obj) :? string)
The initial type of the overall expression is bool. Expression expr is checked using a fresh initial type tye. After checking,

  1. The type tye must not be a variable type.
  2. A warning is given if tye coerces to ty
  3. The type tye must not be sealed

  4. If type ty is sealed, or ty is a variable type, or type tye is not an

    interface type then ty :> tye is
    asserted

and "5.4.7 Subtyping and Coercion"
A static type ty2 coerces to static type ty1 (with respect to a set of current inference constraints X), written ty2 :> ty1, if ty1 is in the transitive closure of the base types and interface types of ty2.
So I expect the behaviour in cases (1) and (2) should be the same: issuing the warning. But it isn't...
Can you please clarify why?
---
Best regards,
Vladimir Matveev

.

It appears that it must always be a 'downcast' attempt, e.g.

1
2
3
4
5
6
7
8
9

 

// Canvas is-a FrameworkElement
let canvas : System.Windows.Controls.Canvas = null
let elem : System.Windows.FrameworkElement = null
let x1 = (canvas :? System.Windows.FrameworkElement) // does not compile
let x2 = (elem :? System.Windows.Controls.Canvas) // compiles
let x3 = (elem :? System.Windows.FrameworkElement) // compiles with warning

seems like it always is asserting "ty :> tye". Oh, that's supposed to happen due to bullet (4.) in the spec you called out. What's the issue (other than the diagnostic being poor/confusing)? Basically the behavior I see is that you can type-test an attempted downcast (or no-cast to own-type, with warning), but you cannot type-test an upcast (which would always succeed).

By on 5/2/2010 11:29 AM ()

seems like it always is asserting "ty :> tye". Oh, that's supposed to happen due to bullet (4.) in the spec you called out. What's the issue (other than the diagnostic being poor/confusing)? Basically the behavior I see is that you can type-test an attempted downcast (or no-cast to own-type, with warning), but you cannot type-test an upcast (which would always succeed).

If it always succeed then why this is reported via error message (quite confusing)?
I'll try to clarify my point of view: according to spec's definition of coerce, behavior with own-type and with derived types should be the same (warning). Now it behavior of compiler dissent with specification: compile-time error in case of derived type.

By on 5/5/2010 8:45 AM ()

Thanks; I filed a bug about the confusing error diagnostic and the spec issue.

By on 5/5/2010 9:47 AM ()

I assumed that second point with 'coercion' should work not only in case of own type but also with derived types. According to definition of 'coerce' from spec type B should coerce to type A
type A = interface end
type B() = class interface A end
because A is contained in transitive closure of base types and interfaces of B.

so this case should fall into point 2 (with warning...)

By on 5/2/2010 11:58 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper