+1 Less namespace pollution is great. I’d prefer to see the essentials module further broken up. Maybe: FoundationTypes, FoundationFiles, FoundationSerialization, FoundationOS
A high-precision, low-cost time API.
Darwin's mach_absolute_time() or what is called hrtime on other platforms is standard and useful for performance measurement.
3 Likes
Personally I hope very much that locks, atomics and threads APIs will be added to the standard library. I think the current concurrency story pushed to developers is lacking and this is having a highly detrimental effect.
14 Likes
yes. atomics please
1 Like
This might be an overgeneralized/simplistic argument, but if Foundation has a need for it that isn't provided for by async/await, wouldn't there be legit uses for it outside of Foundation as well?
17 Likes
I think we should probably save redesigning Foundation's API for once the process for proposing changes is ready to go, rather than all in one forum thread ahead of time. The interesting question for a lot of things (probably including locks) will be less "should this be available?" and more "which library should this go in?".
19 Likes
If we cut the module into smaller pieces, we may want to need "submodule" feature.
import Foundation.Foo
import Foundation.Bar
import Foundation.Baz
// or
import Foundation.*
I don’t know if it’s desirable or not.
3 Likes
Nothing should be removed, (especially the items proposed for removal) . The rest of this proposal is good.
1 Like
Structured concurrency is still in its infancy and suffers a lot in terms of performance. Regardless of that removing well established classes for the purpose of forcing the still-in-infancy “new” way feels more ideologically motivated.
4 Likes
Forgot to mention the "leeway" functionality that optimises system power consumption by coalescing timers' firing.
This is quite serious. Not all code can be (or afford being) async/await-able. If RunLoop concept in its whole is a no-no in the new foundation consider some simplified version of it, e.g. an explicit "make this call every now and then when you can" model that would be useful for clients outside of structured concurrency.
Locks (various flavours) and the mentioned above atomics are very important for lower level code. "Is it useful for foundation itself?" could be a good litmus test on what to include. IMHO Swift should be generic enough to implement Swift compiler itself, a new implementation of Foundation, a device driver, a realtime function, etc.
4 Likes
The proposal is to use a flat module structure. Submodules are not needed. I assume the Foundation module would just re-export the modules like is done in other places:
@_exported import FoundationEssentials
@_exported import FoundationInternationalization
@_exported import FoundationNetworking
...etc...
Hopefully there will be some modernization of FileManager. I'm a fan of moving FileManager APIs to use a FilePath struct similar to swift-system. It would be great to see FileManger drop the delegate pattern. Callbacks might be fine for the features that currently require a delegate.
5 Likes
Disclaimer: Don't let me spoil your excitement, I find this exciting as well, but I keep thinking about the miserable status quo and what that means for people who are already writing cross-platform programs.
I think we can all agree that swift-corelibs-foundation is kind of stuck. Despite dozens of valuable bug reports (among those ones opened by the Swift Server Team themselves) and even more valuable pull requests (like this one here), it doesn't look like anyone is scheduled to move forward with this repository.
This may or may not be a reason why there is this sudden movement about the future of foundation.
Although swift-corelibs-foundation does not fulfill its mission (source compatibility), many people are actively using it, because they must – there are just no feasible alternatives available for many of the critical parts, such as RunLoops, Streams, and more (and for the fun of it, exactly those critical parts are now scheduled to be removed…)
Let me tell you why Streams and RunLoops are critical to me: I write software that talks to OBD2 adapters for automotive diagnostics. Those adapters come in various forms with various interfaces,
e.g. WiFi, BLE, MFI, Bluetooth Classic, TTY, and what not. At the end of the day there is always a byte stream abstraction, hence Stream is the best common abstraction layer (in fact, it's a must, since on iOS, it's inevitable when you want to use L2CAP channels or an ExternalAccessory protocol).
Most of the automotive business logic is cross-platform, hence being able to run the lower part of this stack on Linux is a must for me. Hence I put a lot of work into a cross-platform streams library that makes communicating with such (and other) devices a breeze.
Now if you say Stream, you also need to say RunLoop, I don't know any other way to make use of streams. Swift Concurrency is not an option here and will not be for quite a long time – at least not until e.g., Apple changes their L2CAP and ExternalAccessory frameworks.
And rather than shrinking the functionality and semantics gap of swift-corelibs-foundation, it looks like you now want to "officially" abandon this. And even more, you don't even want to consider critical parts of the infrastructure in your rewrite.
If this is true, could you at least help us in providing the means to fork swift-corelibs-foundation, so that we can unblock it for !APPLE platforms?
In any case, this is going to be tough for me and it really dampens my enthusiasm over all the new development in Foundation.
14 Likes
A bit of a side note, but I personally think this might be the perfect (and only) opportunity to rename Date to something more accurate to what it actually is — e.g. Instant.
30 Likes
Great to hear … but … scary.
Is there a time frame for when to expect the new implementation? I’m asking because I fear that this makes it official that there will be no bug fixes in the existing foundation from now on.
I agree 100% with @mickeyl that “it doesn't look like anyone is scheduled to move forward with this repository.“ Actually this caused a lot of frustration in me:
I am tracking a more than 6 years old bug report where I provided a fix more than two years ago that is not merged. Communication just stopped.
When I noticed this bug, that was first report one year earlier, I provided a simple, 3 lines fix. Even this simple pull request has not been merged for nearly a month now. Someone got assigned, CI was triggered, that’s it. No comment, nothing. Just ignored.
For a bug that is crashing the app.
14 Likes
Hold on, are Threads also out? I hope not. Threads are essential for low level apps.
3 Likes
As to where things should go, I think threads should go in the standard library, not Foundation. Same goes for locks and atomics. These are the building blocks to write everything else. The fact that they are lacking from the standard library is a problem (in my opinion) and maybe is also one of the reasons why almost all of swift concurrency is actually written in C++, not Swift.
3 Likes
OTOH putting threads / locks / atomics into a separate framework makes total sense IRT platforms that don't need those things (embedded systems or other handicapped / minimal environments). For the same reason unicode handling should also be separable, IMHO.
2 Likes
My reasoning was that this all needs to be available to swift concurrency which is itself already in the standard library. C++ also seems to have it all as part of its standard library. But maybe there's some clever module dependencies that can be made available right down to the stdlib, I don't know enough to give a good answer.