Bill Baxter wrote:
> I think the iterator-as-range idea is at least worth discussing.  99% of the time you use an iterator you also need to know where to stop.  It's pretty similar to how arrays in D keep a length, because 99% of the time when you have an array you need to know how long it is too.  So it makes sense to keep those two bits of information together.  Similarly in C++, when you have an iterator, you almost always need the end() too.  And any time you want to pass around iterators you end up having to pass the two bits of information around separately.

That's a very good point. Got any ideas on that?

"Walter Bright" <newshound@digitalmars.com> wrote in message news:eio6u5$1j6o$1@digitaldaemon.com...

> Overload opIndex for rvalue access
> Overload opIndexAssign for lvalue access

Somehow..

foreach(i; foo)
{
    auto x = i[0];
    i[0] = x + 1;
}

You often say that operator overloading should be used only what it should be used for, and taking the index of an iterator means.. what exactly?

Would it be nicer to just use a .value property instead?

foreach(i; foo)
{
    auto x = i.value;
    i.value = x + 1;
}

Jarrett Billingsley wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eio6u5$1j6o$1@digitaldaemon.com...
> 
>> Overload opIndex for rvalue access
>> Overload opIndexAssign for lvalue access
> 
> Somehow..
> 
> foreach(i; foo)
> {
>     auto x = i[0];
>     i[0] = x + 1;
> }
> 
> You often say that operator overloading should be used only what it should be used for, and taking the index of an iterator means.. what exactly?
> 
> Would it be nicer to just use a .value property instead?
> 
> foreach(i; foo)
> {
>     auto x = i.value;
>     i.value = x + 1;
> } 

The problem is if the iterator is an actual pointer, there is no .value property for a pointer.

Another possibility is to have:
	*x
rewritten to:
	x[0]
if x is not a pointer.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:eiosro$28g6$1@digitaldaemon.com...

> The problem is if the iterator is an actual pointer, there is no .value property for a pointer.
>
> Another possibility is to have:
> *x
> rewritten to:
> x[0]
> if x is not a pointer.

And yet another is to allow overriding of opDeref and opDerefAssign ;) Which would, of course, be the _optimal_ solution, but..

Walter Bright wrote:
> Tom S wrote:
>> Walter Bright wrote:
>>> foreach loops will not be able to have a 'key' parameter.
>> What's the particular reason for that restriction ?
> 
> With an iterator, what is the key?

with an iterator, what is the "value"?
Is it the key-value *pair*, or is it just the key?

On Mon, 06 Nov 2006 12:46:01 -0800, Walter Bright wrote:

> It's becoming increasingly obvious that D needs iterators. While opApply
>   is far better for some kinds of iteration (such as recursively
> traversing a directory), iterators are more efficient in some cases, and
> allow for things that opApply makes difficult.
> 

What are those cases ? Maybe we can find a way to fix the problem with opApply.

Walter Bright wrote:

> there's no way to efficiently 'linearize' a binary tree

In the general case the structure to be linearized is a directed graph. Every linearization has to at least implicitely build a spanning tree for that graph.

A priori in spanning trees the number of childs of a node is limited only by the number of nodes of the structure.

Therefore every linearizator must be able to handle trees of arbitrary degree.

From tree grammars it is known, that top down attributions and bottom up attributions are incomparable to each other when only one run is allowed.

Because the goal of any linearization is to compute some attribution of the structure every 'traverser' must assist the process outlined above, where in the general case more than one run is needed.

Now: what is efficiency in this general case?

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eio6u5$1j6o$1@digitaldaemon.com...
>>
>>> Overload opIndex for rvalue access
>>> Overload opIndexAssign for lvalue access
>>
>> Somehow..
>>
>> foreach(i; foo)
>> {
>>     auto x = i[0];
>>     i[0] = x + 1;
>> }
>>
>> You often say that operator overloading should be used only what it should be used for, and taking the index of an iterator means.. what exactly?
>>
>> Would it be nicer to just use a .value property instead?
>>
>> foreach(i; foo)
>> {
>>     auto x = i.value;
>>     i.value = x + 1;
>> } 
> 
> The problem is if the iterator is an actual pointer, there is no .value property for a pointer.

Is there really any reason to support pointers as iterators though?  C++ libraries even seem to be moving away from that towards more robust and less error-prone iterator objects.


Sean

Knud Sørensen wrote:
> On Mon, 06 Nov 2006 12:46:01 -0800, Walter Bright wrote:
> 
>> It's becoming increasingly obvious that D needs iterators. While opApply   is far better for some kinds of iteration (such as recursively traversing a directory), iterators are more efficient in some cases, and allow for things that opApply makes difficult.
>>
> 
> What are those cases ? Maybe we can find a way to fix the problem with
> opApply.

One such case is the usefulness of being able to provide an input iterator to a parsing function, which may itself pass the iterator off to other parsing functions.

Sean Kelly wrote:
>>>
>>> Would it be nicer to just use a .value property instead?
>>>
>>> foreach(i; foo)
>>> {
>>>     auto x = i.value;
>>>     i.value = x + 1;
>>> } 
>>
>> The problem is if the iterator is an actual pointer, there is no .value property for a pointer.

Well, they could.  It's up to Mr. Compiler Writer if a pointer has a value property or not.

> Is there really any reason to support pointers as iterators though?  C++ libraries even seem to be moving away from that towards more robust and less error-prone iterator objects.

Agreed.  I don't think I've ever actually used a raw pointer with a fancy STL algorithm.  I was actually really surprised the first time I saw it in the examples on the SGI STL page.  Other than those examples, I've never seen it in real code.

And that should go double for D, where you rarely even see pointers to begin with.

--bb