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 

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
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 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 "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
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 next 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 reply "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
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 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=

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

nd 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 =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 reply "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
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=

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

y to
 be honoured.

 - The -v1 compiler switch (which I think only enables the use of =3D=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, 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 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 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
parent reply 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
next sibling parent reply 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
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 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