Vincent Esche

It wouldn't, unfortunately. 😕 I would expect the API to `fatalError()` on anything but `Float` or `Double`. I agree though, that this might not be the desired behavior for a...

> > I would expect the API to `fatalError()` on anything but `Float` or `Double`. > > I think this would be a step backwards in terms of API usability....

With Swift already [supporting `Float80`](https://developer.apple.com/documentation/swift/float80) and `Float16` being [scheduled for addition in Swift 5.3](https://github.com/apple/swift-evolution/blob/master/proposals/0277-float16.md) simply providing a generic API for `T: FloatingPoint` is a dead-end, safety-wise. As such initial thought...

They should be, yes. Good catch! Would you like to open a pull request for it?

There should be a single multi-platform framework target available to you when using SPM or CocoaPods and individual ones (`Surge-iOS`, `Surge-macOS`, `Surge-tvOS`, `Surge-watchOS`) for each platform when using Carthage. 🤔...

I personally am leaning towards Option B. What are your thoughts, @mattt?

Hi @mattt, @alejandro-isaza, I was wondering if you could give these proposals a light read some time and provide some short feedback on the proposed changes? (Some of them are...

> Among the non-breaking changes, #143 seems like a clear win, and so does #144 (TIL about the Box–Muller transform — that's really cool!). They might also make it into...

If Carthage was to do a check for SPM projects with missing `.xcodeproj` files and added an intermediary step of running `Swift package generate-xcodeproj` it would work just fine. Alas...

Hahaha, you gotta be kidding me. 😂 > My first approach was to eliminate the string best guessing stuff in the API Design to move over to a struct. Then...