On 10/18/2014 9:16 AM, Sean Kelly wrote:
>  But dismissing ranges out of hand for not being sufficiently
> "powerful and foundational" is just silly.

I agree. It's like "foreach" in D. It's less powerful and foundational than a "for" loop (in fact, the compiler internally rewrites foreach into for), but that takes nothing away from how darned useful (and far less bug prone) foreach is.

Also, the glue layer rewrites "for" loops into "goto" loops, as gotos are more powerful and foundational :-)

On 10/18/2014 8:17 AM, Andrei Alexandrescu wrote:
> On 10/18/14, 4:43 AM, John Colvin wrote:
>> auto kahanSum(R)(R input)
>> {
>>      double sum = 0.0;
>>      double c = 0.0;
>>      foreach(double el; input)
>>      {
>>          double y = el - c;
>>          double t = sum + y;
>>          c = (t - sum) - y;
>>          sum = t;
>>      }
>>      return sum;
>> }
>
> No need to implement it. http://dlang.org/phobos/std_algorithm.html#.sum

Wow, I hadn't noticed that before. Sweet!

On Saturday, 18 October 2014 at 17:31:18 UTC, Walter Bright wrote:
> I agree. It's like "foreach" in D. It's less powerful and foundational than a "for" loop (in fact, the compiler internally rewrites foreach into for), but that takes nothing away from how darned useful (and far less bug prone) foreach is.

Actually, there are quite a few bugs related to modifying values and/or indexes in a foreach loop. In particular, foreach allows "ref" iteration over ranges that don't give ref access...

All that said, after a quick scan I really like the range proposal for C++. In particular, the idea of positions is a nice one, as it addresses an awkward issue with D ranges.

Zhu and Hayes (2010) «Algorithm 908: Online Exact Summation of Floating-Point Streams» is compatible with ranges and looks interesting:

http://s3.amazonaws.com/researchcompendia_prod/articles/990d22f230c4b4eb7796f0ed45b209eb-2013-12-23-01-53-27/a37-zhu.pdf

On 10/18/2014 10:37 AM, monarch_dodra wrote:
> On Saturday, 18 October 2014 at 17:31:18 UTC, Walter Bright wrote:
>> I agree. It's like "foreach" in D. It's less powerful and foundational than a
>> "for" loop (in fact, the compiler internally rewrites foreach into for), but
>> that takes nothing away from how darned useful (and far less bug prone)
>> foreach is.
>
> Actually, there are quite a few bugs related to modifying values and/or indexes
> in a foreach loop. In particular, foreach allows "ref" iteration over ranges
> that don't give ref access...

All bugs should be reported to bugzilla.

I still argue that foreach is far less bug prone than for loops.

On Saturday, 18 October 2014 at 16:16:17 UTC, Sean Kelly wrote:
> gets my point across.  It's always possible to reduce a library interface to something that's even more stripped-down, which is by definition more powerful and foundational.  But if the user never wants to work at that low level of abstraction then you're just imposing an unnecessary burden upon them.

Anything that you can do with an iterator can be done with a tail recursive function, but not vice versa, which means iterators serve no purpose.

On Sunday, 19 October 2014 at 11:56:10 UTC, bachmeier wrote:
> Anything that you can do with an iterator can be done with a tail recursive function, but not vice versa, which means iterators serve no purpose.

I guess that comment was ironic, but end-begin kind of disproves it :-).

I kind of like the concept of "cursors" in databases, where you can pin-point a position in a query result and continue even after the table has changed.

For a linked list it is is easy to get "cursor semantics". Not so easy for arrays, but it should be possible to define "cursor enabled containers" with appropriate locking.

On 10/18/2014 07:30 PM, Walter Bright wrote:
>
> Also, the glue layer rewrites "for" loops into "goto" loops, as gotos
> are more powerful and foundational :-)

Well, not really. It rewrites "for" loops into "goto" loops because that's the only control flow construct implemented by the hardware.

"Timon Gehr"  wrote in message news:m23eqa$2qfq$1@digitalmars.com... 

> On 10/18/2014 07:30 PM, Walter Bright wrote:
> >
> > Also, the glue layer rewrites "for" loops into "goto" loops, as gotos
> > are more powerful and foundational :-)
> 
> Well, not really. It rewrites "for" loops into "goto" loops because that's the only control flow construct implemented by the hardware.

You might be thinking of the code generator, not the glue layer.