[pitch] remove global sqrt<T: FloatingPoint>

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

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 <swift-evolution@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.

– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

···

On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution <swift-evolution@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.

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 <g.c.b.at.work@gmail.com> 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 <swift-evolution@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.

– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

···

On Jul 11, 2016, at 6:42 PM, Chris Lattner <clattner@apple.com> wrote:

On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution <swift-evolution@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?

Seems reasonable enough.

···

On Mon, Jul 11, 2016 at 16:28 Stephen Canon via swift-evolution < swift-evolution@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.

– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

> On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

For certain functions (sqrt, sin, cos, log, etc) we’ve grown up in math class calling them as a function on an argument rather than viewing them as a property (or method) of the number.

Just like we prefer to use `a - b` rather than `a.sub(b)`, we (or at least I) prefer `sqrt(a)` over `a.squareRoot()`.

It seems this is dooming everyone to either reverse their internal math grammar or do what I’m doing now and write their own generic function for no other purpose than to wrap a method call to look like a function call.

I’d be less resistant if your proposed `Math` module was concurrent with the change.

···

On Jul 11, 2016, at 15:13 , Stephen Canon <scanon@apple.com> wrote:

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 <g.c.b.at.work@gmail.com> 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 <swift-evolution@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.

– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I’m not sure what problem you’re trying to solve. I think you agree that people should be able to write a generic function and use “sqrt(x)” where x is some FloatingPoint bound type, right? If so, is it just the concern about it being injected into every program that imports (e.g.) Foundation?

-Chris

···

On Jul 11, 2016, at 3:52 PM, Stephen Canon <scanon@apple.com> wrote:

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.

Expanding slightly:

A generic math module / protocol / whatever that provides all the math operations generically over the built-in floating point types is out of scope for the language/stdlib in Swift 3. Everyone wants it, it’s simply too late to add it (as with many other features and ponies).

N.B. “Out of scope for the language/stdlib” does not mean “you can’t do it”. This is a great opportunity for someone to provide a library solution (it is fairly simple to do so, even if there’s a good amount of boilerplate). I would even suggest that if such a library were widely used and vetted, it would form an excellent base for proposing a math module once Swift 3 closes down.

– Steve

···

On Jul 11, 2016, at 6:13 PM, Stephen Canon via swift-evolution <swift-evolution@swift.org> wrote:

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 <g.c.b.at.work@gmail.com> 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 <swift-evolution@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.

– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The problem with having the Math module concurrent with this change is that such a thing is necessarily post-swift 3, whereas this change should happen in Swift 3 if it’s going to happen at all.

Given that this only effects one function, and you already need your own wrappers for every other math operation, it seems like the right tradeoff to do it now.

– Steve

···

On Jul 11, 2016, at 6:20 PM, G B <g.c.b.at.work@gmail.com> wrote:

For certain functions (sqrt, sin, cos, log, etc) we’ve grown up in math class calling them as a function on an argument rather than viewing them as a property (or method) of the number.

Just like we prefer to use `a - b` rather than `a.sub(b)`, we (or at least I) prefer `sqrt(a)` over `a.squareRoot()`.

It seems this is dooming everyone to either reverse their internal math grammar or do what I’m doing now and write their own generic function for no other purpose than to wrap a method call to look like a function call.

I’d be less resistant if your proposed `Math` module was concurrent with the change.

On Jul 11, 2016, at 15:13 , Stephen Canon <scanon@apple.com> wrote:

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 <g.c.b.at.work@gmail.com> 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 <swift-evolution@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.

– Steve

Right, this is only about the concern that it's injected into every program that doesn’t even import anything, under the assumption that folks may push back against doing that for *every* function in a future Math module.

This is a very minor issue, which would only change anything in the short term for most users, and which has already produced more discussion than I thought possible =)

– Steve

···

On Jul 11, 2016, at 6:55 PM, Chris Lattner <clattner@apple.com> wrote:

On Jul 11, 2016, at 3:52 PM, Stephen Canon <scanon@apple.com> wrote:

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.

I’m not sure what problem you’re trying to solve. I think you agree that people should be able to write a generic function and use “sqrt(x)” where x is some FloatingPoint bound type, right? If so, is it just the concern about it being injected into every program that imports (e.g.) Foundation?

