[swift-evolution] [Discussion] Arbitrary precision integer and float literal protocols

[Brent Royal-Gordon]

> On Apr 2, 2017, at 11:19 PM, David Hart <david at hartbit.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/d76d3e28/attachment.html>