Some code does not compile anymore, but used to compile just fine. See repro:
Given this code from this original post on StackOverflow, which shows a possible way to emulate semi-polyvariadic functions in F#:
```f#
type T = T with
static member inline ($) (T, r:'t->'t ) = fun a b -> a + b
static member inline ($) (T, r:'t->'t->'t ) = fun a b c -> a + b + c
static member inline ($) (T, r:'t->'t->'t->'t) = fun a b c d -> a + b + c + d
let inline sum (x:'a) :'r = (T $ Unchecked.defaultof<'r>) x
// following lines cause error FS0003: This value is not a function and cannot be applied.
let x:int = sum 2 3
let y:int = sum 2 3 4
let z:int = sum 2 3 4 5
let d:decimal = sum 2M 3M 4M
```
Code that was valid and used to compile should remain compilable in future versions of F# (barring changes to the library that may shadow functions, or known backwards incompatibilities).
It doesnt' compile anymore. It compiles fine in VS2015 with F# (just paste in REPL), but not in VS2017. I don't know exactly from what version of VS it stopped working.
No idea, in the mentioned post another approach to polyvariadic functions is given that compiles fine (and compiled fine, but didn't run in debug builds, but this was fixed, see #865), which could be used in an alternative, but is more limited in terms of argument types.
Seen working in VS2015, stopped working in VS2017. Tested up until VS 2017 15.8 Preview 2, only tested on Windows versions of VS.
I don't see anything terribly "on the edge" in the code above, unless I am missing it, but essentially these are just overrides and I think this code is sound and should compile just fine.
I am not aware of an incompatibility that was introduced in the VS 2017 F# compiler that was "by design", but please close this with due comment if I've missed it ;).
Several small changes were made to SRTP resolution during F# 4.x and to be honest we reverted most of them because they introduced slight changes in resolution. The ones that are not reverted I don't propose to change any further and will treat as a bug fix/by-design.
I believe this particular one is related to a bug fix around how implicit operators like $ in the example are resolved, a change was made to order of resolution. Although this code compiled in VS2015, we won't be making any further changes/fixes specifically to get F# 4.0 code to compile, as it would likely cause further problems.
So I'll resolve this as "by design" and we can add the case as a test so we know when/where we are changing behaviour more precisely.
@abelbraaksma I've adjusted the title to reflect that this is now an issue where we need to record the test case
This was due to the PR I tried to revert here but unfortunately it was decided to re-revert it.
The only known "good" effect of that PR was in an old implementation of Taskbuilder.fs which of course only worked in F# 4.1 but bad effects like this one I find regularly.
The test I added in that PR is very similar to the one you reported.
Bringing this one back to the top of peoples' inboxes. I think the current behavior we've decided to live with is not ideal, and the only real reason we didn't change back was because we had no mechanism to control when this fix could be rolled out to users while also getting meaningful usage in a preview. Now that we have LangVersion, we can fix this and put it behind a feature flag that only lights up with preview. We can then work with folks like @abelbraaksma to try it out and determine if we need to keep it behind preview or if we can light it up in a future update.
Most helpful comment
Bringing this one back to the top of peoples' inboxes. I think the current behavior we've decided to live with is not ideal, and the only real reason we didn't change back was because we had no mechanism to control when this fix could be rolled out to users while also getting meaningful usage in a preview. Now that we have LangVersion, we can fix this and put it behind a feature flag that only lights up with preview. We can then work with folks like @abelbraaksma to try it out and determine if we need to keep it behind preview or if we can light it up in a future update.