www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecation schedule

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I wonder what would be a good deprecation schedule. Consider 
http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.

We should now slowly deprecate std.utf.count. How should we go about it?

T0: documentation marked as "scheduled for deprecation".
T1: Function is deprecated and documentation updated to mention "has 
been deprecated"
T2: Function is eliminated

Question is, what are some good values for T1 - T0 and T2 - T1?


Andrei
Nov 26 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has 
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?


T0 = T1 = 0 seconds
T2 = 2 months (2 releases)

One year from now, in a similar situation:
T0 = 0 seconds, documentation marked as "scheduled for deprecation in next
release".
T1 = 1 release (1 month)
T2 = 3-6 releases (3 - 6 months)

Bye,
bearophile
Nov 26 2010
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:


 Andrei:
 

 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?


 
 T0 = T1 = 0 seconds
 T2 = 2 months (2 releases)
 
 One year from now, in a similar situation:
 T0 = 0 seconds, documentation marked as "scheduled for deprecation in next
 release". T1 = 1 release (1 month)
 T2 = 3-6 releases (3 - 6 months)
 
 Bye,
 bearophile


That is very harsh for T2, it means that at this point anything you write 
might not compile anymore with the newest phobos in just 5 weeks time. Even 
3 months is short, especially for a more stable point in time. I'd rather 
have T1 earlier and last longer, that way you can still compile the code.
Dec 07 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:

 I wonder what would be a good deprecation schedule. Consider
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
 
 We should now slowly deprecate std.utf.count. How should we go about it?
 
 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?


I think that not doing T0 and T1 at the same time only makes sense if we know 
that we're going to deprecate it but aren't ready to do so yet (like if we were 
to do another release with std.date without putting in the new std.datetime -
we 
_know_ that we're going to deprecate std.date, but we wouldn't be ready to 
actually do it yet, because it's replacement wasn't yet in Phobos). So, in this 
case, I think that T0 and T1 should be done at the same time.

As for for how long a function should be deprecated and not yet removed, that's 
a bit harder. How often do people update dmd? Part of me wants to say 1
release, 
but I know that there are people out there who don't bother updating for a 
release or two. How long before having a function deprecated but still there 
becomes an issue (particularly if you end up with very many of them)? And given 
the relatively fast pace of development, if we were actually to deprecate 
everything that we wanted to deprecate right now, I'm not sure that it would be 
all that short a list (though, since it's mostly either whole modules or an 
entire language feature like scoped local variables rather than individual 
functions, the actual number of things that you'd have to list as deprecated 
would probably be rather short).

I'd say that T2 - T1 should be about 6 months at most at this point. If Phobos 
dmd and Phobos were completely stable and had been for a while, then something 
more like 2 years might be appropriate, but the pace of development is still
too 
fast for that to make sense. 6 months is still a bit of an eternity for D at
the 
moment, so that's probably enough right now. I do think, however, that it's 
something that should change once Phobos has become more stable.

- Jonathan M Davis
Nov 26 2010
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Jonathan M Davis wrote:


 On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:

 I wonder what would be a good deprecation schedule. Consider
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
 
 We should now slowly deprecate std.utf.count. How should we go about it?
 
 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?


 
 I think that not doing T0 and T1 at the same time only makes sense if we
 know that we're going to deprecate it but aren't ready to do so yet (like
 if we were to do another release with std.date without putting in the new
 std.datetime - we _know_ that we're going to deprecate std.date, but we
 wouldn't be ready to actually do it yet, because it's replacement wasn't
 yet in Phobos). So, in this case, I think that T0 and T1 should be done at
 the same time.