I understand that it’s only one function and that I’m probably being ever-so-slightly unreasonable but I’ve spent the last month going crazy that a language as expressive as Swift, with all of its support for protocols and generics and under-the-hood optimization, makes me do stuff like this to abstract the most typical of algorithms across functionally identical types:

protocol ScalarMathType {
    func sqrt() -> Self
    func sin() -> Self
    func cos() -> Self
    func asin() -> Self
    func acos() -> Self
    func atan2(x:Self) -> Self
}

func sqrt<T:ScalarMathType> (x:T) -> T {return x.sqrt()}
func sin<T:ScalarMathType> (x:T) -> T {return x.sin()}
func cos<T:ScalarMathType> (x:T) -> T {return x.cos()}
func asin<T:ScalarMathType>(x:T) -> T {return x.asin()}
func acos<T:ScalarMathType>(x:T) -> T {return x.acos()}
func atan2<T:ScalarMathType>(y:T,x:T) -> T {return y.atan2(x)}

extension Float : ScalarMathType {
    func sqrt() -> Float {return Foundation.sqrt(self)}
    func sin() -> Float {return Foundation.sin(self)}
    func cos() -> Float {return Foundation.cos(self)}
    func asin() -> Float {return Foundation.asin(self)}
    func acos() -> Float {return Foundation.acos(self)}
    func atan2(x:Float) -> Float {return Foundation.atan2(self,x)}
}

extension Double : ScalarMathType {
    func sqrt() -> Double {return Foundation.sqrt(self)}
    func sin() -> Double {return Foundation.sin(self)}
    func cos() -> Double {return Foundation.cos(self)}
    func asin() -> Double {return Foundation.asin(self)}
    func acos() -> Double {return Foundation.acos(self)}
    func atan2(x:Double) -> Double {return Foundation.atan2(self,x)}
}

That just seems so horribly hackish.

Even if the `Math` module only included this, it would be a win. Otherwise, I’d almost prefer that we stuff these into the global namespace to keep `sqrt` company. Right now every developer who wants to change between polar and cartesian coordinates, or calculate a radius from a circumference in a generic way needs to replicate this code…

Hopefully we all do it the same way and in the same way that Swift4 implements it or we’re all going to have to deal with the conflicts later.

···

On Jul 11, 2016, at 15:28 , Stephen Canon <scanon@apple.com> wrote:

The problem with having the Math module concurrent with this change is that such a thing is necessarily post-swift 3, whereas this change should happen in Swift 3 if it’s going to happen at all.

Given that this only effects one function, and you already need your own wrappers for every other math operation, it seems like the right tradeoff to do it now.

– Steve

On Jul 11, 2016, at 6:20 PM, G B <g.c.b.at.work@gmail.com> wrote:

For certain functions (sqrt, sin, cos, log, etc) we’ve grown up in math class calling them as a function on an argument rather than viewing them as a property (or method) of the number.

Just like we prefer to use `a - b` rather than `a.sub(b)`, we (or at least I) prefer `sqrt(a)` over `a.squareRoot()`.

It seems this is dooming everyone to either reverse their internal math grammar or do what I’m doing now and write their own generic function for no other purpose than to wrap a method call to look like a function call.

I’d be less resistant if your proposed `Math` module was concurrent with the change.

On Jul 11, 2016, at 15:13 , Stephen Canon <scanon@apple.com> wrote:

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 <g.c.b.at.work@gmail.com> 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 <swift-evolution@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.

– Steve

Ah, in that case, I agree that putting it into the overlay for Darwin.C (instead of in the stdlib) makes sense.

-Chris

···

On Jul 11, 2016, at 4:00 PM, Stephen Canon <scanon@apple.com> wrote:

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.

I’m not sure what problem you’re trying to solve. I think you agree that people should be able to write a generic function and use “sqrt(x)” where x is some FloatingPoint bound type, right? If so, is it just the concern about it being injected into every program that imports (e.g.) Foundation?

Right, this is only about the concern that it's injected into every program that doesn’t even import anything, under the assumption that folks may push back against doing that for *every* function in a future Math module.

This is a very minor issue, which would only change anything in the short term for most users, and which has already produced more discussion than I thought possible =)