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

[Xiaodi Wu]

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? 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.


> 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?


> 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. 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170116/642ab9ea/attachment.html>