Discussion: FSharp.Core breaking/incompatible changes
#16231
Replies: 21 comments 53 replies
-
|
A few thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
For the runtime breaking scenarios, I think the "project template" solution might be a solution. |
Beta Was this translation helpful? Give feedback.
-
How would it be distributed? We don't really want a new NuGet, or more "special" assemblies/projects at this point, it might become a maintenance nightmare very soon (since Idea of "layered" core library is a good one, but probably a bit orthogonal to this one (thought related to it).
This might work, however, we should keep in mind that it will require bringing in some msbuild magic to when we invoke compiler, to let it know which libraries/modules/namespaces to autoload. Logic of "default" behaviour will be spread thin between project file, compiler and core library (parts). This will also become very polluted very soon, if we will chose this approach.
It's also good to keep in mind that it's not how it currently works. Right now, one opts-in implicitly into new language features every time SDK is updated for the project (i.e. we always use |
Beta Was this translation helpful? Give feedback.
-
|
I think for so-called "hypothetical" breaking changes this seems to a reasonable way forward. It just needs to be very well documented and clear in the release notes for the language / FSharp.Core release version. |
Beta Was this translation helpful? Give feedback.
-
|
Problem is nobody reads those, and if they do, it shows that people don't pay enough attention. |
Beta Was this translation helpful? Give feedback.
-
|
Understanding how release notes interacts with your own code base can be hard. I might read it and think Could still be the reasonable way forward. F# is rather small language and has a pretty up to date community so could still be worth it in a risk/reward scenario. |
Beta Was this translation helpful? Give feedback.
-
|
Can an Intellisense refactor save us? |
Beta Was this translation helpful? Give feedback.
-
You mean like showing potential braking changes to people? It sure can, but I am not certain how to make them predictably detectable. |
Beta Was this translation helpful? Give feedback.
-
|
Ah - that makes sense. I echoed Mark Seeman's missive about linters earlier today and I kinda felt sheepish about making this suggestion as a cheap way out. |
Beta Was this translation helpful? Give feedback.
-
|
Just 2 cents, please always keep an eye on Fable compatibility. |
Beta Was this translation helpful? Give feedback.
-
|
That was a point in recent discussion I had as well. Doesn't Fable have its own core library? Or do they have FSharp.Core fork and use it as a source? I'd imagine they'll need to have a per-language mapping from I imagine if we choose to do shadowing, no "binary" breaking changes will take place. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, Fable reimplements the core library for all languages. Any breaking change should eventually be a breaking change in Fable as well |
Beta Was this translation helpful? Give feedback.
-
But only binary breaking changes, not runtime ones, correct? So, shadowing wouldn't affect anything. |
Beta Was this translation helpful? Give feedback.
-
I know there's the equality issue, but what else? Note that there's no guarantee of forwards-compatibility, and so for example, if FSharp.Core were made |
Beta Was this translation helpful? Give feedback.
-
Vectorized collections operations, for example. Or if we'll want to migrate async to state machines, there might be some breaking changes. |
Beta Was this translation helpful? Give feedback.
-
|
I remember a huge PR a few years ago by @manofstick to replace |
Beta Was this translation helpful? Give feedback.
-
|
The Option type being a ref type when it should be a value type is a breaking change needed by the high-perf, real-time devs. Having to use OptionValue is a PITA. Many libraries only accept/return Option<'T>, which generates a lot of GC activity in a hot loop. |
Beta Was this translation helpful? Give feedback.
-
|
Good direction, a specific point I would like to see changed is that |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, versions are up for discussion, not sure if it's the prettiest solution or not. In regards of syntax changes - also need to think more about it, what would it imply and how can we communicate this. |
Beta Was this translation helpful? Give feedback.
-
|
I think it could get pretty unwieldy to maintain differing versions here :/ |
Beta Was this translation helpful? Give feedback.
-
That's my concern as well. Also opens up potential rabbit hole of "try to figure out what implementation is used based on sdk, language version and project flags" |
Beta Was this translation helpful? Give feedback.
-
|
My understanding is that if breaking change is actually fixing the long-standing buggy (or ineffective) behavior then it's normal. Relying on "incorrect" or undocumented behavior is a mistake anyway, so fixing it to to be "correct" only makes invisible bugs to become visible. |
Beta Was this translation helpful? Give feedback.
-
It won't, just an old fsharp.core will be used, depending on language version.
That's the whole point, introduce a breaking change, with ability to quickly opt out (either via language version or some property). Alternatively it can fully be opt in via the same mechanism. Can't just make a breaking change and not let people to chose to fallback to the old behaviour. |
Beta Was this translation helpful? Give feedback.
-
This doesn't have any importance to me. Let's say I have a silent bug sitting in my code which relies on buggy NaN comparison. It's 99% chance that I don't know about it (otherwise I would fix it myself). As I don't know about it - I upgrade FSharp.Core to get new features and/or performance (why do I upgrade otherwise). And it appears that upgrade breaks in production. At the moment when I investigate and issue, it would be clear that the issue is that I relied on NaN in the first place, so I'll rather fix it than enable compat.
If people are that afraid of doing upgrade that after upgrade they want to enable compat, then they shouldn't upgrade at all. Because the unintentional breaking changes can still happen and nobody is immune of those. |
Beta Was this translation helpful? Give feedback.
-
Exactly, you're only describing your experience, which is not necessary mapping to others'. I talked to some of F# folks who use it in bioinformatics or telecoms, and they will appreciate if we don't break much of runtime. |
Beta Was this translation helpful? Give feedback.
-
I'll definitely appreciate this as well! :) But whenever I upgrade major version of any library or framework, I do acknowledge that runtime can be broken. Also, if I really care about the minimizing the impact of upgrade, I'll very carefully read release note and possible breaking changes of major version change. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @Lanayx . Any runtime bugfix is "breaking" since when fixed it is a runtime change in behaviour and people may be relying on the bug. We should not be scared about bugfixes! Any approach that unblocks F# progress is good, especially in an area like the canonical example here which both fixes a bug and improves performance. That includes the proposal here. However the proposal adds additional complexity in communication, and may add additional complexity in the compiler, which will then result in making it harder to make improvements in future. So I believe the best approach would be to do nothing except fix the bug. If anyone for historical reasons wants to preserve runtime behaviour then they can specify an FSharp.Core version and a dotnet sdk. |
Beta Was this translation helpful? Give feedback.
-
|
Another solution that comes to mind is to have a new Core lib "layer", something like A reference to (Yeah, this approach has a bunch of downsides, and for now I'm proposing it for brainstorming purposes only.) |
Beta Was this translation helpful? Give feedback.
-
|
That sounds no different to just a nuget with some shadowing modules. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that is. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, done, what should I include next? https://www.nuget.org/packages/FSharp.Core.Faster We can test things on this package version and iterate faster than normal FSharp.Core. |
Beta Was this translation helpful? Give feedback.
-
|
Nice! When shadowing you might run into #13535 though, as we created such a library internally as well |
Beta Was this translation helpful? Give feedback.
-
Just to be clear, I unironically intend to use it as platform for experiments and benchmarks. I also might try and use it in our VS extension (since it's more or less independent) and maybe in future LSP layer, since it'll be a new project with small to no risks. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to make options, choices, etc structs and automatically insert glue code for conversion to reference types on interop with old libraries? |
Beta Was this translation helpful? Give feedback.
-
|
Been thinking about it as well. Will experiment with it. |
Beta Was this translation helpful? Give feedback.
-
|
Don't forget tuples, basically they're wrappers, should've been ValueType |
Beta Was this translation helpful? Give feedback.
-
|
If such a breaking change is introduced in Fsharp.Core 9 would that mean any nuget package referencing Fsharp.Core 8 could misbehave in my app using Fsharp.Core 9 ? |
Beta Was this translation helpful? Give feedback.
-
|
If newer core is loaded, then yes (given its runtime change and nothing was inlined). |
Beta Was this translation helpful? Give feedback.
-
|
DESTROY ALL NON-VALUE OPTIONS |
Beta Was this translation helpful? Give feedback.
-
|
That is a non-behavioural breaking change. It will result in huge compile-time and runtime breaking changes, and will likely never happen in such form. I can suggest shadowing for all functions used to work with value options. |
Beta Was this translation helpful? Give feedback.
-
|
Shadowing is a great idea that solves the problem. Throw in a nice compiler warning too and we'd be good to go! |
Beta Was this translation helpful? Give feedback.
-
|
If we don't break things other people will, it's part of growing up, (none ValueType wrappers) needs byebye |
Beta Was this translation helpful? Give feedback.
-
|
Shadowing doesn't guard against code that uses reflection. |
Beta Was this translation helpful? Give feedback.
-
Yeah, but reflection should then depend not only on the structure but also on the types of entities (structs vs ref types, etc), which is surely a "deep" implementation detail, and people should not do that (I know they will anyway). |
Beta Was this translation helpful? Give feedback.
-
|
Leave behind people who wants to use the old version, by introducing change inside next version of F# / .NET and telling people if upgraded to newest version there is breaking change, start documenting the behavior of old version and the new version of the language is different and how, and making these changes a moduler part of the language, so people who wants to use the old version of a specific part of the language can specify so (some how), other parts of the language can be using latest F# features But first introduce breaking change in a way that both the new version and the old version is equally obvious, so McGriddle w/peanut and McGriddle without peanut both are on the menu, now 1~2 yrs has passed we can have the older version available in non obvious way and eventually be making the decision whether to keep the old version around (.NET Framework is around still) Meaning in visual studio have the option of { use ValueType for the fsharp core library } available in .NET 9 and turned on by default Now if we are starting to have a bunch of flags in Visual Studio project property and one single { use latest } flags to hide them all that's off by default for the brave, the fsharp language can be agile enough, similar to Haskell If fsharp is performant and elegant, that's a result everyone wants seeing Sometimes you simply wanted to write quantum entanglement in classical computer in fsharp because it feels closer to doing math |
Beta Was this translation helpful? Give feedback.
-
Yeah, this isn't happening any time soon. Especially if the change is "silent" or runtime. |
Beta Was this translation helpful? Give feedback.
-
|
People building their project in .NET 6 is still going to use the old version, you can achieve the adaptive compatibility because people has to change their project to use the newer version of Fsharp, as we are moving on to .NET 9 if they use new version of course they get new features and breaking changes and what comes with it |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
This has nothing to do breaking changes in core library. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
This, again, has nothing to do breaking changes in core library. |
Beta Was this translation helpful? Give feedback.
-
|
I love planned, intentional breaking changes. It means that things are progressing, and the truth is: people complain about it, but most of the time it takes an average mid-level programmer less than a day to make whatever changes need to be made for new versions of stuff. (I'm not as big of a fan of unintentional breaking changes, i.e. bugs.) We're in a new world with LLM's and Copilot. If you imagine a compatibility helper process of some sort (one-time migration tool? integration with IDE's? a target in MSBuild? just thinking out loud...) that submits code to an LLM and allows us to automatically evaluate it to find things that could be breaking with a new version, it allows us to move much faster than we ever have before in terms of breaking changes. I'm a huge fan of the expansion in the last many years of warnings and code fixes (💡), but those rely on the compiler to find issues. LLM's can do more and different things than pure compilation. Yes, as of January, 2024, this seems like a less reliable way than compilation, but I think of Wayne Gretzky's famous quote: "I skate to where the puck is going, not where it has been." Looking ahead to 2025-2026, with improved, much less expensive GPT-4-level models, and then more advanced GPT-5-level models, incorporating LLM's into our compilation processes seems like a no-brainer. This - breaking changes in a new language version - is exactly the kind of thing that's a perfect use case for starting down that road. Taking advantage of these new tools lets us accelerate the changes we can make with our languages. I'm going to be building LLM usage into the source control layer with Grace in as many ways as I can think of. Using them with large context windows is expensive today but will be much less expensive in a couple of years, and using them for this - a one-time(-ish) migration between language versions - is so much less expensive than loaded-cost-per-hour for a programmer. |
Beta Was this translation helpful? Give feedback.
-
|
I think I would favor the simplest break possible: release a new major version of FSharp.Core, referenced by default by the new SDK. If someone has pinned an older version of FSharp.Core, use that version; otherwise, use the one that came with the SDK—as is currently done. When the new SDK compiled an existing project, we could use target framework as a heuristic and emit some kind of warning if it was lower than the framework version in the SDK at release and the project did not have FSharp.Core pinned. The warning would mention the incompatible runtime behavior in the new FSharp.Core version. The user could dismiss the warning for such a project in two ways: if targeting an older framework version, say ProsWhen compiled with the new SDK:
ConsWhen compiled with the new SDK:
|
Beta Was this translation helpful? Give feedback.
-
|
(epistemic status: personal non-canonical prediction of my employer's preferences) We are currently stuck with FSharp.Core v5 because of an unfortunate choice many years ago to standardise on pickling instead of serialising. Any upgrade of FSharp.Core is currently breaking for us due to the resulting inability to read in output that was pickled from older versions of FSharp.Core. I've been putting forth some effort over the last few years to unblock an upgrade by moving parts of the world to more stable output formats, but it's a very slow job. So it would make things much easier for us if we could opt into new behaviour purely from the SDK or language version rather than FSharp.Core. Given warning and the ability to opt out on a case-by-case basis, I expect we are generally happy to accept breaking changes as long as they are very clearly indicated in the release notes. Enough of us do read the release notes each cycle that we'd learn about it immediately. We already view SDK upgrades with deep suspicion (because NuGet is typically unusable until at least the .20x release due to performance regressions in the .10x releases), so we are already on high alert when we move to a new SDK and I'd expect us to catch issues pretty quickly. Our development model is to keep versions of critical libraries in tight lock-step across all our in-house dependencies, so "silent breakage when a library was built and tested with a lower FSharp.Core and was consumed in a binary with a higher FSharp.Core" wouldn't arise for us as often as one might expect. Developers aiming for maximum compatibility already have to test against many different versions of the runtime, and this is easy with |
Beta Was this translation helpful? Give feedback.
-
|
The pickling problem is that a long time ago (even before my time, which was six years ago now!) we advertised to our internal users that "you can safely pickle massive binary blobs, it's much faster than any other serialisation format" (which was true, to the best of our knowledge, using an in-house fork of FsPickler; it may even still be true now). Our users are mathematical researchers and not programmers, so we set up a few standard APIs around this pattern, and we have a bunch of tests in various pipelines for those APIs. The particular test I have in mind is: take a version of our platform from three months ago; write out a bunch of common data types with it using a bunch of the common utility functions; read it back in using today's platform-under-test; verify that you read in the same thing as was written out. That test breaks during an attempt to upgrade from FSharp.Core v5.0.1 to v6. Off the top of my head, I don't remember why, but ultimately I claim this is a perverse use-case that FSharp.Core shouldn't worry about breaking: nobody should expect pickling to be stable across library version upgrades. The real fix is for us to stop using a pickler as a serialiser, and instead migrate every call site where stability matters to a more self-describing format like BSON or Parquet (whatever is appropriate at any given call site). We've been doing this bit-by-bit, but there's quite a lot of call sites, which often have to be deeply understood to perform this change, and it's not really the sort of maintenance anyone can ever get much dedicated time to do. |
Beta Was this translation helpful? Give feedback.
-
|
@Smaug123 : I have made the exact same mistake years ago despite reading the first page of the FsPickler docs :-)), luckily realized sooner while it was still easy to migrate. It's just so fast and especially convenient to get things working in a quickly evolving environment...
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting problem. Seems manageable to migrate by defining a serializer that adds a new serialization method in addition to pickler and a deserializer that deserializes either, then deserialize and reserialize the data, then delete the pickler, then update fsharp.core. We are doing well with cbor serialization, we find that manual serialization is great for making changes needing backwards compatibility including occasional tricky sequential changes like the one above, and that github copilot is great at writing serializer code so you might find that the process goes faster now than it did a few years ago. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it's all solvable in principle, but the correct choice of serialisation format is different on a case-by-case basis - it's not the kind of thing one can trivially automate, or else you end up trying to reserialise a petabyte of floating point data as JSON :) |
Beta Was this translation helpful? Give feedback.
-
|
That may be, but 1. it's possible to choose something which dominates pickler in terms of speed and size, and 2. JSON is heavily dominated in both dimensions so never the correct choice. |
Beta Was this translation helpful? Give feedback.
-
|
I honestly think it's worth it. Dealing with different versions of things is already a challenge, but so often that challenge seems to come with little real world benefit for the hassle cost. A breaking change moving forward is.. Well actually moving forward. It can suck, but as long as there is a bunch of support for the change, something like making analyzers that check for known breaking changes, and supply suggestions, or diagnostics or some sort of clue about whether or not it's going to happen or what to do about it, I think it's ultimately healthy to cull the crufty, to prune the dead branches, etc... It's a cost, but the reverse is a higher one, I think. |
Beta Was this translation helpful? Give feedback.
-
|
This a good approach. Those are the good breaking changes - if their breakiness can be detected by analyzing the source code. Perfect example is the generic equality and how it works with floating point |
Beta Was this translation helpful? Give feedback.
-
|
Which changes are actually proposed @vzarytovskii ? Only avoiding boxing on equality ? Is there a list with reasons , impact and current workarounds? |
Beta Was this translation helpful? Give feedback.
-
|
This is not proposal for any specific changes. It's is a discussion of possible approaches if library breaking changes make sense and we want to introduce them, how it should be done. |
Beta Was this translation helpful? Give feedback.
-
|
Don't do breaking changes! Here is why: The news about braking changes is scary and confusing for new F# adopters. So bad for F# adoption Or did I miss other braking changes that are not about performance ? Or can't be fixed with shadowing or additional code? |
Beta Was this translation helpful? Give feedback.
-
|
Any arguments made against breaking compatibility are pretty much defeated by the fact that we've already successfully navigated possibly the biggest transition in the .NET Framework -> .NET Core move. If we could break compatibility with complete disregard for legacy code, imagine what we could do:
I would venture to suggest, that while keeping compatibility is a noble goal, in the sufficiently long term it's highly detrimental to the adoption of F#. Trying to explain to new developers how/why all this stuff exists that we shouldn't use and have to work around is really annoying. if we do not actually do this, F# will continue to languish in its warty state, filled with thing that seemed like a good idea at the time. Is it really is the intention of Microsoft to literally keep all of these problems around forever? that seems like an engineering approach that I and many others would fundamentally disagree with. I really don't want to have to be dealing with these legacy elements still in 10 years time - we might as well try to get rid of them sooner rather than later. |
Beta Was this translation helpful? Give feedback.
-
What you're suggesting is pretty much "Hey, let's not think of users with legacy code bases, who just update SDK and want their code just work, and instead do all sorts of breaking changes, for reasons.". It's not right approach here. There are a lot of F# projects out there which can't account such breaking changes, we for sure need to think about those.
We can't "just" make it a struct, it will break all existing libraries which are using options and not rebuilt with latest
They are not the interchangeable, they have different approach, cold vs hot, implicit vs explicit cancellation, composable vs not, etc.
Not sure what that means, but probably less breaking than others.
Also not sure what that means.
That was discussed many times, we wanted to hide a bunch of mlcompat under separate lexer/parser.
It's not, we're not literally keeping all of these problems around forever. This is exactly why this discussion is started.
There are people with different projects and use-cases, you described yours - when you're fine if every major version language does breaking changes, both compile-time and runtime, and you're dealing with those. The other side of the coin is people who can't and won't deal with them, as it simply doesn't work for them. Is is important to find a middle ground (which this discussion aims to do), and not just say "hey, let's just change things" or "hey, let's keep this issue foreve", as it's not productive. |
Beta Was this translation helpful? Give feedback.
-
Just to note that the large majority of .NET Core work was in maintaining compatibility with most of .NET Framework, and especially in ensuring most libraries can get ported over to .NET Standard fairly painlessly. Of course there were some big breaks, but the reason why most people have been able to move their code over is explicitly because of legacy compatibility. |
Beta Was this translation helpful? Give feedback.
-
|
Can we incorporate some features of FSharpPlus e.g. NonEmptySeq? Maybe a NonEmptySeq can even be defined as a seq with const generic length constraint > 0. These can help ensure domain constraints. They are related to breaking FSharp.Core because of fsprojects/FSharpPlus#480: |
Beta Was this translation helpful? Give feedback.
and others
-
Would like to start this discussion for how should/shouldn't we be introducing breaking changes to core library.
Why: Things like the issue below, are reasonable and benefitial for average codebase but can be/are breaking runtime behaviour:
Overall rationale is: this probably should be done eventually if we don't want core library to stagnate and lag behind in features.
One of the solutions is to use shadowing:
FSharp.Core.Compat.*, which will contain a bunch ofAutoOpen(?) modules, which will be shadowing a standard library modules and will have "default" corelib behaviour.FSharp.Core.Compat.Approach has some pros and cons:
Pros:
Cons:
FSharp.Coreonly or ifFSharp.Coreis loaded at runtime, might face breaking changes at runtime without any warnings.Question is do we think it's worth it? I personally do, since otherwise core library will be stagnating and lagging behind in features.
fyi @T-Gro @Happypig375 @dsyme @cartermp
Request for comments: additional approaches, flaws in current approach.
Update 1: For those with edit permissions, feel free to add to OP's pros/cons and additional approaches.
Update 2: We've had an idea of "layered" core library, which essentially may cover this approach as well, but ids probably a bit orthogonal to this specific discussion (thought related to it).
Beta Was this translation helpful? Give feedback.
All reactions