[Accepted with Modifications] SE-0246: Generic Math Functions

[xwu (Xiaodi Wu)]

@scanon

The only exception to that is sqrt , because the generic constraint for the free function changes from FloatingPoint to Real .

Huh. Why did we make this change? Ah, you mean ElementaryFunctions.

[Coeur (Antoine Cœur)]

Talking about naming, I would have preferred squareRoot over sqrt. With an IDE like Xcode, tapping s-q-r-t would still allow auto-completion to the readable form of squareRoot.

With those old C names like sqrt, you can't tell if it's a mutable or non-mutable function, and you wouldn't know how to name the counterpart. Are we going to have a formSqrt for instance as a mutable version of the same function?

[scanon (Steve Canon)]

@Coeur

With those old C names like sqrt , you can't tell if it's a mutable or non-mutable function, and you wouldn't know how to name the counterpart. Are we going to have a formSqrt for instance as a mutable version of the same function?

For free functions, there are no mutating variants, so this isn't an issue. For the implementation hooks (statics), there is again no way to have a mutating version. I.e., these new operations appear either as sqrt(x) or Float.sqrt(x). There's no way either of those can be mutating, so no confusion is possible.

Even the existing method x.formSquareRoot( ) was probably ill-considered because it doesn't offer any efficiency wins, but everyone was quite gung-ho about testing out the edges of the naming conventions at that point. It's a vestigial curiosity now that we might deprecate at some future point.

[Bjoern (Björn)]

Hi all,
is there any update what happened to the SE-0246: Generic Math Functions proposal?

[scanon (Steve Canon)]

Yes. There are some issues that were exposed with type checker performance and source stability that caused us to move it out of 5.1. Specifically:

• we cannot easily eliminate the existing concrete functions in the Glibc/Darwin/etc modules because of source and binary stability concerns. These have the same names as many of the new functions, which causes some type checker regressions. Most of these regressions are small, but there are some bad cases that we haven't have time to address yet.

• there's a type checker bug involving overload resolution; static member functions are always preferred to free functions, which means that existing code like:

  extension Double {
    func foo() -> Double {
      log10(self)
    }
  }
  

  would fail to compile (because the static log10 cannot be used without calling it as Double.log10, but is still preferred in name lookup, so the type checker doesn't find the existing free function). This is a bug, but we can't land the change until it is fixed, and we didn't have time to do so for 5.1.

Once we get the necessary type checker improvements to unblock these changes, I'll re-propose them.

[Ben_Cohen]

Core Team Update on SE-0246

Hi everyone – this proposal remains accepted, but is currently not implemented in the Swift standard library due to potential source-breaking changes that require improvements to the typechecker to avoid, as described above by @scanon

In the mean-time, users looking for this functionality can consider using the recently released Swift Numerics package, which contains the same code within its Real module.

[Bjoern (Björn)]

Hi all,
is SE-0246 on the plate to be released in Swift 5.5?

[scanon (Steve Canon)]

No, we will run it through evolution again before landing it in the standard library (also we haven’t resolved all the typechecker difficulties yet). Please use Swift numerics for these APIs.

[slyvek (Sylwester Los)]

Hi

Im my opinion the SE-0246 is one of the most important part of the Swift that is still not added to the standard library. Can anybody estimate when it may be published?

[YOCKOW]

Nothing seems to have been changed since this post.

---

FYI...

A quote from Addressing unimplemented evolution proposals:

@Ben_Cohen

SE-0220 and SE-0246 are both unimplemented due to their impact on type checker performance. These could be reproposed once the type checker issues are addressed. Note that the full implementation of SE-0246 is available via the Numerics package .

A quote from swift-numerics/Sources/RealModule/README.md:

SE-0246 proposed an API for "basic math functions" that would make operations like sine and logarithm available in generic contexts. It was accepted, but because of limitations in the compiler, the API could not be added to the standard library in a source-stable manner. RealModule provides that API as a separate module so that you can use it right away to get access to the improved API for these operations in your projects.