Allow defining covariant/contravariant type parameters for use in other .NET languages

[IS4Code]

I propose we have a way to produce (i.e. not necessarily consume from within F#) type parameters that are covariant/contravariant, per .NET's rules (allowed only in input/output positions, respectively).

Custom attributes could be used for this purpose, such as:

type IEnumerable<[<Out>] 'T> =
  abstract member GetEnumerator : unit -> IEnumerator<'T>
and IEnumerator<[<Out>] 'T> =
  abstract member Current : 'T with get

I chose to abuse InAttribute and OutAttribute for this purpose here, since .NET disallows them on type parameters (F# would have to treat them as allowed) and they look similar to C#'s syntax and thus are broadly understandable. Of course different attributes could be used for this purpose too.

The existing way of approaching this problem in F# is none; maybe via (unsafe) IL rewriting to add the necessary flags.

Pros and Cons

The advantages of making this adjustment to F# are parity with other .NET languages in terms of quality of type hierarchies, improving interoperability with such languages.

The disadvantages of making this adjustment to F# are having a feature that cannot be used from within F# itself (in company with CLIMutable etc.)

Extra information

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

Related suggestions: #162

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• 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
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

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

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[T-Gro]

Could you please also add a motivating real-world example?
Also in contrast with using mixed solutions, e.g. a C# wrapper.

A major disadvantage for an attribute that does nothing on the first glance (at least within the F# project itself) is user confusion.
One could possibly clear that by placing 2 new attributes into an obviously-csharp-interop namespace.

[IS4Code]

Certainly – I am making a generalized coroutine computation for use in other libraries, using an interface at its core:

[<Interface>]
type ICoroutine<'TInput, 'TElement, 'TResult> =
  abstract member Exception : Exception with get
  abstract member Current : 'TElement with get
  abstract member Result : 'TResult with get
  abstract member Resume : input : 'TInput * context : CoroutineContext -> unit

(yes this should expose a union of the state and there is a subinterface that does; this is just for convenience using it from .NET)

Now this would be a great candidate for <in TInput, out TElement, out TResult>, and I was thinking about defining that in a C# project and referencing that with staticlink, except that the CoroutineContext is an F# record with internal contents, so I'd also need to have another F# project to be referenced from C#, with InternalsVisibleTo... a lot of hassle that would be simplified if able to do this from F# alone.

There may even be situations where not even this solution is possible, say if there is a method on the interface taking an F# function, anonymous record, optional parameter, has generic constraints that cannot be expressed in C#, etc.

Also I would like to offer an alternative view: this is not necessarily "just for C# interop" – co-/contravariance is a .NET concept and the runtime will also be affected by it. This means the effect of such attribute will be perceivable from F# alone, just through a round of box/unbox and not directly by the type system (yet?). If people are okay with it, they will be able to utilize it that way.

When #255 becomes possible, you would even be able to define a simple type-safe function that hides this conversion:

module Coroutine =
  let widen (c : ICoroutine<'TBaseInput, 'TDerivedElement, 'TDerivedResult>) : ICoroutine<'TDerivedInput, 'TBaseElement, 'TBaseResult> when 'TDerivedInput :> 'TBaseInput and 'TDerivedElement :> 'TBaseElement and 'TDerivedResult :> 'TBaseResult and 'TDerivedInput : not struct and 'TDerivedElement : not struct and 'TDerivedResult : not struct
    = downcast (box c)

  let narrow (c : ICoroutine<'TDerivedInput, 'TBaseElement, 'TBaseResult>) : ICoroutine<'TBaseInput, 'TDerivedElement, 'TDerivedResult> when 'TDerivedInput :> 'TBaseInput and 'TDerivedElement :> 'TBaseElement and 'TDerivedResult :> 'TBaseResult and 'TDerivedInput : not struct and 'TDerivedElement : not struct and 'TDerivedResult : not struct
    = downcast (box c)

That makes it worth it in my opinion, since otherwise one would need to create proxy objects for casting the arguments/results and incur overhead.

[T-Gro]

Understood, thanks.

Re:syntax: I get that it might be tempting to reuse an existing attribute, but since it would need to hack around AttributeTargets validation anyway, I would rather prefer using an attribute which is specifically meant for AttributeTargets.GenericParameter target.

[IS4Code]

Aye, that makes sense too. Could be something like RuntimeCovariantAttribute and RuntimeContravariantAttribute then.