swift

A division free integer in a range RNG has been developed: https://github.com/apple/swift/pull/39143

Yes, I've never written a line of Swift, but these cases don't seem to be of the usual variety that cause Hindley-Milner to blow up. It seems like the Swift compiler source is available, and these test cases are small. This is encouragement for someone to spend a small amount of time digging into this, just for the curiosity of it. And I mean, just something like, fire it up in the debugger, start the compiler on one of these test cases, interrupt the when it looks like it is "hung", but before it times out. Step through the code a bit, to identify the handful of functions that that we're looping through, and then report out what you find, and your best guess, the algorithm is implemented correctly and is hopelessly intractable, or "hey, didn't we already check down this branch previously?". I'll give you my next upvote on HN. https:

There are a bunch of other chokepoints, but type inference is a big part of it: https://github.com/apple/swift/blob/main/docs/CompilerPerfor... Another thing I would add to swift as a flag is to make imports based on specific files vs. an abstract "module", there is a lot of repeated work that happens because of that last time I looked.

Lenore’s approach uses rejection sampling, which translates to needing an uncertain amount of input — a uint128 may or may not be enough. But there is one related algorithm that doesn’t: https://github.com/apple/swift/pull/39143. This method only requires (output word size + 64) bits, which is really convenient for us since we probably don’t have 2^64 buckets. Same ballpark as (hash >> 64) * n, just with bias correction. With this method the output value will be very not-scrambled relative to the high bits of the hash. Now whether that’s a problem is… someone else’s question. One can always do some shifts and XORs.

According to their changelog[0], Clock was added to the standard library with Swift 5.7, which shipped in 2022, at the same time as iOS 16. It looks like static linking by default was approved[1] but development stalled[2]. I expect that it's as simple as that: It's supported on iOS 16+ because it's dynamically linked by default, against a system-wide version of the standard library. You can probably try to statically link newer versions on old OS versions, or maybe ship a newer version of the standard library and dynamically link against that, but I have no idea how well those paths are supported. 0. https://github.com/apple/swift/blob/main/CHANGELOG.md 1. https://github.com/apple/swift-evolution/blob/main/proposals... 2. https://github.com/apple/swift-package-manager/pull/3905

This algorithm produces biased result with probability 1/2^(32-bitwidth(N)). Using 64 or 128 random bits can make the bias practically undetectable. Comprehensive overview of the approach can be found here: https://github.com/apple/swift/pull/39143

How would C track references for heap-allocated data originating from (A)RC-based language? I don't think what you say on .NET correlates with reality - you are not supposed to pass managed objects across FFI (you just can't, it won't let you unless you do unsafe cast shenanigans) - the correct way is to either marshal the data or use blittable representation (plain structs can be passed as is, either by reference or value, same goes for arrays/pointers of primitives). On the rare occasion where unmanaged code needs to keep a GC object alive, it is passed via special GCHandle but that's an exception not the rule. Swift has its own high level representation for such objects which are very much not FFI compatible. ARC in Swift is a feature that requires compiler involvement to work correctly, and its structs are not FFI compatible unless th

Because of C/C++ interop, and integration with CMake, you can just add Swift to a Zephyr project and it pretty much Just Works. [The docs](https://github.com/apple/swift/blob/main/docs/EmbeddedSwift/...) should mostly apply to the Zephyr SDK as well.

>Well that’s a completely false statement. C++ is a first class language, I understand your clarification but gp (jb1991) is just using a different meaning of "first class" than you and gp (bluetomcat). For some people, a "first class language status" would also include examples such as: - C++ would be a menu dropdown choice in Xcode project options. In Xcode's "choose options for your new project", the only language options for "Storyboard"/"XIB" are "Swift" and "Objective-C". - C++ would be the programming language and API for Apple's VR headset ARKit. Instead, it requires Swift and SwiftUI. - C++ language would be prominently featured as the code examples in Apple WWDC developer conferences and presentations. E.g. go to WWDC sessions page and compare Ctrl+F search hits count for "C++" vs "Swift": https://developer.apple.com/wwdc23/