[swift-evolution] [pitch] remove global sqrt<T: FloatingPoint>
allevato at google.com
Mon Jul 11 17:48:57 CDT 2016
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 <
swift-evolution at swift.org> wrote:
> > On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution <
> swift-evolution at swift.org> 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
> 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?
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution