[swift-evolution] [Discussion] stride behavior and a little bit of a call-back to digital numbers

Joe Groff jgroff at apple.com
Sat Feb 27 20:30:33 CST 2016


Erica Sadun via swift-evolution
<swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Feb 27, 2016, at 6:28 PM, Joe Groff via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> Erica Sadun via swift-evolution
>> <swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>> wrote:
>>> If you were addressing issue 2, what approach would you suggest:
>>> 
>>> * Differentiating integer strides from floating point, and minimizing
>>> floating point errors?
>>> * Leaving the tech as-is with minimal code
>>> change with a relatively high benefit?
>> 
>> Arguably, floating point types shouldn't conform to Strideable at all, on
>> the general principle that genericizing arithmetic over ints and floats is
>> a trap. That would free floating point types to provide their own
>> specialized implementation of the stride methods. 
>> 
> 
> 
> As if I don't already get enough grief from the C-for-loop people, now this? They'll be 
> burning semicolons on my front lawn at this rate. (And let me mention again that this
> problem affects C-for-loop just as much as it does strides.)

Forloopians probably don't care whether Float is Strideable, as long as it
has working stride methods. If those methods are better than what they'd
write naively, well, that's even better justification for taking the C loop
away. 

> 
>>> In both cases, I'd still prefer the semantics to *go through* the end
>>> point, not just stop at it, which is issue 1.
>> 
>> I'll have to defer to domain experts on this one. It seems superficially
>> appealing at least. If your only motivation is to get 1.0 through 2.0 by
>> 0.1 to include 2.0, though, that feels like weak justification to me, since
>> that's a symptom of a different problem. 
> 
> This sounds like it reduces to the following:
> 
> 1. Leave as is, broken, requiring workarounds for nearly all floating point cases
> 
> 2. Leave as is but remove floating point stride support, tick off
> forloopians. Introduce floating point stride-alike,
> which isn't terribly difficult but will need a different something since
> `Stride` is built on `SignedNumberType`.
> 
> 3. (This) Introduce a fix to make floating point less sucky and integers
> more semantically fitting, with
> minimal code change. Issue FIXME warnings during migration to warn
> against changed semantics.
> 
> 4. Do something else. Magic happens. Profit.
> 
> -- E
> 






More information about the swift-evolution mailing list