[swift-evolution] “Integer” protocol?

[Kelvin Ma]

On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> On Wed, Nov 1, 2017 at 07:24 Daryle Walker <darylew at mac.com> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> Right, these issues were discussed when the proposal was introduced and
>> reviewed three times. In brief, what was once proposed as `Integer` was
>> renamed `BinaryInteger` to avoid confusion in name between `Integer` and
>> `Int`. It was also found to better reflect the semantics of the protocol,
>> as certain functions treated the value not merely as an integer but
>> operated specifically on its binary representation (for instance, the
>> bitwise operators).
>>
>> Do not confuse integers from their representation. Integers have no
>> intrinsic radix and all integers have a binary representation. This is
>> distinct from floating-point protocols, because many real values
>> representable exactly as a decimal floating-point value cannot be
>> represented exactly as a binary floating-point value.
>>
>>
>> Abstractly, integers have representations in nearly all real radixes. But
>> mandating base-2 properties for a numeric type that uses something else
>> (ternary, negadecimal, non-radix, etc.) in its storage is definitely
>> non-trivial. Hence the request for intermediate protocols that peel off the
>> binary requirements.
>>
>
> Not only binary properties, but specifically two’s-complement binary
> properties. You are correct that some operations require thought for
> implementation if your type uses ternary storage, or for any type that does
> not specifically use two’s-complement representation internally, but having
> actually implemented them I can assure you it is not difficult to do
> correctly without even a CS degree.
>
> Again, one must distinguish between the actual representation in storage
> and semantics, which is what Swift protocols guarantee. The protocols are
> totally agnostic to the internal storage representation. The trade-off for
> supporting ternary _semantics_ is an additional set of protocols which
> complicates understanding and use in generic algorithms. I am not aware of
> tritwise operations being sufficiently in demand.
>

Before everyone gets carried away with these protocols, can I ask what the
real use case for ternary integers is? Also I’m not a fan of bikeshedding
protocols for things that don’t exist (yet).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171101/b269b402/attachment.html>