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
