F# compiler treats FSharpFunc as sealed in latest update to F# 4.1

[krauthaufen]

Hi everyone,

I know it's bad practice to inherit FSharpFunc directly in user code but in certain scenarios i had to do that.
typeof<int -> int>.IsSealed reports false obviously but the new (4.1) compiler complains about FSharpFunc<int, int> being sealed.

I understand the general idea of making all the concrete implementations sealed but why did you decide to treat the base-type as if it was sealed?

Would it be possible to make the base-type non-sealed again, since it just gives the system more flexibility. Couldn't it just be a warning of some sort? (e.g. inheriting FSharpFunc may cause your code to be broken in future versions of F#)

P.S.: the types in OptimiziedClosures (FSharpFunc<,,_>, etc.) are not sealed btw.

cheers

[vasily-kirichenko]

#3020

[krauthaufen]

Hi, I'm aware that the implementers shall be sealed but why does the compiler treat the base type itself as if it was sealed?

The point here is that FSharpFunc itself is not sealed but the compiler forbids inheriting it with "cannot inherit a sealed type"

[eiriktsarpalis]

+1 I just came across this, and it's a breaking change in cases where defining stable closure names is a requirement, e.g. https://github.com/mbraceproject/MBrace.Core/blob/f7a2b8bc13ddd0f59928b82054f05a7be52e3755/src/MBrace.Core/Continuation/Builders.fs#L91

[dsyme]

@eiriktsarpalis I see this comment in your code

    // F# won't let use inherit OptimizedClosures.FSharpFunc<_,_,_> because of the unit return type
    inherit FSharpFunc<ExecutionContext, Continuation<'T> -> unit> ()

Is there a way to use a non-unit return type here? e.g. can you use a type parameter which you then instantiate to unit?

[eiriktsarpalis]

@dsyme I think we'd have to use an async style FakeUnit return type for the continuations.

[dsyme]

Hmm so #3031 (which implemented #3020) is not the change responsible here, since that is about making the closures that implement FSharpFunc sealed.

The change happened after F# 4.1 RTM. I think the change responsible is #3283, which decodes FSharpFunc to the compiler's view on function types. There is an explicit opt-out when compiling FSharp.Core here https://github.com/Microsoft/visualfsharp/pull/3283/files#diff-5b9ab9dd9d7133aaf23add1048742031R4893.

@cartermp This is the second break because of that change - sorry - mea culpa, the other is #3729

[cartermp]

Just as a note, we're likely past the window of getting this into a compiler update for 15.5, but for a 15.6 update we could conceivably take this. No timeline is in place for either release at the moment, but 15.5 will be sooner since we're now in Escrow.