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

[Curt Clifton]

Looks good!

Cheers,

Curt


> On Feb 28, 2016, at 9:18 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> Reload and check please. https://gist.github.com/erica/03c398c06f6c47824429
> 
> -- E
> 
>> On Feb 28, 2016, at 9:55 AM, Curt Clifton <curt at omnigroup.com> wrote:
>> 
>> 
>> 
>> 
>> Cheers,
>> 
>> Curt
>> 
>> On Feb 27, 2016, at 10:03 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> I've updated the proposal to take this into account: https://gist.github.com/erica/03c398c06f6c47824429
>>> 
>>> It makes two core recommendations:
>>> 
>>> 1. Adjust stride function semantics to expand from two to three functions, renaming them appropriately.
>>> 2. Break floating point strides away from Strideable to provide their own stride method implementations.
>> 
>> I don't have a strong opinion on the proposal. These sorts of strides are rare in the problem domains I work in. I would like to nitpick the proposed documentation for the new stride(through:,by:). The revised proposal gives the new documentation as:
>> 
>> A Strideable through sequence currently returns the sequence of values (self, self + stride, self + stride + stride, ... last) where last is the last value in the progression greater than or equal to end. There is no guarantee that end is an element of the sequence.
>> 
>> 
>> That should read “where last is the **first** value in the progression that is greater than or  equal to end.“ As proposed, last would be the largest number representable in self’s type that is a multiple of stride greater than self. That’s not the intent.
>> 
>> Cheers, 
>> 
>> Curt
>> 
>> -------------------------
>> Curt Clifton, PhD 
>> Software Developer 
>> The Omni Group 
>> www.curtclifton.net 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/6cf0a97a/attachment.html>