Lift byref generics restrictions for inline functions

[NinoFloris]

I propose to lift byref generics restrictions for inline functions.

Since all the new byref things have landed in 4.5 I've been playing quite a bit with Span. It's awesome it all works so well already and correctly prevents you from going off the rails.
It is definitely restrictive and it complicates generic programming a lot. It might especially shock people where they normally don't realize this applies, like piping |> or functions like id. The reason for this is purely a limitation of the CLR and its implementation of generics, it cannot accept a byref type argument, however F# could.

F# already has ways to deal with other generics limitations by marking functions as inline. This effectively removes this function from the runtime's view which allows the language to relax restrictions around generic constraints or limitations.

For instance lifting restrictions on byref for generic functions should allow the following contrived example to pass compilation:

Span<int>.Empty |> id

Both |> and id are generic, but both are also already marked inline today.

Making this change is neatly in line ;) with previous choices for inline to lift generics limitations and it greatly increases ergonomics working with byreflike types and byref arguments.

@TIHan has also quickly checked the feasibility of this and found a place to implement this inside PostInferenceChecks.fs where it can be, in theory, implemented in a way to guarantee correctness.

Pros and Cons

The advantages of making this adjustment to F# are increased language ergonomics and consistency as not being able to use byref in generics is purely a CLR restriction. This is opens up a lot of possibilities to add some sugar on interactions with Span and friends. And it might also help in performance scenarios where passing structs byref is preferred but where generic code is important too or used a lot. In the face of F# dissuading people from doing method overloading it is a good option to have.

The disadvantages of making this adjustment to F# are extra complexity in the compiler. A function marked as inline should, for byref call sites, not contain any calls to other generic functions that aren't marked inline as well.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S (or 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

[cartermp]

The advantages of making this adjustment to F# are increased language ergonomics and consistency as not being able to use byref in generics is purely a CLR restriction.

Agreed on this. It's so commonplace to pipe data into another function that it's a guaranteed surprise to first-time users of Span and other byref-like types that they cannot use |>.

Another thing worth calling out is that an error message when applying a byref-like type to a generic function that isn't inline needs to have a descriptive error message (tracked by dotnet/fsharp#5351). Otherwise, people will definitely be confused about why some functions "work" and others don't.

[dsyme]

I think this is basically reasonable though it's very tricky to implement the appropriate checks.

• Currently all byref checks are done in PostInferenceChecks, that last phase of errors reported in the IDE.

• The F# compiler does not run inlining before implementing PostInferenceChecks - inlining is implemented in the later Optimizer phase.

• Running the Optimizer in the IDE is not feasible for performance reasons

• Implementing inlining and reduction in the PostInferenceChecks is not feasible for complexity reasons

• It's very hard to come up with a spec of allowable functions that doesn't really amount to implementing both inlining and reduction.

[abelbraaksma]

@dsyme, wouldn't most of the tricky bits of implementing this be solved if we were to introduce a new (internal to the compiler only) feature to rewrite the expression tree in the parsing phase? For instance, only for productions that have been tagged (with an attribute perhaps) to be rewritable?

In the case of |>, this would mean that if, and only if, it is used as an operator (as opposed to usage as a function with (|>)), and the production rules match the signature, then the production is rewritten as a function call on the rh operand instead and the pipe operator disappears.

This would change the resulting opcodes, and obviously the intermediate AST, but since currently that already happens at the end during the inlining phase, I doubt this causes many issues in practice.

This will also fix the issue that piping breaks tail recursion.

If this is feasible, we might find other operators that can be optimized this way (like ||> or >>).

It might change the debugging experience, but since inlining already makes it nearly impossible to debug |>, we might as well live with it.

Rewriting the AST would not take place when the operator is redefined by the user.

[dsyme]

@abelbraaksma That kind of rewrite is more or less how the current F# compiler optimization phases work.

You can definitely make another dedicated lowering phase work, but it becomes very hard to control/test/document/explain/answer-questions -on-stackoverflow about the exact subset of constructs supported, people end up relying on corner cases that were never intended to work, and keep asking for more things to be supported ("can we inline Array.map into flattened code" etc.)

[7sharp9]

You can see some of the details of rewriting quotations in a similar manner in ProvidedTypes.fs : https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/src/ProvidedTypes.fs#L8575-L8590 etc

…

On Thu, 7 Nov 2019 at 13:07, Don (coding) ***@***.***> wrote: @abelbraaksma <https://github.com/abelbraaksma> That kind of rewrite is more or less how the current F# compiler optimization phases work. You can definitely make another dedicated lowering phase work, but it becomes very hard to control/test/document/explain/answer-questions -on-stackoverflow about the exact subset of constructs supported, people end up relying on corner cases that were never intended to work, and keep asking for more things to be supported ("can we inline Array.map into flattened code" etc.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#688?email_source=notifications&email_token=AAEPXSS4H4ERCNZMSPTMC4DQSQHKPA5CNFSM4FSOULA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMK6FQ#issuecomment-551071510>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEPXSRIC2QH3675V26USV3QSQHKPANCNFSM4FSOULAQ> .

[TIHan]

I've thought about this for a while. I think we should refrain from allowing byref type arguments for inline functions because it introduces more complexity to the language that a user has to learn about.

When calling functions today, we don't really care if it is inline or not; we just call it. If we allowed this feature, you now have special semantics at the call site for the function in regards to it being marked as inline. Now, we do have SRTP which require inline functions, but the user calling the function is expected to understand the constraints rather than understanding that the function is inline.

I do agree that using |> would be useful for Span. However, there are only a limited amount of use cases for Span to the point where you should not be constantly using it.