Compile errors when using FSharp.Core 3.x in latest version

[ReedCopsey]

Description

The newest PR includes functionality not available in older F# versions.

Repro steps

Try to compile using F# 3.0.

Related information

The culprits are:

Option.ofObj should be replaced with the internal nullToOption utility (already existing). Example of this is https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/src/ProvidedTypes.fs#L6807 Occurs 4 times in ProvidedTypes.fs

Slicing operations on lists here fail: https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/src/ProvidedTypes.fs#L7925-L7926 These need to be rewritten to use some other mechanism.

[dsyme]

@ReedCopsey I think we might just assume FSharp.Core 4.0 from here on. Is there any specific reason to continue to assume FSharp.Core 3.x?

[ReedCopsey]

I thought the guidance was always to try to build libraries for the broadest audience. I'm fine upgrading to F# 4 for this (good for my personal use), but I know I had a complaint when I went from 3.0 to 3.1, so there are users still using old F# versions. I'm okay telling them they have to use old versions, if you want to make type providers effectively F# 4+ only, though.

[dsyme]

@ReedCopsey The question is really whether users of F# 3.x will be happy using existing versions, so only users of F# 4.x get new features

[dsyme]

@ReedCopsey Yes, you're right about guidance BTW

[ReedCopsey]

@dsyme The users will definitely complain - I'm okay with that, if this is "the way" moving forward, but I do think that the guidance would need changing if we want to put this restriction in place, since it'll basically make "new type providers" F# 4+ only.

In the case of FsXaml, using F# 4 doesn't add any value for that library - so I've been fine leaving it in old versions. All of my other libs are going to force upgrade people to netstandard 2 once VS supports it better (there are technical advantages to be had there), so I'm already planning to go through this conversation elsewhere. This is just one place where it isn't necessary from a technical POV, as far as I can tell, so I was going to try to keep it 3.x.

[dsyme]

I put it under test for FSharp.Core 3.1.0.0 in https://github.com/fsprojects/FSharp.TypeProviders.SDK/pull/158

I do think we're at a point in time where library authors are strongly rev'ing towards .NET Standard 2.0, so F# 4.1 compiler and FSharp.Core 4.1.xx will be cycled in as the assumed minimal basis for all fresh library work much more quickly than may normally be the case

[dsyme]

Note that the TPSDK already assumes .NET SDK 2.0-style project files - you can use it without via source code inclusion, but people cloning the library will be by default assuming to F# 4.1/FSharp.Core 4.1.0.0/.NET SDK 2.0

[ReedCopsey]

@dsyme I think the most common way to use this library seems to be using paket to pull in source, from what I've seen, so the project file type doesn't really matter here.

As I said, I'm perfectly fine with making F# 4 (or even 4.1) the baseline - I just think we should consider updating guidance if we want to make the "official" TP authoring package 4.x only.

I also agree that, once VS supports it well, NS2 will become common enough most libraries will move that direction (I'm planning to do that with the majority of mine). I was mainly pointing out why I've been keeping this library F# 3, which is due to the current guidance (and one user that I know of targeting F# 3).