It's helpful to know if some module is going to be deprecated in the near 
future, even if an alternative is not ready. That is true for many modules 
in phobos. So a for T0 should be the moment the decision is made and T1 as 
soon as an alternative is ready - or the functionality is dropped entirely. 
 

 As for for how long a function should be deprecated and not yet removed,
 that's a bit harder. How often do people update dmd? Part of me wants to
 say 1 release, but I know that there are people out there who don't bother
 updating for a release or two. How long before having a function
 deprecated but still there becomes an issue (particularly if you end up
 with very many of them)? And given the relatively fast pace of
 development, if we were actually to deprecate everything that we wanted to
 deprecate right now, I'm not sure that it would be all that short a list
 (though, since it's mostly either whole modules or an entire language
 feature like scoped local variables rather than individual functions, the
 actual number of things that you'd have to list as deprecated would
 probably be rather short).
 
 I'd say that T2 - T1 should be about 6 months at most at this point. If
 Phobos dmd and Phobos were completely stable and had been for a while,
 then something more like 2 years might be appropriate, but the pace of
 development is still too fast for that to make sense. 6 months is still a
 bit of an eternity for D at the moment, so that's probably enough right
 now. I do think, however, that it's something that should change once
 Phobos has become more stable.
 
 - Jonathan M Davis


Although it's good to remove things, why should it be rushed? What is the  
inconvenience of having deprecated stuff lingering? Phobos users will still 
be reminded by the compiler that they should update the code, which is 
useful.
Dec 07 2010
parent reply Don <nospam nospam.com> writes:
Lutger Blijdestijn wrote:

 Jonathan M Davis wrote:
 

 On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:

 I wonder what would be a good deprecation schedule. Consider
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.

 We should now slowly deprecate std.utf.count. How should we go about it?

 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has
 been deprecated"
 T2: Function is eliminated

 Question is, what are some good values for T1 - T0 and T2 - T1?


 I think that not doing T0 and T1 at the same time only makes sense if we
 know that we're going to deprecate it but aren't ready to do so yet (like
 if we were to do another release with std.date without putting in the new
 std.datetime - we _know_ that we're going to deprecate std.date, but we
 wouldn't be ready to actually do it yet, because it's replacement wasn't
 yet in Phobos). So, in this case, I think that T0 and T1 should be done at
 the same time.


 
 It's helpful to know if some module is going to be deprecated in the near 
 future, even if an alternative is not ready. That is true for many modules 
 in phobos. So a for T0 should be the moment the decision is made and T1 as 
 soon as an alternative is ready - or the functionality is dropped entirely. 
  

 As for for how long a function should be deprecated and not yet removed,
 that's a bit harder. How often do people update dmd? Part of me wants to
 say 1 release, but I know that there are people out there who don't bother
 updating for a release or two. How long before having a function
 deprecated but still there becomes an issue (particularly if you end up
 with very many of them)? And given the relatively fast pace of
 development, if we were actually to deprecate everything that we wanted to
 deprecate right now, I'm not sure that it would be all that short a list
 (though, since it's mostly either whole modules or an entire language
 feature like scoped local variables rather than individual functions, the
 actual number of things that you'd have to list as deprecated would
 probably be rather short).

 I'd say that T2 - T1 should be about 6 months at most at this point. If
 Phobos dmd and Phobos were completely stable and had been for a while,
 then something more like 2 years might be appropriate, but the pace of
 development is still too fast for that to make sense. 6 months is still a
 bit of an eternity for D at the moment, so that's probably enough right
 now. I do think, however, that it's something that should change once
 Phobos has become more stable.

 - Jonathan M Davis


 
 Although it's good to remove things, why should it be rushed? What is the  
 inconvenience of having deprecated stuff lingering? 


Some features cannot be implemented until some deprecated functions have 
been completely removed.


Phobos users will still 
 be reminded by the compiler that they should update the code, which is 
 useful.
