on Mon Jan 16 2017, Xiaodi Wu <swift-evolution@swift.org> wrote: > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < > swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution