I saw the Sign, and it opened up my mind

There are two changes in this release:

• AlgebraicField now refines SignedNumeric instead of Numeric. This should have no visible change for most users, because all conforming types (Float, Double, Float80, and Complex) already conform to SignedNumeric. However, users who have code that is generic over the AlgebraicField protocol can now use unary negation (or remove existing explicit SignedNumeric constraints from that code).

• The Real and Complex modules have been renamed RealModule and ComplexModule. If you import Numerics, then this change does not affect you. However, if you currently import either Real or Complex directly, you will need to update your import statements. (sorry!)

  This is not a change that I make lightly; I would very much prefer to avoid this sort of churn, even though Swift Numerics hasn't yet declared 1.0. However, there are real limitations of the current name lookup system, which prevents use of some nice patterns when a module name shadows a type.

  E.g. with this change, a user who mostly only wants to work with complex doubles can do the following:

  import ComplexModule
  
  typealias Complex = ComplexModule.Complex<Double>
  
  // Can now use the simpler name Complex for Complex<Double>:
  func foo(_ z: Complex) -> Complex {
    ...
  }
  
  // But can still get at the generic type when necessary:
  let a = ComplexModule.Complex<Float>

  Any Swift Numerics module that might have this ambiguity will be suffixed with Module in the future (just like the pattern of protocols being suffixed with Protocol when necessary to break ambiguity).

As always, if you have any questions or comments, there is a forums thread for discussing this release.