www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecated language features

reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
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. 
Feb 02 2012
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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 

 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 

 year before being removed.

I think foreach_reverse and the associated opApplyReverse member function. Ali
Feb 02 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Feb 02 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Feb 02 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 02 2012
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Feb 02 2012
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 retro makes it very easy.

Right, sorry, but my comment was about intervals: foreach (i; 10 .. 0 : -1) {} Bye, bearophile
Feb 02 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Feb 02 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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
Feb 02 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Feb 03 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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. =A0I'd like to=

 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? =A0I'm thinking features should stay deprecated for arou=

 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 =3D=3D=3D = operator) - volatile statements - invariant as an alias for immutable --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 02 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Feb 02 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/12, Daniel Murphy <yebblies nospamgmail.com> wrote:
 - 'l' suffix for integer literals

You mean L for long?
Feb 02 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Feb 02 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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 (emerge=

 regression fix, etc) =A0I think a date is more appropriate and more likel=

 be honoured.

 - The -v1 compiler switch (which I think only enables the use of =3D=3D=


 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! --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 02 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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!
Feb 02 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 02 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.

Feb 04 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-08 12:04, Andrej Mitrovic wrote:
 On 2/4/12, Walter Bright<newshound2 digitalmars.com>  wrote:
 Base class protection attributes

I'm not sure what this means?

I think it's this: class Base {} class Foo : private Base {} -- /Jacob Carlborg
Feb 08 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/8/12, Jacob Carlborg <doob me.com> wrote:
 I think it's this:

 class Base {}
 class Foo : private Base {}

Looks like you're right. Thanks.
Feb 08 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/12/12, Adam <adaprogrammer usenet.net> wrote:
 Andrej Mitrovic wrote:
 On 2/4/12, Walter Bright <newshound2 digitalmars.com> wrote:
 Base class protection attributes

I'm not sure what this means?

It means he hates Serbians. :p

wat
Feb 12 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 04 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Feb 04 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Will do.  And pull requests on the actual features.

"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jgklsi$146t$1 digitalmars.com...
 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!

Feb 04 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2012 6:29 PM, Daniel Murphy wrote:
 Will do.  And pull requests on the actual features.

Thank you. This is important.
Feb 04 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 03, 2012 02:46:31 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.

What about scope on local variables? That's supposed to be deprecated in favor of std.typecons.Scoped. - Jonathan M Davis
Feb 06 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
I'll add it.

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.76.1328576679.20196.digitalmars-d puremagic.com...
 On Friday, February 03, 2012 02:46:31 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.

What about scope on local variables? That's supposed to be deprecated in favor of std.typecons.Scoped. - Jonathan M Davis

Feb 06 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/12, Walter Bright <newshound2 digitalmars.com> wrote:
 Base class protection attributes

I'm not sure what this means?
Feb 08 2012