Stop requiring bit shift operators to take int32 on the right hand side

[Happypig375]

I propose we allow:

type G() = static member (<<<) (x:G, y) = x
let a = G() <<< 1L
// error FS0001: This expression was expected to have type 'int32' but here has type 'int64'

The existing way of approaching this problem in F# is

type G() = static member (<<<) (x:G, y) = x
let a = G.(<<<) (G(), 1L)

This is probably a decision made in F# 1.0. However, there is a proposal champion from the C# side currently in the C# team's Working Set:
[Proposal]: Relaxing shift operator requirements

Motivation

When working with types other than int, it is not uncommon that you shift using the result of another computation, such as shifting based on the leading zero count. The natural type of something like a leading zero count is the same as the input type (TSelf) and so in many cases, this requires you to convert that result to int before shifting, even if that result is already within range.

Within the context of the generic math interfaces the libraries are planning to expose, this is potentially problematic as the type is not well known and so the conversion to int may not be possible or even well-defined.

To enable consumption from F#, we must enable this, otherwise we will be incompatible with this change once implemented.

Pros and Cons

The advantages of making this adjustment to F# are

1. Interoperability
2. Convenience for custom operator definitions
3. Effective utilisation of the .NET BCL once this change propagates through it

The disadvantages of making this adjustment to F# are

Drawbacks

Users will be able to define operators that do not follow the recommended guidelines, such as implementing cout << "string" in C#.

Also existing type inference will be more confusing with this change.

Extra information

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

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this 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
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• 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:

• 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.

[charlesroddie]

Are there .Net methods corresponding to these things? If there are then this become a single documentation issue in dotnet about how to find them rather than a language request in F#.

[Happypig375]

@charlesroddie The C# team is looking to relax this requirement.

[charlesroddie]

Presumbly the C# language feature depends on dotnet methods. If those are usable then we can just preserve the status quo in F# and if you need anything else you can use the dotnet methods.

[Happypig375]

So force op_LeftShift and op_RightShift in these cases?

[dsyme]

I looked over this and don't really see cases where we need to shifting to be non-integer. It just seems like a very small win?