> On 20 Jun 2016, at 15:44, Stephen Canon <[email protected]> wrote: > > At some danger of going off on a tangent, I should point out that DEC64 has > very little to recommend it. It’s not much more efficient performance-wise > than IEEE-754 decimal types and has significantly less exponent range (it > effectively throws away almost three bits in order to have the exponent fit > in a byte; 2**56 is ~7.2E16, which means that it can represent some, but not > all, 17-digit significands; the effective working precision is 16 digits, > which actually requires only ~53.15 bits. Even if you weren’t going to use > those extra bits for exponent, they could be profitably used for other > purposes. The fact that the dec-64 scheme allows one to use byte operations > has only a tiny benefit, and really only on x86).
Fair enough, I just thought the idea of a single number type was interesting. As for the proposal, there's a FIXME comment which suggests the original plan: <https://github.com/apple/swift/blob/master/stdlib/public/core/Policy.swift> //===----------------------------------------------------------------------===// // Aliases for floating point types //===----------------------------------------------------------------------===// // FIXME: it should be the other way round, Float = Float32, Double = Float64, // but the type checker loses sugar currently, and ends up displaying 'FloatXX' // in diagnostics. /// A 32-bit floating point type. public typealias Float32 = Float /// A 64-bit floating point type. public typealias Float64 = Double I think CFloat and CDouble are clearer, so Float and Double could be made unavailable: @available(*, unavailable, renamed: "Float32") public typealias Float = Float32 @available(*, unavailable, renamed: "Float64") public typealias Double = Float64 Clang importer already seems to be using the correct names: <https://github.com/apple/swift/blob/master/include/swift/ClangImporter/BuiltinMappedTypes.def> <https://github.com/apple/swift/blob/master/lib/ClangImporter/MappedTypes.def> -- Ben _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
