Agreed. Imagine this: let distance = (x * x + y * y).squareRoot()
That reads extremely foreign to me. Why not provide this as a static function that takes Self on the protocol so that conformances can specialize it, and have the protocol-constrained global function sqrt<T: FloatingPoint> call T.sqrt? On Mon, Jul 11, 2016 at 3:42 PM Chris Lattner via swift-evolution < [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? > > -Chris > _______________________________________________ > 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
