Hi Remy, > I would also like to know why bit shifting and bit-wise and, or and xor > operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable way consistent with the protocol. Wouldn't it?
The problem is that with fixed-width, the values will eventually "fall off the cliff” when shifted left, but with the arbitrary-precision integers we can simply grow the underlying storage so that “the cliff” is never reached. Which means that in generic context, when all you have is some T that conforms to Integer, you won’t be able to tell what will happen exactly. Pretty much the same argument applies to the bitwise operations: since 2 bignums might have different widths of the underlying storage, the semantics of those operations is not exactly the same as for the fixed width types. Does it make sense? Max > On Jun 23, 2016, at 9:08 AM, Remy Demarest via swift-evolution > <[email protected]> wrote: > > I would also like to know why bit shifting and bit-wise and, or and xor > operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable way consistent with the protocol. Wouldn't it? > >> Le 22 juin 2016 à 23:23, Félix Cloutier via swift-evolution >> <[email protected]> a écrit : >> >> Do we lose the ability to create a signed integer from an unsigned bit >> pattern? >> >> Is there a way to get an optional initializer that returns `nil` if the >> operand can't be represented? >> >> What is the cost of heterogeneous comparison? >> >> Félix >> >>> Le 22 juin 2016 à 22:42:00, David Waite via swift-evolution >>> <[email protected]> a écrit : >>> >>> In addition to the technical review, I would like to point out that the >>> definition of Arithmetic appears to be missing some underscores in >>> add/adding/subtract/subtracting >>>> >>>> >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md >>>> >>>> * What is your evaluation of the proposal? >>> >>> I’m so glad this work is being done! >>> >>> For Integer, does the presence of signBit indicate an expectation that >>> signed Integers will have a two's complement representation? >>> >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what >>> situations would you have an overflow? I could only come up with something >>> like Int.min.dividedWithOverflow(-1). >>> >>>> * Is the problem being addressed significant enough to warrant a change >>>> to Swift? >>> >>> Yes, oh yes. >>> >>>> * Does this proposal fit well with the feel and direction of Swift? >>> >>> It looks like a significant improvement. >>> >>>> >>>> * How much effort did you put into your review? A glance, a quick >>>> reading, or an in-depth study? >>> >>> I combed the proposal for questions, although most were answered by the >>> time I hit the end. >>> >>> -DW >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
