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

[Erica Sadun]

Let me go ahead and do that.

-- E

> On Feb 29, 2016, at 5:03 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> On Feb 29, 2016, at 4:02 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>> 
>>> 
>>> On Feb 29, 2016, at 4:48 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>> 
>>>> On Feb 27, 2016, at 6:54 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>> 
>>>> 
>>>>> On Feb 27, 2016, at 7:30 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 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. 
>>>> 
>>>> How about something like https://gist.github.com/erica/3cd5633b9e139844aa5a <https://gist.github.com/erica/3cd5633b9e139844aa5a>
>>> Functionally that seems reasonable. IMO it wouldn't be a problem to call the Double variant `stride(through:by:)` to match the integer form. Just for fun, you could simplify the condition here:
>>> 
>>>         if stride > 0.0 ? current >= end : current <= end {
>>> 
>>> by using 'if signbit(current - end) == signbit(stride)' instead.
>>> 
>>> -Joe
>>> 
>> 
>> Updated proposal, including code tweak: https://gist.github.com/erica/03c398c06f6c47824429 <https://gist.github.com/erica/03c398c06f6c47824429>  
>> 
>> I get your point, but I'm leaving this as `fstride` right now.  The proposal is *already* breaking several rules of Lattner. It's proposing not one but two distinct changes, which should probably be two separate proposals: "Changing Strideable semantics" and "Decoupling Floating Point Strides from Generic Implementations". If decoupled, I'll recommend keeping stride name consistency. (I kind of recommend it here to, but I'll punch it more.)
>> 
>> I'm about theeeeeeeesclose to separating them into those two proposals, and would like your feedback on that.
> 
> I agree, splitting into two proposals is a good idea.
> 
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160229/f7662687/attachment.html>