Comments (10)
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 zip
, unzip
.
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.
from fsharpplus.
So the implication is mainly in how overloading is handled?
from fsharpplus.
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.
from fsharpplus.
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:
- Next version of F# is released with the above mentioned breaking change
- We migrate this project to .Net Framework 4.7
- People start adopting struct tuples, at the moment nobody complained about it.
and this will be after v1.0 so we would have to do it in a backwards compatibility way.
Any thoughts?
from fsharpplus.
What breaks? Will it interop with old style tuples?
from fsharpplus.
The breaking change is that next F# version will have .ItemX
member property available for syntactic tuples, so by calling for instance item1 (1,2,3)
would result in an ambiguous overload resolution error, because now there will be two overloads that match.
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.
from fsharpplus.
So, better to document that you need to use the latest f# version instead?
from fsharpplus.
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 item1
works only with F# syntactic tuples.
from fsharpplus.
Sounds good.
from fsharpplus.
Implemented in #524 no breaking changes AFAIK.
Also note about my comments above that at the moment struct tuples don't implement ItemX
members.
from fsharpplus.
Related Issues (20)
- `(>>=)` should be constrained with `Map` HOT 8
- New Validation type HOT 2
- Array.replace takes in seq for its two first values instead of arrays
- Adjust package info with icon and license elements
- Add more static member operators like >=> HOT 1
- `String.take 0 s` throws IndexOutOfRangeException HOT 2
- Traverse Lens Documentation Needs more Examples HOT 1
- Documentation table of contents is missing list of namespaces HOT 3
- Proposal: A set of modules for list and tree zippers HOT 1
- Upload packages built on main branch onto GitHub NuGet feed
- Int32.TryParse and F#+ tryParse give different results HOT 6
- Fable 4 support HOT 3
- Type inference issue with applicative2 HOT 1
- [API Proposal] String.(try)FindLastSliceIndex HOT 3
- Clean up preprocessor directives
- Drop net45, net6, Fable3 from F#+ 2 release
- net45 not compatible with updated F# typeprovider
- Naming convention for (non-generic) Sequence-like overloaded methods
- Adjust async/task/value task tests to work on net6 and on release branch
- Cannot destructure ask when using ReaderT HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fsharpplus.