There are two changes in this release:
-
AlgebraicFieldnow refinesSignedNumericinstead ofNumeric. This should have no visible change for most users, because all conforming types (Float,Double,Float80, andComplex) already conform toSignedNumeric. However, users who have code that is generic over theAlgebraicFieldprotocol can now use unary negation (or remove existing explicitSignedNumericconstraints from that code). -
The
RealandComplexmodules have been renamedRealModuleandComplexModule. If you importNumerics, then this change does not affect you. However, if you currently import eitherRealorComplexdirectly, 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
Modulein the future (just like the pattern of protocols being suffixed withProtocolwhen necessary to break ambiguity).