Re: foreach range with index

On 6/14/17 6:02 PM, Ali Çehreli wrote: On 06/14/2017 12:22 PM, Steven Schveighoffer wrote: foreach(i, v; hashmap) => i is counter, v is value Later hashmap adds support for iterating key and value. Now i is key, v is value. Code means something completely different. Compare with foreach(i,

Re: foreach range with index

On 6/14/17 6:46 PM, Luís Marques wrote: On Wednesday, 14 June 2017 at 19:22:24 UTC, Steven Schveighoffer wrote: For example: foreach(i, v; hashmap) => i is counter, v is value Later hashmap adds support for iterating key and value. Now i is key, v is value. Code means something completely

Re: foreach range with index

On 06/14/2017 03:48 PM, bachmeier wrote: On Wednesday, 14 June 2017 at 22:02:30 UTC, Ali Çehreli wrote: Then, perhaps we're arguing in favor of * writing .enumerate even for slices (implying that automatic indexing for them has been a historical artifact and code that wants to be portable

Re: foreach range with index

On Wednesday, 14 June 2017 at 22:02:30 UTC, Ali Çehreli wrote: Then, perhaps we're arguing in favor of * writing .enumerate even for slices (implying that automatic indexing for them has been a historical artifact and code that wants to be portable should always write .enumerate) * making

Re: foreach range with index

On Wednesday, 14 June 2017 at 19:22:24 UTC, Steven Schveighoffer wrote: For example: foreach(i, v; hashmap) => i is counter, v is value Later hashmap adds support for iterating key and value. Now i is key, v is value. Code means something completely different. If we take a step back, I

Re: foreach range with index

On 06/14/2017 12:22 PM, Steven Schveighoffer wrote: > foreach(i, v; hashmap) => i is counter, v is value > > Later hashmap adds support for iterating key and value. Now i is key, v > is value. Code means something completely different. > > Compare with > > foreach(i, v; hashmap.enumerate) > >

Re: foreach range with index

On 6/14/17 12:35 PM, Luís Marques wrote: On Wednesday, 14 June 2017 at 16:17:50 UTC, Steven Schveighoffer wrote: I don't know if there is room to allow range-defined indexes and foreach-defined indexes. foreach(a, b; someRange) has to do one or the other. Otherwise, changes to how someRange

Re: foreach range with index

On Wednesday, 14 June 2017 at 16:17:50 UTC, Steven Schveighoffer wrote: I think opApply is kind of a forgotten piece of the language since ranges have been introduced. We could resurrect it quite easily this way, as opApply with template parameters that return another range does not conflict

Re: foreach range with index

On 6/14/17 11:42 AM, Luís Marques wrote: On Wednesday, 14 June 2017 at 14:35:32 UTC, Steven Schveighoffer wrote: What I'd rather see is a better mechanism for ranges (or things that provide ranges) to hook the foreach syntax to allow better control and power from ranges without using

Re: foreach range with index

On Wednesday, 14 June 2017 at 14:35:32 UTC, Steven Schveighoffer wrote: What I'd rather see is a better mechanism for ranges (or things that provide ranges) to hook the foreach syntax to allow better control and power from ranges without using traditional opApply. For example, if we had:

Re: foreach range with index

On 6/13/17 10:42 PM, Luís Marques wrote: On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer wrote: But I think leaving the definition of the index up to the range itself is paramount -- I don't want every range to be able to have a size_t index, as that's not always what you want,

Re: foreach range with index

On Wednesday, 14 June 2017 at 03:06:26 UTC, Luís Marques wrote: On Wednesday, 14 June 2017 at 02:54:30 UTC, 9il wrote: Random access iteration is more expensive then front/popFront in general case. For arrays it is not true. But for many other kinds of ranges it is. For example ranges that do

Re: foreach range with index

On Wednesday, 14 June 2017 at 02:54:30 UTC, 9il wrote: Random access iteration is more expensive then front/popFront in general case. For arrays it is not true. But for many other kinds of ranges it is. For example ranges that do not have contiguous memory representation (strided vectors,

Re: foreach range with index

On Wednesday, 14 June 2017 at 02:48:34 UTC, Luís Marques wrote: Hmm, I suppose that even if we have all of the good stuff of length, opIndex, opSlice, etc., we can't assume the indices are [0..length], right? But there should be some way for, say, map to preserve that information from the

Re: foreach range with index

On Wednesday, 14 June 2017 at 02:42:46 UTC, Luís Marques wrote: On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer wrote: But I think leaving the definition of the index up to the range itself is paramount -- I don't want every range to be able to have a size_t index, as that's not

Re: foreach range with index

On Wednesday, 14 June 2017 at 02:42:46 UTC, Luís Marques wrote: On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer wrote: But I think leaving the definition of the index up to the range itself is paramount -- I don't want every range to be able to have a size_t index, as that's not

Re: foreach range with index

On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer wrote: But I think leaving the definition of the index up to the range itself is paramount -- I don't want every range to be able to have a size_t index, as that's not always what you want, and it conflicts with other items. What

Re: foreach range with index

On 6/13/17 1:15 PM, Luís Marques wrote: In the documentation for foreach with range concepts (not x..y ranges) () I did not find anything about foreach supporting iteration indices/tuple unpacking for ranges, such as `foreach(i, elm;

foreach range with index

In the documentation for foreach with range concepts (not x..y ranges) () I did not find anything about foreach supporting iteration indices/tuple unpacking for ranges, such as `foreach(i, elm; range)`. It is "documented" in an example