Allow using byref<'T,'Kind> for type inference

I propose we are allowed to use the currently internal byref<'T, 'Kind> type as synonymous to one of the normal byref types byref<'T>, inref<'T>, outref<'T>. This is primarily for use in type-directing situations, for example:

// error FS1204: This construct is for use in the FSharp.Core library and should not be used directly
let choose b (r1 : byref<_, _>) (r2 : byref<_, _>) =
  if b then &r1 else &r2

Functions in this category do not care about mutation and only serve to retrieve a pre-existing reference. This is however not possible to express neatly because the base byref type cannot be used.

This would also be beneficial to express a sort of wildcard reference:

let r : byref<_, _> = &expr

In this case, the developer expects the code to work in all situations where the address of expr can be obtained and wants to get as much capability as the obtained reference offers. The F# compiler already does most of the work, raising an error on ByRefKinds mismatch. Likewise, in functions, the compiler might be able to infer the proper kind based on the operations the function performs (reading, mutation).

The existing way of approaching this problem in F# is to duplicate the code for each of the byref, inref, outref types. I did not find a way to avoid getting the error.

Pros and Cons

The advantages of making this adjustment to F# are improving its type-inference capabilities in relation to byrefs.

The disadvantages of making this adjustment to F# are exposing an internal type for this purpose.

Extra information

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

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.

Start by reviewing the proposal's byref<'T, 'Kind> examples and the existing byref, inref, and outref behavior described in the issue. Determine how type inference and ByRefKinds mismatch checking would need to treat the internal form, then define tests covering wildcard references, type-directed functions, and incompatible kinds.