Upcast branches of match and if expressions when type is specified

[charlesroddie]

F# should upcast return values of if and match expressions where the required type is known. For example the following expressions should compile:

type View() = class end
type Label() = inherit View()
let f b :View =
    if b
    then View()
    else Label() // FS0001 "All branches of an 'if' expression must return values of the same type as the first branch..."
let g b :View =
    match b with
    | true -> View()
    | false -> Label() // FS0001 "All branches of a pattern match expression must..."
let h b :View =
    match b with
    | true -> Label() // FS0001 "This expression was expected to have type View..."
    | false -> View()

Currently up-casting (where the intended type is specified or known) happens automatically in lists (let l:View list = [ Label() ]) and in function inputs. This doesn't happen in if and match constructs. There may be other constructs where this also doesn't happen, which should be added to this suggestion.

Pros and Cons

The advantages of making this adjustment to F# are: less manual upcasting

The disadvantages of making this adjustment to F# are: none

Extra information

Estimated cost (XS, S, M, L, XL, XXL): M

Related suggestions: There are suggestions also to do with upcasting which are more complex: #3, #536 .

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• [ x ] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [ x ] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [ x ] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• [ x ] This is not a breaking change to the F# language design
• [ x ] I or my company would be willing to help implement and/or test this

[alexandrehtrb]

Currently, in ASP.NET controllers using F#, manual upcasting is required:

[<HttpGet("{id}")>]
member this.Get(id: int): IActionResult =
    let x = this.Repository.Get(id)
    match x with 
    | null -> this.NotFound() :> IActionResult
    | _ -> this.Ok(x) :> IActionResult

It would be good to have automatic upcasting when type is specified.

[auduchinok]

Not an ideal suggestion but you can simplify it a bit using inferred types:

member this.Get(id: int): IActionResult =
    match this.Repository.Get(id) with 
    | null -> this.NotFound() :> _
    | _ -> this.Ok(x) :> _

[cartermp]

I can definitely see this being controversial, since adding anything about making it easier to work with inheritance hierarchies always draws some allergic reactions. I'm generally in favor of something like this since it makes working with unavoidable and common APIs a bit easier.

[isaacabraham]

I would feel uncomfortable about this feature, or at least there would need to be some explicit guidance needed. Check out this old blog post from Lincoln Atkinson (ex F# compiler team) https://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/ looking at the very first sample. I definitely don't want that in F# with the compiler trying to be helpful but picking some arbitrary common type.

[cartermp]

In this case it’s not quite analogous; in Scala the compiler walks up the subtype tree and “magically” finds an ancestor that works. The proposal here is about when the type is already known, not about inferring up the tree. Though this could arguably be a step down the path of more inheritance-oriented programming, which goes against general F# principles/dogma

…

On Sat, Oct 5, 2019, at 14:05, Isaac Abraham wrote: I would feel uncomfortable about this feature, or at least there would need to be some explicit guidance needed. Check out this old blog post from Lincoln Atkinson (ex F# compiler team) https://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/ looking at the very first sample. I definitely don't want that in F# with the compiler trying to be helpful but picking some arbitrary common type. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#792?email_source=notifications&email_token=ABQEJTTSGFR7VAOLR3KSSVTQND6S5A5CNFSM4I4W3ETKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAN3YCI#issuecomment-538688521>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQEJTTZQPX2JUDTORI7SBLQND6S5ANCNFSM4I4W3ETA>.

[heronbpv]

Wouldn't it be kind of a special case of a flexible type, but in the return definition instead of the parameter one? Maybe we could use that to properly signal that we want the return type to be exactly this one.

Wonder how much we could reuse of the current flexible type implementation for this, if any.

F# docs reference: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/flexible-types

[isaacabraham]

@cartermp as long as the behaviour would be predictable, understandable and easy to reason about I'd probably be interested in this eg if there was a type hint to explicitly tell the compiler what the expected type was.

[isaacabraham]

In fact I remember when writing GPWF having to explain this exact scenario. So perhaps doing this in a specific scope has some value after all 😊

[charlesroddie]

This suggestion would just extend current list behaviour to if and match:

let l1 = [View(); Label()] // Not OK
let l2:View list = [View(); Label()] // OK
let f(_:View list) = ()
f [View(); Label()] // OK

A more complete solution would be to upcast whenever the required type is known:

let l3:View list = [Label(); Label()] // OK
let v1:View = if true then Label() else Label() // This suggestion would make this OK
let v2:View = Label() // Not OK. Should it be OK?

[isaacabraham]

@charlesroddie mmm good question. The latter would I assume be logical to permit if the first two are legal, yet that's nothing that's been allowed this far.

[dsyme]

This has been completed as part of RFC FS-1093 https://github.com/fsharp/fslang-design/blob/main/preview/FS-1093-additional-conversions.md, currently in preview and scheduled for F# 6.0