Expanding slightly: A generic math module / protocol / whatever that provides all the math operations generically over the built-in floating point types is out of scope for the language/stdlib in Swift 3. Everyone wants it, it’s simply too late to add it (as with many other features and ponies).
N.B. “Out of scope for the language/stdlib” does not mean “you can’t do it”. This is a great opportunity for someone to provide a library solution (it is fairly simple to do so, even if there’s a good amount of boilerplate). I would even suggest that if such a library were widely used and vetted, it would form an excellent base for proposing a math module once Swift 3 closes down. – Steve > On Jul 11, 2016, at 6:13 PM, Stephen Canon via swift-evolution > <[email protected]> wrote: > > It wouldn’t delay code intended to operate generically at all. That code can > use .squareRoot( ). > >> On Jul 11, 2016, at 6:12 PM, G B <[email protected]> wrote: >> >> While I don’t have a strong opinion about what functions are in the global >> namespace and which are in a `Math` module, I’m not excited about the idea >> of delaying the availability of generic implementations of floating point >> functions. >> >> How would this affect code intended to operate generically over Float and >> Double? I’ve made the mistake of trying to do this with some of my code and >> it’s remarkably painful for what I’d hoped would be a simple abstraction. >> >> Right now (pre SE-0067), it takes a surprising amount of tinkering to get >> code to work generically across those two types. Provisions need to be >> added to provide `sqrt`, `sin`, `cos`, etc. While it all compiles down to >> the same instructions, I don’t feel it is natural to call `squareRoot()` as >> a method. >> >> I don’t necessarily care if these functions are in the global namespace, or >> if they’re imported from a `Math` module. I’m also not convinced that they >> should be part of the core FloatingPoint protocol. `sqrt` probably should >> be, but the trig functions would naturally fit together in a protocol that >> itself conforms to FloatingPoint. >> >>> On Jul 11, 2016, at 14:28 , Stephen Canon via swift-evolution >>> <[email protected]> wrote: >>> >>> Post SE-0067 FloatingPoint provides the usual global operators, as well as >>> a single global function: >>> >>> func sqrt<T: FloatingPoint>(_: T) -> T >>> >>> It seems out of place and lonely, and it would be nice if we can keep the >>> default members of the global namespace to a minimum. >>> >>> I’d like to suggest removing this global from FloatingPoint while keeping >>> the existing global functions for concrete types in the Darwin.C module. >>> The square root operation would still be available for all FloatingPoint >>> types as `.squareRoot()`. >>> >>> I would also plan to provide this and other math.h-ish globals in a future >>> (post swift 3) Math module. >>> >>> – Steve >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
