> On Apr 2, 2017, at 11:19 PM, David Hart <[email protected]> wrote:
>
> Any reason we need to burden ourselves with the two's complement
> representation?
The `words` collection and its two's-complement representation come straight
out of the `BinaryInteger` protocol; all integer types already "speak" in
variable-length two's-complement words. So having our literal protocol also
speak the same language seems like a good way to leverage code that's already
in the standard library. Besides, I can't think of a better universal
format—the world has largely settled on two's complement for signed integers.
>> (There are a few similar approaches we could take, like exposing an
>> `init(words:)` constructor in `BinaryInteger` and having the
>> `IntegerLiteral` behave as a `Words` collection, but all of them basically
>> involve bootstrapping into `BinaryInteger` through the `Words` type.)
>>
>> I *think* that the not-yet-implemented `BinaryFloatingPoint.init<Source:
>> BinaryFloatingPoint>(_ value: Source)` initializers could be leveraged in a
>> similar way—create a `BinaryFloatingPointSource` protocol and a
>> `BinaryFloatLiteral` type that conforms to it—but I'm less certain of that
>> because I don't really understand how this universal float conversion is
>> supposed to work. Plus, the universal float conversion is still just a TODO
>> comment right now.
>
> What do you mean by the universal float conversion?
SE-0067 includes these `BinaryFloatingPoint` members which aren't in Swift yet:
// NOTE:
--------------------------------------------------------------------
// The next two APIs are not implementable without a revised integer
// protocol. Nonetheless, I believe that it makes sense to consider
them
// with the rest of this proposal, with the understanding that they
will
// be implemented when it becomes possible to do so.
/// `value` rounded to the closest representable value.
init<Source: BinaryFloatingPoint>(_ value: Source)
/// Fails if `value` cannot be represented exactly as `Self`.
init?<Source: BinaryFloatingPoint>(exactly value: Source)
//
--------------------------------------------------------------------------
These are what I refer to as "universal float conversion": they allow you to
convert from any `BinaryFloatingPoint` type to any other `BinaryFloatingPoint`
type, even if the two types aren't aware of each other's existence.
In principle, I believe we could do something similar to what I proposed for
`BinaryInteger`: extract a `BinaryFloatingPointSource` super-protocol from
`BinaryFloatingPoint` containing the members these initializers rely upon,
modify these initializers to constrain their parameter to that new protocol,
and use that to make a `BinaryFloatingPointLiteral` type. However, since these
calls have not been implemented yet and I don't know which parts of
`BinaryFloatingPoint` they're supposed to use, I can't really give a design for
that.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