Dec 07 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 07, 2010 16:53:38 Don wrote:

 Lutger Blijdestijn wrote:

 Jonathan M Davis wrote:

 On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:

 I wonder what would be a good deprecation schedule. Consider
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
 
 We should now slowly deprecate std.utf.count. How should we go about
 it?
 
 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?


 
 I think that not doing T0 and T1 at the same time only makes sense if we
 know that we're going to deprecate it but aren't ready to do so yet
 (like if we were to do another release with std.date without putting in
 the new std.datetime - we _know_ that we're going to deprecate
 std.date, but we wouldn't be ready to actually do it yet, because it's
 replacement wasn't yet in Phobos). So, in this case, I think that T0
 and T1 should be done at the same time.


 
 It's helpful to know if some module is going to be deprecated in the near
 future, even if an alternative is not ready. That is true for many
 modules in phobos. So a for T0 should be the moment the decision is made
 and T1 as soon as an alternative is ready - or the functionality is
 dropped entirely.
 

 As for for how long a function should be deprecated and not yet removed,
 that's a bit harder. How often do people update dmd? Part of me wants to
 say 1 release, but I know that there are people out there who don't
 bother updating for a release or two. How long before having a function
 deprecated but still there becomes an issue (particularly if you end up
 with very many of them)? And given the relatively fast pace of
 development, if we were actually to deprecate everything that we wanted
 to deprecate right now, I'm not sure that it would be all that short a
 list (though, since it's mostly either whole modules or an entire
 language feature like scoped local variables rather than individual
 functions, the actual number of things that you'd have to list as
 deprecated would probably be rather short).
 
 I'd say that T2 - T1 should be about 6 months at most at this point. If
 Phobos dmd and Phobos were completely stable and had been for a while,
 then something more like 2 years might be appropriate, but the pace of
 development is still too fast for that to make sense. 6 months is still
 a bit of an eternity for D at the moment, so that's probably enough
 right now. I do think, however, that it's something that should change
 once Phobos has become more stable.
 
 - Jonathan M Davis


 
 Although it's good to remove things, why should it be rushed? What is the
 inconvenience of having deprecated stuff lingering?


 
 Some features cannot be implemented until some deprecated functions have
 been completely removed.


That, and to some extent, you still have to maintain it. Just because it's 
deprecated doesn't mean that it should stop working - just that it shouldn't be 
used in any new code and that old code should be changed so that it doesn't use 
it anymore.

Also, as long as it's around people will use it. If you really want it gone, it 
needs to be gone, not just deprecated.

- Jonathan M Davis
Dec 07 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 08/12/2010 00:53, Don wrote:

 Lutger Blijdestijn wrote:

 Although it's good to remove things, why should it be rushed? What is
 the inconvenience of having deprecated stuff lingering?


 Some features cannot be implemented until some deprecated functions have
 been completely removed.


I'm surprised that's the case, what exactly are those features?


I think that likely there should not be a constant rule for (T2 - T1). 
It depends on how much value is gained by removing the deprecated 
feature. If the new API can coexist with the deprecated one without 
drawbacks, and there is not much maintenance work done on the deprecated 
implementation, there is little gain in removing it, so I agree with 
Lutger that (T2 - T1) should be long. But otherwise it should be 
shorter, yeah.


-- 
Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
T0 - As soon as there are concrete plans for a replacement. I'd also mark
sub-par modules as"looking for someone to replace this". Truth in advertising
is always appreciated.
T1 - As soon as replacement code is available or maybe a month after it's
available. Regardless, I'd update the scheduled for documentation bit with
instructions on using the new API as soon as it's available.
T2 - This should be quite long. There's no reason to leave active projects with
a non-compiling code base just because an API in a low priority area has
changed. I would say something like 6-12 months. What do other languages do?

Andrei Alexandrescu Wrote:


 I wonder what would be a good deprecation schedule. Consider 
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
 
 We should now slowly deprecate std.utf.count. How should we go about it?
 
 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has 
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?
 
 
 Andrei
Nov 26 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 15:19:37 Jason House wrote:

 T2 - This should be quite long. There's no
 reason to leave active projects with a non-compiling code base just
 because an API in a low priority area has changed. I would say something
 like 6-12 months. What do other languages do?


Java marks stuff as deprecated and then _never_ removes it. It makes the 
deprecation a bit of a joke really. Many people continue to use the deprecated 
stuff anyway. A prime example would be that they deprecated Date's most useful 
constructors in an effort to make you use the Calendar stuff. People keep on
using 
those constructors anyway, because they don't care about the Calendar stuff,
and 
it's a lot more of a pain to use. As far as I know, Sun has _never_ actually 
removed a deprecated function from Java's standard library (and if they haven't 
before, now they never will since they were eaten by Oracle - who knows what 
Oracle will do).

Certainly, whatever we do, we don't want to follow Java's route. Hopefully
there 
are other languages out there which handle deprecation better. Since I've
mostly 
been a C++ and Java guy though, I'm not at all familiar with how other
languages 
deal with it. Python would probably be a good place to look though, since they 
generally seem to be pretty organized.

- Jonathan M Davis
Nov 26 2010
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/11/2010 23:44, Jonathan M Davis wrote:
<snip>

 Java marks stuff as deprecated and then _never_ removes it. It makes the
 deprecation a bit of a joke really. Many people continue to use the deprecated
 stuff anyway. A prime example would be that they deprecated Date's most useful
 constructors in an effort to make you use the Calendar stuff. People keep on
using
 those constructors anyway, because they don't care about the Calendar stuff,
and
 it's a lot more of a pain to use.


Hooray for Phobos's "simple operations should be simple" philosophy!

Another example of a pain in Java is GridBagLayout.  If only Java had 
that philosophy, I suppose GridBagLayout would never have been invented. 
  (Sun did eventually publish something better - TableLayout - but for 
some reason it hasn't become a standard API feature.)


 As far as I know, Sun has _never_ actually
 removed a deprecated function from Java's standard library (and if they haven't
 before, now they never will since they were eaten by Oracle - who knows what
 Oracle will do).


I wonder when/if they're going to get rid of Thread.destroy, which was 
in the API for many years but never implemented.


 Certainly, whatever we do, we don't want to follow Java's route. Hopefully
there
 are other languages out there which handle deprecation better.


<snip>

But does Java ever deprecate language features, or only API features? 
In the latter case, it's a matter of other libraries/APIs, not other 
languages.

Stewart.
Nov 26 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 18:38:20 Stewart Gordon wrote:

 But does Java ever deprecate language features, or only API features?
 In the latter case, it's a matter of other libraries/APIs, not other
 languages.


That's true. I'm not sure that they've ever deprecated a language feature. I 
don't _think_ so, but I'm not 100% sure. I'd be surprised. It's more of a 
library thing really. So, maybe looking at what the deal is with something like 
Apache Commons would be a good place to look.

- Jonathan M Davis
Nov 26 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-27 00:44, Jonathan M Davis wrote:

 On Friday 26 November 2010 15:19:37 Jason House wrote:

 T2 - This should be quite long. There's no
 reason to leave active projects with a non-compiling code base just
 because an API in a low priority area has changed. I would say something
 like 6-12 months. What do other languages do?


 Java marks stuff as deprecated and then _never_ removes it. It makes the
 deprecation a bit of a joke really. Many people continue to use the deprecated
 stuff anyway. A prime example would be that they deprecated Date's most useful
 constructors in an effort to make you use the Calendar stuff. People keep on
using
 those constructors anyway, because they don't care about the Calendar stuff,
and
 it's a lot more of a pain to use. As far as I know, Sun has _never_ actually
 removed a deprecated function from Java's standard library (and if they haven't
 before, now they never will since they were eaten by Oracle - who knows what
 Oracle will do).

 Certainly, whatever we do, we don't want to follow Java's route. Hopefully
there
 are other languages out there which handle deprecation better. Since I've
mostly
 been a C++ and Java guy though, I'm not at all familiar with how other
languages
 deal with it. Python would probably be a good place to look though, since they
 generally seem to be pretty organized.

 - Jonathan M Davis


It seems like that developers using Java are very afraid of removing 
anything. If I recall correctly the SWT library contains several 
classes/interfaces with a 2 appended to the end of the name just because 
they don't want to remove the old class/interface.

-- 
/Jacob Carlborg
Nov 27 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 27/11/2010 17:04, Jacob Carlborg wrote:
<snip>

 It seems like that developers using Java are very afraid of removing
 anything. If I recall correctly the SWT library contains several
 classes/interfaces with a 2 appended to the end of the name just because
 they don't want to remove the old class/interface.


Adding methods to an existing interface creates immediate backward 
incompatibility, no wait for the interface to be removed.  It's like 
changing the parameter list of a function.

Stewart.
Nov 27 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 26/11/2010 23:44, Jonathan M Davis wrote:

 On Friday 26 November 2010 15:19:37 Jason House wrote:

 T2 - This should be quite long. There's no
 reason to leave active projects with a non-compiling code base just
 because an API in a low priority area has changed. I would say something
 like 6-12 months. What do other languages do?


 Java marks stuff as deprecated and then _never_ removes it.


<snip>

Thinking about it now, I can see why.  Java .class files don't contain 
implementations of the Java APIs - they pull them up from the JRE on 
demand.  So if stuff were removed, old programs would stop working, not 
just stop compiling.

Though I suppose they could do something like declare Java 1 obsolete, 
and then another few years down the line start to remove stuff.  Maybe 
with a warning for anyone who tries to use a Java 1 app that it may not 
function correctly.  (Do .class files store such version info?)

.exe files, OTOH, have the library code they rely on embedded in them. 
So removing something from a library won't break these old binaries.

Stewart.
Nov 27 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 27/11/2010 17:04, Stewart Gordon wrote:

 On 26/11/2010 23:44, Jonathan M Davis wrote:

 On Friday 26 November 2010 15:19:37 Jason House wrote:

 T2 - This should be quite long. There's no
 reason to leave active projects with a non-compiling code base just
 because an API in a low priority area has changed. I would say something
 like 6-12 months. What do other languages do?


 Java marks stuff as deprecated and then _never_ removes it.


 <snip>

 Thinking about it now, I can see why. Java .class files don't contain
 implementations of the Java APIs - they pull them up from the JRE on
 demand. So if stuff were removed, old programs would stop working, not
 just stop compiling.


Yup, there are no equivalent of "executables" in Java compilation 
artifacts, only the .class files which are the equivalent of "shared 
libraries". Thus binary compatibility is a constant issue.


 Though I suppose they could do something like declare Java 1 obsolete,
 and then another few years down the line start to remove stuff.
 Maybe
 with a warning for anyone who tries to use a Java 1 app that it may not
 function correctly.(Do .class files store such version info?)


.class files do have version info, but that relates to bytecode 
compatibility only, it specifies to the minimum *VM* interpreter 
required (1.4, 1.5, 1.6, etc.). But it says nothing about the minimum 
JRE (standard library) required, which can be higher (but not lower).



The problem with removing stuff in the JRE in a breaking manner, is that 
in enterprise software you often have a system with *lots* of 
middleware, libraries, other third-party software, etc., in the same 
Java program. If just one of them requires that deprecated API, removing 
that API could make the whole system not run, in newer VM's at least. 
And often such software is closed-source, so you can't just modify it to 
run on newer JREs. So they have to be very mindful of that.

The other thing (especially with APIs) is that sometimes there is no 
significant advantage in actually removing deprecated stuff: just having 
the people switch to an alternate component/library is good enough (like 
the Calendar example). Removing is only more significant when the two 
APIs (newer and older) cannot coexist at the same time (or cannot do so 
easily).


-- 
Bruno Medeiros - Software Engineer
Dec 07 2010
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-11-26 at 15:44 -0800, Jonathan M Davis wrote:


 Java marks stuff as deprecated and then _never_ removes it. It makes the=


=20

 deprecation a bit of a joke really. Many people continue to use the depre=


cated=20

Not entirely true.  There was some stuff that Sun actually removed
between 1.3 and 1.4 I think but there was a huge outcry and so it was
all put back in (undeprecated!) for 1.5.  I can't remember the exact
details but there were two issues:

1.  The items in question should not have been deprecated in the first
place.

2.  The whole incident, and Sun's obsessive commitment to backwards
compatibility, meant that nothing ever got removed again.

On the whole though, it is true Sun should have removed things that have
been deprecated.=20


 stuff anyway. A prime example would be that they deprecated Date's most u=


seful=20

 constructors in an effort to make you use the Calendar stuff. People keep=


 on using=20

 those constructors anyway, because they don't care about the Calendar stu=


ff, and=20

 it's a lot more of a pain to use. As far as I know, Sun has _never_ actua=


lly=20

 removed a deprecated function from Java's standard library (and if they h=


aven't=20

 before, now they never will since they were eaten by Oracle - who knows w=


hat=20

 Oracle will do).


Actually the whole Calendar thing should not only be deprecated as a
whole, it should be ignored as of now.  Use only JodaTime!


 Certainly, whatever we do, we don't want to follow Java's route. Hopefull=


y there=20

 are other languages out there which handle deprecation better. Since I've=


 mostly=20

 been a C++ and Java guy though, I'm not at all familiar with how other la=


nguages=20

 deal with it. Python would probably be a good place to look though, since=


 they=20

 generally seem to be pretty organized.


I guess the prime example here is Fortran -- they end up not being
allowed to deprecate anything, let along remove it from the language.
It never ceases to amaze me that the committee manages to evolve the
language and yet still be able to compile all the 1960s legacy code that
everyone colludes in finding no-one willing to rewrite.  This is not a
negative comment on the Fortran language evolution people, exactly the
opposite, but it is an indictment of a society that chooses to insist
that old code that works not be rewritten even though hardware has moved
on significantly making the code significantly past its use-by date.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 27 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:

 I guess the prime example here is Fortran -- they end up not being
 allowed to deprecate anything, let along remove it from the language.
 It never ceases to amaze me that the committee manages to evolve the
 language and yet still be able to compile all the 1960s legacy code that
 everyone colludes in finding no-one willing to rewrite.  This is not a
 negative comment on the Fortran language evolution people, exactly the
 opposite, but it is an indictment of a society that chooses to insist
 that old code that works not be rewritten even though hardware has moved
 on significantly making the code significantly past its use-by date. 


On the other hand, even small incompatibilities moving from D1 to D2 create 
problems for people. Fortran's longevity may be in part attributable to its 
perfect legacy compatibility. After all, if you're going to force a rewrite of 
the old code, one might as well move to a more modern language.
Nov 27 2010
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:

 I wonder what would be a good deprecation schedule. Consider 
 http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
 
 We should now slowly deprecate std.utf.count. How should we go about it?
 
 T0: documentation marked as "scheduled for deprecation".
 T1: Function is deprecated and documentation updated to mention "has 
 been deprecated"
 T2: Function is eliminated
 
 Question is, what are some good values for T1 - T0 and T2 - T1?
 
 
 Andrei


T0: As soon as it's decided that the function will be replaced

T1: Once the replacement is available and usable (tested, considered mostly
stable)

T2: If the function was available in phobos1: never/for D3. That would make 
porting of D1/Phobos1 code to D2 a lot easier - one could replace the use of 
deprecated functions bit by bit instead of having to overhaul the whole project 
before being able to compile it for D2 - or, at least you'd only have to fix 
stuff concerning changes in the language (const, TLS, etcpp) at first.
If it wasn't available in phobos1: Within 2 or 3 DMD releases?

Cheers,
- Daniel
Nov 26 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I wonder what would be a good deprecation schedule.


I'd like to know something about the deprecation schedule of compiler features
too, that is when they will be removed from the DMD front-end. Things like part
of the complex number syntax, typedef, floating point comparison operators (are
they present still?), scoped classes, delete, implicit string joining, old
operator overloading scheme, and so on and on.

This stuff makes the front end code longer, may cause bugs (because you don't
have bugs in code that is not present), needs maintenance to be kept working as
DMD changes, makes the creation of alternative D compilers unnecessarily a bit
harder and laborious, and it may confuse newbies.

I've seen lot of talking about deprecated features (like the long discussion
about deprecation of delete), but only very rarely I've seen them actually
removed... (I remember the array[new], some bad C syntax removed recently and
what else?).

Bye,
bearophile
Nov 28 2010