Yeah, I ended up writing a RationalNumber type (generic on Term) and then rewrote a better version of Measurement and Unit that could take the RationalNumbers (as well as FloatingPoints). 
@mgriebling @jasonbobier Interesting, I've open sourced swift-measures last year.
- It has basic units, as well as many derived units that Foundation doesn't have. You can find the list in this DocC I made.
- There's also all the binary and metric ISO prefixes
The Measure object could easily have a generic type for its value.
Interestingly too I pitched the Rational type last year for Google Summer of Code. It was not accepted on the programme, however I still open sourced my work. It's incomplete and would need more thoughts.
8 Likes
I've done several years of iterations on the RationalNumber, so it is pretty well developed. I haven't released it as a package yet mostly because:
-
I didn't do enough research into how rationals were handled in other languages yet. (I prefer to write something so that I have good knowledge of the issues before optimizing.)
-
I have been using it to test new features in Swift/Foundation. For example, I just added the first iteration of FormatStyle, FormatStyle.Attributed, and FormatStyle.ParseableFormatStyle to it. This version has separate FormatStyles for mixed number, improper fraction, and decimal. I may want to combine them depending upon how the usage feels.
-
If I release it, suddenly I need to maintain it for others. Ha!
-
I need to add a few more functions (throwing versions of Equatable and Comparable).
it is fully covered with test cases and documented though.
1 Like
I've used them in Perl and Python, but C++ has them too these days according to Rational data type - Wikipedia.
Yep. They are used when you want to guarantee accuracy. For example, neither Decimal nor Double can represent the rational number of 1/3 correctly, but a RationalNumber type can.
2 Likes
Very nice if you are at it maybe revise the Process api too to support async await out of the box and be more like GitHub - Zollerboy1/SwiftCommand: A wrapper around Foundation.Process, inspired by Rust's std::process::Command.
File handling should also improve and in my opinion be more like
One last thing, we are at the end of 2023. Any plans in announcing a release date?
3 Likes
It appears swift-foundation will be releasing over time, as it has already shipped as part of Apple's 2023 OS versions. I imagine we may see another "release" for the spring OS updates, and then even more for the next major. It's unlikely there's a single date where the whole framework is expected to be complete (not that Apple would share their expectation anyway).
1 Like
Where is it in use currently? When you import Foundation on the new iOS and macOS releases it's using this new version of Foundation? How does that compare to Linux at the moment?
3 Likes
On Apple platforms the current releases use a mix of the “new” open source foundation and the old Apple codebase. The share that comes from the new open source project will grow over time as we build it out.
On Linux, by default if you just do import Foundation, you get the “old” corelibs-foundation, but you can also import the “new” foundation modules from the project.
7 Likes
Is this documented anywhere; how can I tell what's from which in each OS & version? And when e.g. the fixes for number formatting will be available on Apple's OSes?
I was assuming, 'til this thread, that the new Foundation was going to be largely academic until some big 'flag release' where it was swapped in wholesale. I'm of course pleased that it's actually getting deployed much sooner than that, and that might make me more willing to invest time in new Foundation (bug fixes etc) if I can get a little more concrete idea of timelines. (I like the idea of fixing root causes in Foundation, but I also need my software to work now or imminently, so there's a question of whether to go further than just local workarounds)
6 Likes
the new Foundation has no tags (semver or otherwise), so it’s still not possible to distribute anything that imports it while using SPM.
10 Likes
Note that I started a new topic on this for not to continue an old topic with many participants. The linked comment contains a description how it should not be.
Just stumbled upon that separation of Foundation parts on platforms other than Apple while testing code on both macOS and Linux. Read the original pitch and found absolutely no benefit in it.
Source code compability is a benefit. Whatever the separation of Foundation in parts gives you, I do not know or understand, I fail to see a benefit in that. It just introduces #ifdef's again. Did we not learn from C that this is a mess?
1 Like
That's corelibs Foundation which is the 'old' Linux version and done for linking reasons (FoundationNetworking on Linux requires libcurl-dev to be installed and linked for instance).
The new Foundation being discussed here will be the same on all platforms, so importing FoundationEssentials will import the same stuff on all platforms. This will align all supported platforms of Swift
4 Likes
For some background on new (new) Foundation - Tony spoke about it at the ServerSide.swift conference
11 Likes