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?

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.

On 02/02/2012 07: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?
>
> 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.
>
>

I think foreach_reverse and the associated opApplyReverse member function.

Ali

On 2 February 2012 15:46, Daniel Murphy <yebblies@nospamgmail.com> 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?
>
> 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.
>
>

Some of these have been deprecated for at least a few...

I think should organise them in order of priority and attach an agreed release version against them for the time they will be completely removed.


Three things I can pluck out of that list that I'd like to see gone in the next release if not sooner:

- The -v1 compiler switch (which I think only enables the use of === operator)
- volatile statements
- invariant as an alias for immutable


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Ali Çehreli" <acehreli@yahoo.com> wrote in message news:jged6d$21i5$1@digitalmars.com...
>
> I think foreach_reverse and the associated opApplyReverse member function.
>
> Ali
>

This was discussed, but I don't think any official conclusion was reached.

"Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.248.1328200426.25230.digitalmars-d@puremagic.com...
> Some of these have been deprecated for at least a few...

Yeah, I'll have a dig through the history/changelog and see if I can find dates.

> I think should organise them in order of priority and attach an agreed release version against them for the time they will be completely removed.

Releases tend to be 2 months apart, but are sometimes much closer (emergency regression fix, etc)  I think a date is more appropriate and more likely to be honoured.

> - The -v1 compiler switch (which I think only enables the use of === operator)

This is an error already, it does nothing.

> - invariant as an alias for immutable

I don't think all the deprecation errors for this have been around that long.

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

On 2/2/12, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> - 'l' suffix for integer literals

You mean L for long?

On Thursday, February 02, 2012 19:51:57 Andrej Mitrovic wrote:
> On 2/2/12, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> > - 'l' suffix for integer literals
> 
> You mean L for long?

No. He means l. l is deprecated. You're supposed to use L now instead of l.

Try using 1234567890l instead of 1234567890L, and you should a compiler error, because l is deprecated.

- Jonathan M Davis

On 2 February 2012 17:02, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.248.1328200426.25230.digitalmars-d@puremagic.com...
>> Some of these have been deprecated for at least a few...
>
> Yeah, I'll have a dig through the history/changelog and see if I can find dates.
>
>> I think should organise them in order of priority and attach an agreed release version against them for the time they will be completely removed.
>
> Releases tend to be 2 months apart, but are sometimes much closer (emergency regression fix, etc)  I think a date is more appropriate and more likely to be honoured.
>
>> - The -v1 compiler switch (which I think only enables the use of ===
>> operator)
>
> This is an error already, it does nothing.
>

That seems to have dropped below my radar then. :-)

I will have to remove that tonight!

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2/2/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Try using 1234567890l instead of 1234567890L, and you should a compiler
> error,
> because l is deprecated.

Makes sense, I had to copy-paste "l" and google it to find out if it was i or L!