[swift-evolution] protocol-oriented integers (take 2)
xiaodi.wu at gmail.com
Sun Jan 29 12:36:26 CST 2017
Hmm, interesting. I might be tempted to use a 40-bit type for large arrays,
but the performance hit for any useful computation over a large array would
probably tilt heavily in favor of plain 64-bit integers. What's your use
case for such a 40-bit type? And is it common enough to justify such a
facility in the stdlib vs. providing the tools to build it yourself?
On Sun, Jan 29, 2017 at 12:29 David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:
> On Jan 13, 2017, at 12:47, Max Moiseev via swift-evolution <
> swift-evolution at swift.org> wrote:
> The DoubleWidth<T> type allows to create wider fixed-width integer types
> from the ones available in the standard library.
> Standard library currently provides fixed-width integer types of up to 64
> bits. A value of DoubleWidth<Int64> will double the range of the
> underlying type and implement all the FixedWidthInteger requirements. *Please
> note* though that the implementation will not necessarily be the most
> efficient one, so it would not be a good idea to use DoubleWidth<Int32>instead
> of a built-in Int64.
> What about having a "CompoundBinaryInteger<T,U>" type, and then do
> "typealias DoubleWidth<T> = CompoundBinaryInteger<T,T>"? That would make it
> easier to have, say, 40-bit ints, "CompoundBinaryInteger<Int8,Int32>",
> while still having the convenience of "DoubleWidth<T>".
> - Dave Sweeris
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution