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