No I would not be surprised by a limit based on Int provided that:<div><br></div><div>  1. It was articulated in the documentation</div><div>  2. The error occurred when the Range/stride was created</div><div>  3. The error message stated that there were too many steps and what the step limit was</div><div><br></div><div>What I don&#39;t think would be acceptable was if:</div><div><br></div><div>  1. The error occurred part way through the iteration; not at creation time</div><div>  2. There was no error and the loop turned into an infinite loop silently<br><br>On Friday, 1 April 2016, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All true. I call that Erica&#39;s solution because her proposal is where I first found it sketched out.<br><br>I&#39;m not convinced that Erica&#39;s solution is definitely the right answer because:<br><br>(a) Use of an iteration counter of type Int to stride through Doubles is an implementation detail which is not an obviously correct choice; users might find it surprising that how many steps they get for StrideTo&lt;Double&gt; is constrained by Int.max<br><br>(b) I&#39;m not completely certain that there is no use case for a loop with more than Int.max steps so long as you break before the end, so I&#39;m not completely certain that an error right off the bat is the most ideal behavior; for example, someone may wish to increment by a user-supplied epsilon from one user-supplied value to another but break after a certain amount of time has elapsed<br><br>(c) I agree with you that it&#39;s Swiftier to do nothing than to start returning approximately correct values, but in a scenario such as `for _ in stride(from: 0, to: DBL_MAX, by: someAbsurdlySmallValue) { }` it may not matter (I cannot imagine a use case for this ridiculous loop, but for the sake of argument here let&#39;s take it); one alternative solution someone might propose, for example, would be to fall back to the old error-accumulating algorithm after the iteration counter has reached its max possible value<br><br>So I guess the feedback I&#39;m interested in is:<br><br>- Would you be surprised to find that Stride&lt;Double&gt; may become constrained by an upper limit in the number of steps?<br><br>- If not, would it irk you that such a limit is based on the size of a totally unrelated numeric type (namely, Int) which is an implementation detail? Would you prefer that the limit be something related to the nature of the type itself (for example, a maximum number of steps for StrideTo&lt;Double&gt; that reflects the maximum exactly representable integer in a Double)?<br><br>- If there is to be an upper limit on steps, would you prefer an error when the Stride is being initialized or when the iteration counter overflows?<br><br>- Would you rather instead be able to stride indefinitely, as is currently the case in Swift 2, accepting that error will start accumulating at some point?<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 31, 2016 at 4:33 PM Howard Lovatt via swift-evolution &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you define a range as range[i] = first + i * stride where i is an Int then this generates an error when there are more than Int_Max steps, see code previously posted. The error is generated when the range is formed, which is ideal since an error part way along an iteration or a never ending iteration would be difficult to track down. <br><br>On Friday, 1 April 2016, Stephen Canon via swift-evolution &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution &lt;<a>swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote:<br>
&gt;&gt;<br>
&gt;&gt; on Thu Mar 31 2016, Xiaodi Wu &lt;<a href="http://xiaodi.wu-AT-gmail.com" target="_blank">xiaodi.wu-AT-gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Thoughts on an edge case: so long as it&#39;s possible to use<br>
&gt;&gt;&gt; `stride(from:to:by:)` with Double, we&#39;ll need to figure out what<br>
&gt;&gt;&gt; happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.<br>
&gt;&gt;&gt; Bounds may be unknown at compile time, obviously.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Currently (this is by reasoning through the code, not actually<br>
&gt;&gt;&gt; observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:<br>
&gt;&gt;&gt; DBL_MIN) { }` degenerates into an infinite loop once you reach<br>
&gt;&gt;&gt; sufficient large values such that `current + stride == current`, which<br>
&gt;&gt;&gt; for a stride of DBL_MIN should happen pretty quickly.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In Erica&#39;s proposed floating point Stride, an Int is used to count<br>
&gt;&gt;&gt; iterations (and iterations need to be counted in order to avoid<br>
&gt;&gt;&gt; accumulating error). Thus, one must break from `for i in stride(from:<br>
&gt;&gt;&gt; 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter<br>
&gt;&gt;&gt; overflows or it will trap. IMO, trapping at some point is fine, but I<br>
&gt;&gt;&gt; think a limit of Int.max iterations might be rather arbitrary for a<br>
&gt;&gt;&gt; StrideTo&lt;Double&gt; (or whatever it will be named) and I&#39;m not sure how<br>
&gt;&gt;&gt; one can justify why the behavior of StrideTo&lt;Double&gt; would change from<br>
&gt;&gt;&gt; machine to machine based on the size of Int.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;ve been waffling between using an Int counter as Erica does or a<br>
&gt;&gt;&gt; counter of type Strideable.Stride in `StrideTo&lt;Strideable where<br>
&gt;&gt;&gt; Strideable.Stride : FloatingPoint&gt;`. In the latter alternative, no<br>
&gt;&gt;&gt; trapping occurs, but error begins to accumulate when the iteration<br>
&gt;&gt;&gt; counter is too large to represent integers exactly (e.g., 2^53 for<br>
&gt;&gt;&gt; Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by:<br>
&gt;&gt;&gt; DBL_MIN) { }` degenerates into an infinite loop eventually (once<br>
&gt;&gt;&gt; `iterationCount + 1.0 == iterationCount`) and never traps, which I&#39;m<br>
&gt;&gt;&gt; not sure I like, but a limit of 2^53 iterations bears at least a<br>
&gt;&gt;&gt; rational connection to Double and is known at compile time independent<br>
&gt;&gt;&gt; of the supplied bounds. We could alternatively return nil on reaching<br>
&gt;&gt;&gt; 2^53 iterations, trap, etc.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Comments?<br>
&gt;&gt;<br>
&gt;&gt; I think I want to hear Steve Canon&#39;s input on this one.  I defer to him<br>
&gt;&gt; on most things numeric.<br>
&gt;<br>
&gt; In particular, should Steve confirm that the IEEE754 Decimal128 format<br>
&gt; is being worked on, and if simple decimal constants like those in<br>
&gt;       `for i in stride(from: 0.0, to: DBL_MAX, by: DBL_MIN) { }`<br>
&gt; will be type-inferred as Decimal128, all that would &quot;just work&quot;.<br>
<br>
Decimal is something that I would like to see happen.  However, I would not expect any such proposal to result in that loop being type inferred to Decimal, since the to: and by: values are explicitly (binary floating-point) Doubles.<br>
<br>
I also don’t think that such a loop is particularly useful.  For floating-point types, something like stride(from: T, to: T, steps: Int) seems safer and more workable to me (this is just my immediate reaction, I haven’t thought this through in detail, and am likely to change my mind if someone makes a good case).<br>
<br>
– Steve<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br>-- <br>-- Howard.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</blockquote></div><br><br>-- <br>-- Howard.<br>