[swift-evolution] protocol-oriented integers (take 2)

[Dave Abrahams]

on Mon Jan 16 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Really glad to see this coming back :)
>>
>> I have a couple of questions:
>>
>> 1) How does Strideable relate to Arithmetic?
>>
>> My understanding is that Strideable allows non-numeric types to express
>> different-type addition and subtraction, and that Arithmetic is for numeric
>> types only (derives from ExpressibleByIntegerLiteral) and allows then to
>> express same-type operations. Is that correct?
>
> My understanding was that heterogeneous addition and subtraction using
> operators are not supported not merely due to compiler limitations but as a
> fundamental philosophy, because the type of the intended result can be
> unclear to human readers and unintentional promotion is to be avoided? 

No, not really.  We'd like to introduce a promotion model.

> In that vein, my understanding was that having those operators
> available for Strideable was inconsistent and overdue for removal, and
> `advanced(by:)` is the intended spelling for advancing a value by a
> distance of a different type.

The real reason to remove them from Strideable is that unsigned numbers
are strideable with a signed stride, which made preventing people from
adding signed and unsigned numbers unintentionally messy and unreliable.

>> If so, it would be nice to add it to the proposal so people know when they
>> should conform (or set their generic constraints) to one or the other.
>>
>> 2) Can SignedNumber get some operators now?
>>
>> Strideable.Stride is bound to this weird protocol ‘SignedNumber’. You can
>> create instances of it out of thin air via an integer literal, but you
>> can’t accumulate Strides to find the overall distance between some adjacent
>> Strideables.
>>
>
> I understood these new protocols to mean that SignedNumber is headed for
> deprecation?

That's the plan.

>> Also, #1 is why I don’t like the Strideable operator deprecation being
>> part of the proposal (and therefore part of the language specification). It
>> doesn’t solve the underlying issue, which is that our integer literal
>> protocols aren’t really good enough - they’re not useful enough outside the
>> standard library (see: https://bugs.swift.org/browse/SR-920), and
>> evidently the compiler isn’t able to use them to infer types correctly.
>> Perhaps fixing it is a low priority, and that’s fine, but what about if
>> somebody else defines this operator in their library? They start of break
>> lots of valid code because the compiler can’t do the right thing. Improved
>> literal protocols may be the better way to resolve that problem.
>>
>
> I agree totally that literals are aching for improvements as outlined in
> SR-920. 

Indeedy.

> Not sure how it relates to integer protocols though. What are some
> examples of valid code that get broken today because of compiler
> limitations?
>
>> - Karl
>> _______________________________________________
>> 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
>

-- 
-Dave