-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use struct Tuples #53
Comments
I did a quick test and I confirm it won't break anything, as long as we don't use it everywhere, namely in functions like My feeling is that we should add it as an addition, not as a replacement, since there is not only existing code, also F# functions in the core that still use reference tuples, so at this time it's not clear that struct tuples will be adopted by default in the F# ecosystem. If they do so, it will be a breaking change, and so we'll follow that breaking change here. The situation is different with the result type because at the moment there is only one function in core that uses the Choice type, which is Async.Catch. Another thing to decide is whether we should upgrade to NetFramework 4.7 or not, because otherwise System.ValueTuple.dll will have to be added as a Nuget and it will complicate the dependencies. For Netstandard 2.0 it shouldn't be a problem as it is already included. Still it should be possible to multi-target older versions of the framework, but it's work, and at the moment I don't feel comfortable doing it myself, but as always PRs are welcome and will be accepted as soon as they demonstrate they don't break anything. |
So the implication is mainly in how overloading is handled? |
No, I think for stuff exposed externally we should keep using ref tuples, that will be the F# way for some time at least. It's mostly internally where we'll use it. And yes, there will be some overloads for monoids and so on, but that shouldn't be an issue (I hope). The key thing is whether to upgrade to .NET Framework 4.7. |
I'm bit unsure about what to do with this. I haven't seen wide adoption for struct tuples in general. There is a breaking change regarding tuples in the next F# 4.1 version, I just realized it will break some stuff here, so I prepared a fix. Maybe we can postpone struct tuples until:
and this will be after v1.0 so we would have to do it in a backwards compatibility way. Any thoughts? |
What breaks? Will it interop with old style tuples? |
The breaking change is that next F# version will have The fix I did is straight forward, it removes the overload for System Tuple (the one with the trait call) at the cost of excluding System Tuples but they will become available again when you upgrade to the latest F# version. |
So, better to document that you need to use the latest f# version instead? |
Actually it's also possible to fix it in such a way that it will keep working with System Tuples in current F# versions, but it will complicate a lot the code and System Tuples are rarely used, less in a generic way. In the coming F# version both tuple types will become (almost) equivalents. We can state in the docs for the moment that |
Sounds good. |
Implemented in #524 no breaking changes AFAIK. |
In principle it looks like it won't be a breaking change.
The text was updated successfully, but these errors were encountered: