Allow usage of [<TailCall>] with older FSharp.Core package versions

[dawedawe]

Description

This allows users to use the [<TailCall>] analysis with older versions of FSharp.Core. They just need to define the attribute in Microsoft.FSharp.Core themselves.

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated

[vzarytovskii]

Just a note - while it's a valid scenario, we highly discourage people from using custom FSharp.Core.

[smoothdeveloper]

What I like here is, like in C# which has those attributes, they can be added as internal in older projects that don't reference the recent SDK, and the compiler just look at those the same as if they were baked in the SDK. (for C#, I'd prefer record and nullable support to be shipped to .net framework consumers though...).

I don't think it is about "custom version of FSharp.Core" but just playing nice with consumers that can't easily (or just haven't done the) upgrade to latest one, if this comes at a very minor cost.

Taking the opposite approach to extreme (not saying this is what is done, F# is overall better than wider .net on this front, IME), even if it is "2 years were given", I see it a bit the same as "python 2 to 3", but this is so long it is very minor cost in the compiler impl.

If something is possible for string interpolation with FSharp.Core < 5, it may be worth a look, and to keep in mind for other attributes used by the compiler.

[vzarytovskii]

What I like here is, like in C# which has those attributes, they can be added as internal in older projects that don't reference the recent SDK, and the compiler just look at those the same as if they were baked in the SDK. (for C#, I'd prefer record and nullable support to be shipped to .net framework consumers though...).

We do the same for implicit attributes. Can't do with explicit ones.

I don't think it is about "custom version of FSharp.Core" but just playing nice with consumers that can't easily (or just haven't done the) upgrade to latest one, if this comes at a very minor cost.

The only situation where it's needed is when newer compiler is using older fslib. And the only way of doing is to upgrade sdk but specifically pin core lib to old one. And that's generally discouraged.

[smoothdeveloper]

The only situation where it's needed is when newer compiler is using older fslib. And the only way of doing is to upgrade sdk but specifically pin core lib to old one. And that's generally discouraged.

I may misunderstand, but I think the encouraged thing is:

• library pin to lower FSharp.Core, per what they need (not forcing consumers to update due to a dependency)
• applications / leaf projects that are close to make runtime decision have the latitude to pick any FSharp.Core version, so long the compiler supports it

We encourage to support old for "inner / dependencies", or new for "close to runtime".

In this context, one library may decide to remain on lower FSharp.Core but define couple of internal attributes for their own consumption of features of recent F# compiler; it would generally not affect consumers of the library that may still use FSharp.Core that doesn't or does have those attributes.

[psfinaki]

Hmm I am also not a fan of the string comparison but since I don't have a better idea and this seems to be quite an isolated piece of functionality (and also edge-cased for the older F# core), I am fine with letting this in.