> On Jul 11, 2016, at 6:42 PM, Chris Lattner <[email protected]> wrote: > > >> On Jul 11, 2016, at 2:28 PM, 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. > > I’m very concerned with this. Why not do exactly the opposite? Remove the > concrete operations from Darwin.C and replace it with a single generic one? > > The rationale for using global functions here is that they are “terms of art” > in numerics nomenclature. If they aren’t, then we should consistently > eradicate all the global operations: > > assert(Double.pi.sine == 0.0) > > Is this the direction you want to go?
No, definitely not. I’m fine with placing a generic implementation in Darwin.C. I would include that as part of this change. Post Swift 3, we should also have a Swift math module that provides the usual sqrt<T: MathTypeOrWhatever>(_: T) operations. However, I’m not totally convinced we want every math operation we think of in the global namespace *by default*, and I’d like to avoid painting ourselves into a corner where sqrt( ) just sticks out like a sore thumb in the base stdlib for all time. – Steve _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
