There are two changes in this release:
-
AlgebraicField
now refinesSignedNumeric
instead 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 theAlgebraicField
protocol can now use unary negation (or remove existing explicitSignedNumeric
constraints from that code). -
The
Real
andComplex
modules have been renamedRealModule
andComplexModule
. If you importNumerics
, then this change does not affect you. However, if you currently import eitherReal
orComplex
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 withProtocol
when necessary to break ambiguity).