On Wednesday, 12 February 2014 at 10:44:57 UTC, Regan Heath wrote:
> Ahh.. so this is a limitation of the range interface.  Any plans to "fix" this?
>
> R

Did my original reply not arrive? It is the first reply in the thread...

Reproduced:

> See this pull request[1] and the linked enhancement report.
>
> Also note that calling `r.popFront()` without checking `r.empty` is a program error (so it's recommended to at least put in an assert).
>
> [1] https://github.com/D-Programming-Language/phobos/pull/1866

On Wednesday, 12 February 2014 at 10:52:13 UTC, Regan Heath wrote:
> On Tue, 11 Feb 2014 19:48:40 -0000, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
>
>> On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
>>> Things like this should "just work"..
>>>
>>> File input ...
>>>
>>> auto range = input.byLine();
>>> while(!range.empty)
>>> {
>>>  range.popFront();
>>>  foreach (i, line; range.take(4))  //Error: cannot infer argument types
>>>  {

> It isn't *required* to (input/forward), but it could (random access).  I think we even have a template to test if it's indexable as we can optimise some algorithms based on this.
>
>> What do you expect 'i' to be? Is it the line number? Is it the index within the line where 'take' begins? Where 'take' stops?
>
> If I say take(5) I expect 0,1,2,3,4.  The index into the take range itself.

I don't see how these two replies can coexist. 'range.take(5)' is a different range from 'range.' 'range may not traverse in index order (personally haven't seen such a range). But more importantly you're not dealing with random access ranges. The index you're receiving from take(5) can't be used on the range.

Don't get me wrong, counting the elements as you iterate over them is useful, but it isn't the index into the range you're likely after. Maybe the number is needed to correspond to a line number.

>> There is a feature of foreach and tuple() which results in the tuple getting expanded automatically.
>
> And also the opApply overload taking a delegate with both parameters.

I'm trying to stick with ranges and not iteration in general.

On Wed, 12 Feb 2014 11:08:57 -0000, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Wednesday, 12 February 2014 at 10:44:57 UTC, Regan Heath wrote:
>> Ahh.. so this is a limitation of the range interface.  Any plans to "fix" this?
>>
>> R
>
> Did my original reply not arrive? It is the first reply in the thread...

It did, thanks.  It would be better if this was part of the language and "just worked" as expected, but this is just about as good.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 12 Feb 2014 21:01:58 -0000, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:

> On Wednesday, 12 February 2014 at 10:52:13 UTC, Regan Heath wrote:
>> On Tue, 11 Feb 2014 19:48:40 -0000, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
>>
>>> On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
>>>> Things like this should "just work"..
>>>>
>>>> File input ...
>>>>
>>>> auto range = input.byLine();
>>>> while(!range.empty)
>>>> {
>>>>  range.popFront();
>>>>  foreach (i, line; range.take(4))  //Error: cannot infer argument types
>>>>  {
>
>> It isn't *required* to (input/forward), but it could (random access).  I think we even have a template to test if it's indexable as we can optimise some algorithms based on this.

You chopped of your own comment prompting this response, in which I am responding to a minor side-point, which I think has confused the actual issue.  All I was saying above was that a range might well have an index, and we can test for that, but it's not relevant to the foreach issue below.

>>> What do you expect 'i' to be? Is it the line number? Is it the index within the line where 'take' begins? Where 'take' stops?
>>
>> If I say take(5) I expect 0,1,2,3,4.  The index into the take range itself.
>
> I don't see how these two replies can coexist. 'range.take(5)' is a different range from 'range.'

Yes, exactly, meaning that it can trivially "count" the items it returns, starting from 0, and give those to me as 'i'.  *That's all I want*

> 'range may not traverse in index order (personally haven't seen such a range). But more importantly you're not dealing with random access ranges. The index you're receiving from take(5) can't be used on the range.

A forward range can do what I am describing above, it's trivial.

> Don't get me wrong, counting the elements as you iterate over them is useful, but it isn't the index into the range you're likely after.

Nope, not what I am after.  If I was, I'd iterate over the original range instead or keep a line count manually.

> Maybe the number is needed to correspond to a line number.

Nope.  The file contains records of 5 lines plus a blank line.  I want 0, 1, 2, 3, 4, 5 so I can skip lines 0, 2, and 5 *of each record*.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thursday, 13 February 2014 at 14:30:41 UTC, Regan Heath wrote:
>> Don't get me wrong, counting the elements as you iterate over them is useful, but it isn't the index into the range you're likely after.
>
> Nope, not what I am after.  If I was, I'd iterate over the original range instead or keep a line count manually.

Maybe a better way to phrase this is, while counting may be what you're implementation needs, it is not immediately obvious what 'i' should be. Someone who desires an index into the original array will expect 'i' to be that; even though it can be explained that .take() is not the same range as the original.

Thus it is better to be explicit with the .enumerate function.

On Fri, 14 Feb 2014 02:48:51 -0000, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:

> On Thursday, 13 February 2014 at 14:30:41 UTC, Regan Heath wrote:
>>> Don't get me wrong, counting the elements as you iterate over them is useful, but it isn't the index into the range you're likely after.
>>
>> Nope, not what I am after.  If I was, I'd iterate over the original range instead or keep a line count manually.
>
> Maybe a better way to phrase this is, while counting may be what you're implementation needs, it is not immediately obvious what 'i' should be. Someone who desires an index into the original array will expect 'i' to be that; even though it can be explained that .take() is not the same range as the original.
>
> Thus it is better to be explicit with the .enumerate function.

FWIW I disagree.  I think it's immediately and intuitively obvious what 'i' should be when you're foreaching over X items taken from another range, even if you do not know take returns another range.  Compare it to calling a function on a range and foreaching on the result, you would intuitively and immediately expect 'i' to relate to the result, not the input.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 14 February 2014 at 12:10:51 UTC, Regan Heath wrote:
> FWIW I disagree.  I think it's immediately and intuitively obvious what 'i' should be when you're foreaching over X items taken from another range, even if you do not know take returns another range.  Compare it to calling a function on a range and foreaching on the result, you would intuitively and immediately expect 'i' to relate to the result, not the input.
>
> R

How should it behave on ranges without length, such as infinite ranges?

Also, `enumerate` has the advantage of the `start` parameter, which usefulness is demonstrated in `enumerate`'s example as well as in an additional example in the bug report.

I'm not yet sure whether I think it should be implemented at the language or library level, but I think the library approach has some advantages.

Regan Heath:

> FWIW I disagree.  I think it's immediately and intuitively obvious what 'i' should be when you're foreaching over X items taken from another range, even if you do not know take returns another range.  Compare it to calling a function on a range and foreaching on the result, you would intuitively and immediately expect 'i' to relate to the result, not the input.

Using enumerate has several advantages. It gives a bit longer code, but it keeps as much complexity as possible out of the language. So the language gets simpler to implement and its compiler is smaller and simpler to debug.

Also, using enumerate is more explicit, if you have an associative array you can iterate it in many ways:

foreach (v; AA) {}
foreach (k, v; AA) {}
foreach (k; AA.byKeys) {}
foreach (i, k; AA.byKeys.enumerate) {}
foreach (i, v; AA.byValues.enumerate) {}
foreach (k, v; AA.byPairs) {}
foreach (i, k, v; AA.byPairs.enumerate) {}

If you want all those schemes built in a language (and to use them without adding .enumerate) you risk making a mess. In this case "explicit is better than implicit".

Python does the same with its enumerate function and keeps the for loop simple:

for k in my_dict: pass
for i, v in enumerate(my_dict.itervalues()): pass
etc.

In D we have a mess because tuples are not built-in. Instead of having a built-in functionality similar to what enumerate does, it's WAY better to have built-in tuples. Finding what's important and what is not important to have as built-ins in a language is an essential and subtle design problem.

Bye,
bearophile

On Fri, 14 Feb 2014 12:29:49 -0000, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Friday, 14 February 2014 at 12:10:51 UTC, Regan Heath wrote:
>> FWIW I disagree.  I think it's immediately and intuitively obvious what 'i' should be when you're foreaching over X items taken from another range, even if you do not know take returns another range.  Compare it to calling a function on a range and foreaching on the result, you would intuitively and immediately expect 'i' to relate to the result, not the input.
>>
>> R
>
> How should it behave on ranges without length, such as infinite ranges?

In exactly the same way.  It just counts up until you break out of the foreach, or the 'i' value wraps around.  In fact the behaviour I want is so trivial I think it could be provided by foreach itself, for iterations of anything.  In which case whether 'i' was conceptually an "index" or simply a "count" would depend on whether the range passed to foreach (after all skip, take, etc) was itself indexable.

> Also, `enumerate` has the advantage of the `start` parameter, which usefulness is demonstrated in `enumerate`'s example as well as in an additional example in the bug report.

Sure, if you need more functionality reach for enumerate.  We can have both;  sensible default behaviour AND enumerate for more complicated cases.  In my case, enumerate w/ start wouldn't have helped (my file was blocks of 6 lines, where I wanted to skip lines 1, 3, and 6 *of each block*)

> I'm not yet sure whether I think it should be implemented at the language or library level, but I think the library approach has some advantages.

Certainly, for the more complex usage.  But I reckon we want both enumerate and a simple language solution which would do what I've been trying to describe.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Fri, 14 Feb 2014 13:14:51 -0000, bearophile <bearophileHUGS@lycos.com> wrote:

> Regan Heath:
>
>> FWIW I disagree.  I think it's immediately and intuitively obvious what 'i' should be when you're foreaching over X items taken from another range, even if you do not know take returns another range.  Compare it to calling a function on a range and foreaching on the result, you would intuitively and immediately expect 'i' to relate to the result, not the input.
>
> Using enumerate has several advantages.

In my case I didn't need any of these.  Simple things should be simple and intuitive to write.  Yes, we want enumerate *as well* especially for the more complex cases but we also want the basics to be simple, intuitive and easy.

That's all I'm saying here.  This seems to me to be very low hanging fruit.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/