[swift-evolution] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution