DMD 0.170 release

[Bill Baxter]

Walter Bright wrote:
> Bill Baxter wrote:
>> I don't see how it helps.  If you can already do:
>>    foreach(T item; &collection.reversed()) { }
> 
> That doesn't work for arrays.

I see.  I didn't realize the compiler special-cased arrays with foreach.
I see that also extends to every built-in behavior that can be mimicked 
by operator overloading.   That's disappointing.

It would be much more consistent if something[4] could *always* be 
substituted with something.opIndex(4).  Or if foreach(a; something) 
could *always* be substituted with foreach(a; &something.opApply).  That 
doesn't mean that arrays have to be classes, just that it has to look 
like one to the user.  Same way they now have .length, but that doesn't 
mean they are classes/structs.  You can still use whatever optimizations 
or special cases you want in the compiler to speed it up.

Hmmm.  Well anyway, even if array.reversed() isn't going to work, I 
still think

    foreach(T item; reversed(collection)) { }

could be the solution.  In any case you've got to have a reasonable 
story for how to handle specific iteration strategies being bolted on 
after the fact.  I.e. I've got a BorgCollection class and I want an 
iterator that returns only the borg's which are of type KlingonBorg. 
Unfortunately the BorgCollection designer didn't foresee this need. 
There should be a reasonable way for me to write a klingonBorgIter 
function so I can say

    foreach(KlingonBorg b; klingonBorgIter(borg_collection)) {
    }

I can do that now.  Tom S showed how.  But you say that requires "dummy 
classes and hackish stuff" and so is not good enough as a solution for 
the core iteration implementation.  So *make* it good enough! Figure out 
how to make it work, then apply that one technique mercilessly and 
consistently everywhere.

--bb