[swift-evolution] [pitch] remove global sqrt<T: FloatingPoint>

[Tony Allevato]

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
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/e1a7ade0/attachment.html>