February 03, 2012
Am 02.02.2012, 18:53 Uhr, schrieb bearophile <bearophileHUGS@lycos.com>:

> Ali:
>
>> I think foreach_reverse and the associated opApplyReverse member function.
>
> I use it now and then. A possible replacement:
>
> foreach (i; 10 .. 0 : -1) {}
>
> Bye,
> bearophile

I agree. iterating in reverse over an array is common enough
February 03, 2012
On Friday, February 03, 2012 03:08:05 Marco Leise wrote:
> Am 02.02.2012, 18:53 Uhr, schrieb bearophile <bearophileHUGS@lycos.com>:
> > Ali:
> >> I think foreach_reverse and the associated opApplyReverse member function.
> > 
> > I use it now and then. A possible replacement:
> > 
> > foreach (i; 10 .. 0 : -1) {}
> > 
> > Bye,
> > bearophile
> 
> I agree. iterating in reverse over an array is common enough

retro makes it very easy.

- Jonathan M Davis
February 03, 2012
Jonathan M Davis:

> retro makes it very easy.

But it can't be used here. retro is too much slow. And you can't write retro(1..10).

Bye,
bearophile
February 03, 2012
Jonathan M Davis:

> retro makes it very easy.

Right, sorry, but my comment was about intervals:
foreach (i; 10 .. 0 : -1) {}

Bye,
bearophile
February 03, 2012
Am 03.02.2012, 03:19 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Friday, February 03, 2012 03:08:05 Marco Leise wrote:
>> Am 02.02.2012, 18:53 Uhr, schrieb bearophile <bearophileHUGS@lycos.com>:
>> > Ali:
>> >> I think foreach_reverse and the associated opApplyReverse member
>> >> function.
>> >
>> > I use it now and then. A possible replacement:
>> >
>> > foreach (i; 10 .. 0 : -1) {}
>> >
>> > Bye,
>> > bearophile
>>
>> I agree. iterating in reverse over an array is common enough
>
> retro makes it very easy.
>
> - Jonathan M Davis

Ok, sometimes I have nested loops and I limit the inner loop by the counter of the outer loop and then I cannot iterate over the array, but just want a fast foreach_reverse(i; a .. b). Can retro reproduce that without any function call overhead? If I think that reverse iteration will be slower, then I'll not use it in the first place.
February 03, 2012
On Friday, February 03, 2012 04:32:01 Marco Leise wrote:
> Am 03.02.2012, 03:19 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:
> > On Friday, February 03, 2012 03:08:05 Marco Leise wrote:
> >> Am 02.02.2012, 18:53 Uhr, schrieb bearophile <bearophileHUGS@lycos.com>:
> >> > Ali:
> >> >> I think foreach_reverse and the associated opApplyReverse member function.
> >> > 
> >> > I use it now and then. A possible replacement:
> >> > 
> >> > foreach (i; 10 .. 0 : -1) {}
> >> > 
> >> > Bye,
> >> > bearophile
> >> 
> >> I agree. iterating in reverse over an array is common enough
> > 
> > retro makes it very easy.
> > 
> > - Jonathan M Davis
> 
> Ok, sometimes I have nested loops and I limit the inner loop by the counter of the outer loop and then I cannot iterate over the array, but just want a fast foreach_reverse(i; a .. b). Can retro reproduce that without any function call overhead? If I think that reverse iteration will be slower, then I'll not use it in the first place.

That's entirely a matter of how good the compiler is at inlining.

- Jonathan M Davis
February 04, 2012
On Thu, 02 Feb 2012 12:53:38 -0500, bearophile <bearophileHUGS@lycos.com> wrote:

> Ali:
>
>> I think foreach_reverse and the associated opApplyReverse member function.
>
> I use it now and then. A possible replacement:
>
> foreach (i; 10 .. 0 : -1) {}

foreach_reverse is fine to keep for builtins and range specifiers, but I'd really like to get rid of it for every other use.  We already have foreach on a delegate to give us the equivalent functionality.

The worst thing is foreach_reverse on a delegate, since the delegate does nothing different when called in "reverse" mode!

-Steve
February 04, 2012
On 2/2/2012 7:46 AM, Daniel Murphy wrote:
> There are a bunch of features that are planned for removal, and some that
> are already deprecated, but no clear timeline for removal.  I'd like to make
> a comprehensive list, pick suitable durations, then I'll make a wiki page
> for this.
>
> What I've got so far is...
>
> Planned for deprecation:
> - float.min
> - complex and imaginary types
> - NCEG operators
> - array.sort and array.reverse
> - delete?

Base class protection attributes


> Deprecated:
> - Using length inside index expressions
> - typedef
> - variable shadowing
> - invariant as an alias for immutable
> - derefencing arrays with *
> - delete aa[key] (same as aa.remove(key))
> - .offset
> - escape string literals
> - 'l' suffix for integer literals
> - octal literals
> - 'I' suffix for imaginary literals
> - html source files
> - Type.typeinfo syntax
> - base class protection
> - c-style function and array pointers
> - if (v; e) syntax
> - volatile statements
> - non-final switch statements without defaults
> - hiding base class functions (was previously only a run-time check)
>
> Any I've missed?  I'm thinking features should stay deprecated for around a
> year before being removed.
>
>

February 04, 2012
On 2/2/2012 7:46 AM, Daniel Murphy wrote:
> There are a bunch of features that are planned for removal, and some that
> are already deprecated, but no clear timeline for removal.  I'd like to make
> a comprehensive list, pick suitable durations, then I'll make a wiki page
> for this.

Yes, it's high time this was done.
February 05, 2012
On 2/2/2012 7:46 AM, Daniel Murphy wrote:
> There are a bunch of features that are planned for removal, and some that
> are already deprecated, but no clear timeline for removal.  I'd like to make
> a comprehensive list, pick suitable durations, then I'll make a wiki page
> for this.

This should be a D spec page. I've started one here:

https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd

Please add a pull request with the information you're gathering. This would be a great help!