www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecated Library Functions / Methods

reply "Chris" <wendlec tcd.ie> writes:
Is there a way of telling when things in the library will calm 
down and it'll be save to develop in D and update old code?

I started with D2 version 2.051 and created a medium-sized 
project fairly quickly, but now I have a lot of deprecated 
methods in my code. I couldn't keep up with all the changes and I 
have been hesitant to update my code because there are still a 
lot of "Will be removed in September/November/December ..." 
warnings in the library. Much that I like D, I simply cannot 
develop in D at the moment due to the constant changes in the 
Phobos library. I have this sinking feeling that this is killing 
the language.
Nov 30 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/30/12 10:04 AM, Chris wrote:
 Is there a way of telling when things in the library will calm down and
 it'll be save to develop in D and update old code?

 I started with D2 version 2.051 and created a medium-sized project
 fairly quickly, but now I have a lot of deprecated methods in my code. I
 couldn't keep up with all the changes and I have been hesitant to update
 my code because there are still a lot of "Will be removed in
 September/November/December ..." warnings in the library. Much that I
 like D, I simply cannot develop in D at the moment due to the constant
 changes in the Phobos library. I have this sinking feeling that this is
 killing the language.
Thanks for this testimony. Andrei
Nov 30 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 30 Nov 2012 10:19:08 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 11/30/12 10:04 AM, Chris wrote:
 Is there a way of telling when things in the library will calm down
 and it'll be save to develop in D and update old code?
Thanks for this testimony. Andrei
I think what we need is a "hard cut" for phobos. We could release 2.061 and then stop all regular bug fixing / enhancement work on phobos for two weeks. In those two weeks all work would be concentrated on reviewing the existing phobos modules. So we'd start a wiki page, assign every module to at least one person reviewing it. Those people should correct naming and codig style of the module in their local repositories. Controversial changes could be discussed on the wiki. If names have to be changed to match the coding conventions the old names should be deprecated. Some modules should be deprecated as a whole, even if we do not yet have a proper replacement yet. For example we know for many years that std.xml is broken and nobody is fixing it, but we still ship it with phobos. std.signal is written in an old D1 style. std.json should probably be removed as well. We should get rid of all that legacy even if we don't have a replacement yet. In the end we would have a 2.062 release with all the old functionality (deprecated) and new functionality / names matching our coding conventions. Some releases later (e.g. 2.064) all deprecated functionality will be removed. Then everyone knows that: * The new functions in 2.062 should be used ASAP. * 2.063 will be the last version supporting the deprecated functionality. * 2.064 will be 'clean'. All deprecated features will be removed and the rest of the functions will be stable. (At very least there will be no more naming changes or similar stuff) So we'd end up with a phobos with less functionality because of the dropped features and upgrading user code to 2.064 might be a bigger task, but we will guarantee that there will be no (or at least very few) breaking changes after 2.064 and obeying the naming conventions in all modules should lead to a better user experience. If someone really needs a deprecated module like std.xml it could always be maintained in a different repository / project but we should remove everything from phobos which doesn't fit our quality standards.
Nov 30 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-30 20:11, Johannes Pfau wrote:

 In the end we would have a 2.062 release with all the old functionality
 (deprecated) and new functionality / names matching our coding
 conventions. Some releases later (e.g. 2.064) all deprecated
 functionality will be removed. Then everyone knows that:
Don't we usually keep deprecated features for 6 months or so? -- /Jacob Carlborg
Dec 01 2012
prev sibling parent reply "sclytrack" <sclytrack thailand.com> writes:
 Some modules should be deprecated as a whole, even if we do not 
 yet
 have a proper replacement yet. For example we know for many 
 years that
 std.xml is broken and nobody is fixing it, but we still ship it 
 with
Shouldn't the new version be called std.xml2 while leaving the old std.xml in phobos? Basically no replacement.
Dec 01 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 00:40:20 sclytrack wrote:
 Some modules should be deprecated as a whole, even if we do not
 yet
 have a proper replacement yet. For example we know for many
 years that
 std.xml is broken and nobody is fixing it, but we still ship it
 with
Shouldn't the new version be called std.xml2 while leaving the old std.xml in phobos? Basically no replacement.
We've talked about doing that with modules that we intend to replace where it doesn't make sense to give them a new name - std.xml being one of them - but nothing like that has happened yet. The closest would be std.regexp -> std.regex and std.date -> std.datetime, and both of those obviously involved renaming. But I would expect std.xml to be replaced with std.xml2 at some point. We _were_ looking at outright throwing std.xml away at one point and then replacing it later, given how bad it is, but we never quite did that, and at this point, I wouldn't expect it to happen. We've been focusing more on avoiding breaking code of late, and so, doing something like that probably wouldn't be deemed acceptable at this point. - Jonathan M Davis
Dec 01 2012
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 01 Dec 2012 16:52:19 -0800
schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 
 Shouldn't the new version be called std.xml2 while leaving the
 old std.xml in phobos? Basically no replacement.
We've talked about doing that with modules that we intend to replace where it doesn't make sense to give them a new name - std.xml being one of them - but nothing like that has happened yet. The closest would be std.regexp -> std.regex and std.date -> std.datetime, and both of those obviously involved renaming. But I would expect std.xml to be replaced with std.xml2 at some point. We _were_ looking at outright throwing std.xml away at one point and then replacing it later, given how bad it is, but we never quite did that, and at this point, I wouldn't expect it to happen. We've been focusing more on avoiding breaking code of late, and so, doing something like that probably wouldn't be deemed acceptable at this point. - Jonathan M Davis
Avoiding breaking code is always a good goal, but I think it's too early for phobos. Code like std.xml, std.outbuffer should have never been a part of phobos. I think one last big break would be best for everyone. Right now we have can't promise not to break code because we can't keep and support code like std.xml forever but we also can't simply remove std.xml because we try to avoid breaking code. So we deprecate small parts of modules in every release which is a pita for everyone. Dropping all sub-par code and fixing naming conventions in one release would get us a clean restart without all that cruft.
Dec 02 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 12:26:24 Johannes Pfau wrote:
 Right now we have can't promise not to break code because
 we can't keep and support code like std.xml forever but we also can't
 simply remove std.xml because we try to avoid breaking code. So we
 deprecate small parts of modules in every release which is a pita for
 everyone. Dropping all sub-par code and fixing naming conventions in
 one release would get us a clean restart without all that cruft.
I've done a lot in the past to try and fix function names which didn't have the correct naming conventions or were otherwise obviously wrong (e.g. the functions in std.ctype returning int instead of bool as if they were C functions rather than D functions), but there's a limit to what we can do, and we've arguably taken too long to resolve a lot of these issues. There's also increased resistance to breaking code. Walter has _always_ been against it pretty much regardless of the reason, and Andrei is starting to come around to his way of thinking. He's even starting to balk at removing functions which have been deprecated even though you have to compile with -d to use them at all. So, I suspect that it's too late at this point to do anything like what you suggest. What I've already done was requested by a lot of people (e.g. fixing the names of the functions in std.string), but it's also resulted in a lot of complaints - especially from those folks trying to use D professionally. And even when we've gotten away with changing things, it's rarely been the case that we've broken stuff immediately. Rather, we've provided new functionality in new names and put the old ones through the deprecation process. So, I'd expect that std.xml would be replaced with std.xml2 rather than being thrown out and immediately replaced with the new std.xml. And while there was some talk at one point of outright throwing out std.xml even though we don't have a replacement yet, and it never happened. So, while I can sympathize with your position and to some extent agree with it, I think that it's too late. - Jonathan M Davis
Dec 02 2012
parent reply "deed" <none none.none> writes:
On Sunday, 2 December 2012 at 12:15:57 UTC, Jonathan M Davis 
wrote:
 On Sunday, December 02, 2012 12:26:24 Johannes Pfau wrote:
 Right now we have can't promise not to break code because
 we can't keep and support code like std.xml forever but we 
 also can't
 simply remove std.xml because we try to avoid breaking code. 
 So we
 deprecate small parts of modules in every release which is a 
 pita for
 everyone. Dropping all sub-par code and fixing naming 
 conventions in
 one release would get us a clean restart without all that 
 cruft.
I've done a lot in the past to try and fix function names which didn't have the correct naming conventions or were otherwise obviously wrong (e.g. the functions in std.ctype returning int instead of bool as if they were C functions rather than D functions), but there's a limit to what we can do, and we've arguably taken too long to resolve a lot of these issues. There's also increased resistance to breaking code. Walter has _always_ been against it pretty much regardless of the reason, and Andrei is starting to come around to his way of thinking. He's even starting to balk at removing functions which have been deprecated even though you have to compile with -d to use them at all. So, I suspect that it's too late at this point to do anything like what you suggest. What I've already done was requested by a lot of people (e.g. fixing the names of the functions in std.string), but it's also resulted in a lot of complaints - especially from those folks trying to use D professionally. And even when we've gotten away with changing things, it's rarely been the case that we've broken stuff immediately. Rather, we've provided new functionality in new names and put the old ones through the deprecation process. So, I'd expect that std.xml would be replaced with std.xml2 rather than being thrown out and immediately replaced with the new std.xml. And while there was some talk at one point of outright throwing out std.xml even though we don't have a replacement yet, and it never happened. So, while I can sympathize with your position and to some extent agree with it, I think that it's too late. - Jonathan M Davis
Why not let all breaking improvements go to a clear cut std2 and let std be improved only with extensions and bug fixes? When std2 is ready enough, let the same happen and breaking code goes to std3. Then you get std.xml and std2.xml, which are different and a probable source of confusion. On the other hand, the modules in the standard library do not exist independently, they are part of a unified design and layout. So it may be more valuable to know that std3.algorithm, std3.range, std3.container, etc. work together out of the box, rather than to know whether std.algorithm2 and std.range3 are compatible. Each library should additionally depend on a specific stable release of D, as discussed recently. (All library bug fixes and extensions are based on that specific release). Thoughts?
Dec 02 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 02, 2012 14:19:18 deed wrote:
 Why not let all breaking improvements go to a clear cut std2 and
 let std be improved only with extensions and bug fixes? When std2
 is ready enough, let the same happen and breaking code goes to
 std3.
 
 Then you get std.xml and std2.xml, which are different and a
 probable source of confusion. On the other hand, the modules in
 the standard library do not exist independently, they are part of
 a unified design and layout. So it may be more valuable to know
 that std3.algorithm, std3.range, std3.container, etc. work
 together out of the box, rather than to know whether
 std.algorithm2 and std.range3 are compatible.
 
 Each library should additionally depend on a specific stable
 release of D, as discussed recently. (All library bug fixes and
 extensions are based on that specific release).
 
 Thoughts?
Duplicating the entire standard library is overkill. Ideally, we wouldn't need to keep making breaking changes to it. You get it right, and then you leave it as-is. The main problem is that Phobos has been being written as the language has been evolving.. That means that we have old stuff that doesn't follow how things are done now (e.g. the naming conventions or being range-based). Once that's fixed, you don't need to keep fixing it. Only a few modules need major overhauls. Most of them have already had it or have been deemed fine. So, there's not much point in setting up a scheme like std2.*. Rather, it makes _far_ more sense to just replace the modules that need replacing. Also, remember that we're trying to minimize code breakage, and requiring that every single import to the standard library get changed periodically goes against that completely. Not to mention, it's not like we want multiple versions of the thing floating around. It's far better to just have those people who use std.xml update their code once std.xml2 is out, and then we phase out std.xml. With your suggestion _everyone_ would have to change their code when that happened. And it's not like different modules are incompatible with other modules in the standard library even if we want to replace some of them. The fact that std.xml isn't range-based does not mean that it doesn't work with the rest of Phobos. And when std.xml2 comes along, it'll work with whatever verson of Phobos is current at the time. The only versioning that's required as far as module compatibility goes is the compiler release, because druntime and Phobos are versioned with it as well. - Jonathan M Davis
Dec 02 2012
parent "deed" <none none.void> writes:
On Sunday, 2 December 2012 at 19:06:22 UTC, Jonathan M Davis 
wrote:
 On Sunday, December 02, 2012 14:19:18 deed wrote:
 Why not let all breaking improvements go to a clear cut std2 
 and
 let std be improved only with extensions and bug fixes? When 
 std2
 is ready enough, let the same happen and breaking code goes to
 std3.
 
 Then you get std.xml and std2.xml, which are different and a
 probable source of confusion. On the other hand, the modules in
 the standard library do not exist independently, they are part 
 of
 a unified design and layout. So it may be more valuable to know
 that std3.algorithm, std3.range, std3.container, etc. work
 together out of the box, rather than to know whether
 std.algorithm2 and std.range3 are compatible.
 Duplicating the entire standard library is overkill. Ideally, 
 we wouldn't need
 to keep making breaking changes to it. You get it right, and 
 then you leave it
 as-is. The main problem is that Phobos has been being written 
 as the language
 has been evolving..
It may introduce more administrative work, but should solve most problems in both camps.
Dec 03 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/2/2012 10:26 PM, Johannes Pfau wrote:
 Avoiding breaking code is always a good goal, but I think it's too
 early for phobos. Code like std.xml, std.outbuffer should have never
 been a part of phobos. I think one last big break would be best for
 everyone.
No, no, no!
 Right now we have can't promise not to break code because
 we can't keep and support code like std.xml forever
Yes, we can (or at least for a very long time).
 but we also can't
 simply remove std.xml because we try to avoid breaking code. So we
 deprecate small parts of modules in every release which is a pita for
 everyone. Dropping all sub-par code and fixing naming conventions in
 one release would get us a clean restart without all that cruft.
No, it won't, because names are a bikeshedding thing and every group of name changes spawns more name change proposals. Every big break (and we've done them before) spawns more big break proposals. We have to stop doing this, or D will never ever advance. The existence of std.xml that is ignored and left out of the documentation is not going to discourage people from using D, but constantly telling people they have to rewrite their existing, working, and stable code will, as the start of this thread shows.
Dec 02 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 2 December 2012 at 21:37:17 UTC, Walter Bright wrote:
 On 12/2/2012 10:26 PM, Johannes Pfau wrote:
 Avoiding breaking code is always a good goal, but I think it's 
 too
 early for phobos. Code like std.xml, std.outbuffer should have 
 never
 been a part of phobos. I think one last big break would be 
 best for
 everyone.
No, no, no!
 Right now we have can't promise not to break code because
 we can't keep and support code like std.xml forever
Yes, we can (or at least for a very long time).
 but we also can't
 simply remove std.xml because we try to avoid breaking code. 
 So we
 deprecate small parts of modules in every release which is a 
 pita for
 everyone. Dropping all sub-par code and fixing naming 
 conventions in
 one release would get us a clean restart without all that 
 cruft.
No, it won't, because names are a bikeshedding thing and every group of name changes spawns more name change proposals. Every big break (and we've done them before) spawns more big break proposals. We have to stop doing this, or D will never ever advance. The existence of std.xml that is ignored and left out of the documentation is not going to discourage people from using D, but constantly telling people they have to rewrite their existing, working, and stable code will, as the start of this thread shows.
And how do you conciliate that with dropping every new stuff directly into master ?
Dec 02 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 8:43 AM, deadalnix wrote:
 And how do you conciliate that with dropping every new stuff directly
 into master ?
I think you're baiting me :-) but I'll respond with that is an orthogonal issue and belongs in the other threads for that topic. I feel the same way about breaking code with language changes as I do for breaking library changes.
Dec 02 2012
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 03 Dec 2012 08:37:15 +1100
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 12/2/2012 10:26 PM, Johannes Pfau wrote:
 Avoiding breaking code is always a good goal, but I think it's too
 early for phobos. Code like std.xml, std.outbuffer should have never
 been a part of phobos. I think one last big break would be best for
 everyone.
No, no, no!
OK, I see I won't convince you so we probably won't have a big break ;-) But I still believe it's too early for phobos to be stable. In the end we have to choose between stabilizing phobos now or having a consistent interface (ranges, naming conventions) in all modules.
 Right now we have can't promise not to break code because
 we can't keep and support code like std.xml forever
Yes, we can (or at least for a very long time).
But having broken, unsupported code like that in phobos isn't exactly good advertising for phobos. And even if we mark it as deprecated and "don't use this" people will keep using it as long as there is no alternative and they will still complain if it's removed later on.
 
 but we also can't
 simply remove std.xml because we try to avoid breaking code. So we
 deprecate small parts of modules in every release which is a pita
 for everyone. Dropping all sub-par code and fixing naming
 conventions in one release would get us a clean restart without all
 that cruft.
No, it won't, because names are a bikeshedding thing and every group of name changes spawns more name change proposals. Every big break (and we've done them before) spawns more big break proposals. We have to stop doing this, or D will never ever advance.
Did we really have big breaks before? If those didn't work out well then another one is probably not a good idea. Regarding names: Choosing the actual name often is bikeshedding but naming conventions (casing, no underscores, etc) are well defined and we still have modules in phobos which don't conform to them.
 
 The existence of std.xml that is ignored and left out of the 
 documentation is not going to discourage people from using D, but 
 constantly telling people they have to rewrite their existing,
 working, and stable code will, as the start of this thread shows.
 
But people may question the standard libraries quality if modules like std.xml are part of it.
Dec 03 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/2/2012 11:52 AM, Jonathan M Davis wrote:
 We _were_ looking at outright throwing std.xml away at one point and then
 replacing it later, given how bad it is, but we never quite did that, and at
 this point, I wouldn't expect it to happen. We've been focusing more on
 avoiding breaking code of late, and so, doing something like that probably
 wouldn't be deemed acceptable at this point.
For this case (and others like it) I strongly suggest putting the revamp in something called std.xml2, and keep std.xml, but let std.xml wither and die away of its own accord rather than killing it. For example, after a while it can be removed from the web site documentation.
Dec 02 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 08:28:30 Walter Bright wrote:
 On 12/2/2012 11:52 AM, Jonathan M Davis wrote:
 We _were_ looking at outright throwing std.xml away at one point and then
 replacing it later, given how bad it is, but we never quite did that, and
 at this point, I wouldn't expect it to happen. We've been focusing more
 on avoiding breaking code of late, and so, doing something like that
 probably wouldn't be deemed acceptable at this point.
For this case (and others like it) I strongly suggest putting the revamp in something called std.xml2, and keep std.xml, but let std.xml wither and die away of its own accord rather than killing it. For example, after a while it can be removed from the web site documentation.
That's basically what I'd expect to happen with this. handled in general in the long term. Without that, I'm not sure what we're going to do, since then deprecating _anything_ breaks code. Regardless, there's some stuff that's already been deprecated which probably should be outright removed at some point here (e.g. the deprecated functions in std.string which don't follow the correct naming conventions), but once that sort of thing has been removed, I think that we should be moving to a model where deprecated stuff becomes undocumented and withers away only to be outright removed with a major release of some kind. Such removals could be made to fit into the stable branch model somehow, but the deprecated symbols would be around a long time before being removed with a major release, and depending, we may not even remove them then. But as deprecations should be becoming rarer as the library stabilizes, this should be less of an issue. - Jonathan M Davis
Dec 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been deprecated which probably
 should be outright removed at some point here (e.g. the deprecated functions
 in std.string which don't follow the correct naming conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.
 but once
 that sort of thing has been removed, I think that we should be moving to a
 model where deprecated stuff becomes undocumented and withers away only to be
 outright removed with a major release of some kind. Such removals could be
 made to fit into the stable branch model somehow, but the deprecated symbols
 would be around a long time before being removed with a major release, and
 depending, we may not even remove them then. But as deprecations should be
 becoming rarer as the library stabilizes, this should be less of an issue.
Dec 02 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
 On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been deprecated which
 probably should be outright removed at some point here (e.g. the
 deprecated functions in std.string which don't follow the correct naming
 conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.
They're clutter, and they've been deprecated for a while, which means that no one has been able to use them without -d for a while. It's also trivial to fix code which uses them, because they're primarily naming changes. It's just not worth keeping that kind of clutter around in the library IMHO. And the documentation has made it clear that they were going to be removed. - Jonathan M Davis
Dec 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
 On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
 On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been deprecated which
 probably should be outright removed at some point here (e.g. the
 deprecated functions in std.string which don't follow the correct naming
 conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.
They're clutter, and they've been deprecated for a while, which means that no one has been able to use them without -d for a while. It's also trivial to fix code which uses them, because they're primarily naming changes. It's just not worth keeping that kind of clutter around in the library IMHO. And the documentation has made it clear that they were going to be removed.
This is really the crux of our disagreement. I do not see a problem with leaving "clutter" around if it prevents breaking existing code. It being trivial to fix user code is not good enough - the fact that the user has to go back and fix stable, working, debugged code is the problem that Chris is saying is preventing him from using D seriously. Remove them from the documentation, ok, but leave them there. It does not hurt to do so. Let them die on their own, we do not need to push them out the airlock.
Dec 02 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 10:32:55 Walter Bright wrote:
 On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
 On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
 On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been deprecated which
 probably should be outright removed at some point here (e.g. the
 deprecated functions in std.string which don't follow the correct naming
 conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.>
They're clutter, and they've been deprecated for a while, which means that no one has been able to use them without -d for a while. It's also trivial to fix code which uses them, because they're primarily naming changes. It's just not worth keeping that kind of clutter around in the library IMHO. And the documentation has made it clear that they were going to be removed.
This is really the crux of our disagreement. I do not see a problem with leaving "clutter" around if it prevents breaking existing code. It being trivial to fix user code is not good enough - the fact that the user has to go back and fix stable, working, debugged code is the problem that Chris is saying is preventing him from using D seriously. Remove them from the documentation, ok, but leave them there. It does not hurt to do so. Let them die on their own, we do not need to push them out the airlock.
Then we're definitely going to disagree. Ideally, no deprecated code would stick around long term. But that creates a practical problem as we do need code to be able to continue to compile for a very long time even if it's not updated, so we do often need to keep deprecated code around long term. In this case, however, we're talking about changes which have long since broken code and which were part of a major shift when cleaning up the library. The only code which would be using them at this point is code that hasn't been updated in quite some time, and so much has changed in both the compiler and the library since those changes were made, that it's not likely that code that old would still work anyway. With an appropriately stable language and API, deprecations can and should take a very long time and possible stick around permanently. But neither the language nor the standard library has been treated as being that stable. They've been becoming more stable, but they've been a work in progress and as such have been breaking code. As we shift to to them being stable, deprecations will then be rarer and more reasonable to keep around. It'll also be far more reasonable to expect code older than a release or three to continue to compile with new releases, which has definitely not been the case with a lot of the library changes that were made in the past (most of which have been completed - the std.string stuff is some of the last stuff still around). I honestly don't expect code compiled with 2.051 to continue to work in general. Too much has changed since then, much of which was done in an attempt to clean up Phobos prior to committing to having a stable API that we expect to continue to work for years to come. We've been giving people who maintain their code ample notice and ample time to fix their code as we've progressed, but we haven't been operating with the idea that old code would compile 9 releases later. Rather, we've been trying to clean stuff up so that we could operate that way without having to maintain bad code forever (or to at least minimize that). We do need to start operating with the idea that code will compile 9+ releases later, but stuff like the std.string deprecations were not done with the idea that they would stay around long term. So, I see stuff like the std.string deprecations as being fundamentally different from deprecations that will happen in the future. We're moving from a model where we were trying to clean up the standard library in order to stabilize it to one where it's stable and shouldn't be changing that much aside from additions. And I think that it's perfectly reasonable to treat deprecations differently in those two situations. So, I'm definitely going to push for removing stuff that's already been deprecated. It's already broken people's code by being deprecated due to how deprecated currently works, so it's really not going to cost anyone much for them to be outright removed now. And in the case of the std.string deprecations, they'll even get nice messages asking them things like if they really meant toLower instead of tolower. I don't like leaving clutter in code, and in this case, I think that it's safe and reasonable to clean up that clutter. - Jonathan M Davis
Dec 02 2012
next sibling parent reply "Joshua Niehus" <jm.niehus gmail.com> writes:
On Sunday, 2 December 2012 at 23:56:29 UTC, Jonathan M Davis 
wrote:
[... <breath> snip </breath> ...]

 I don't like leaving clutter in code, and in this case, I think 
 that it's safe
 and reasonable to clean up that clutter.

 - Jonathan M Davis
+1
Dec 02 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
 I don't like leaving clutter in code, and in this case, I 
 think that it's safe and reasonable to clean up that clutter.

 - Jonathan M Davis
+1
-1. There's really no harm in leaving it there. On my hard drive, I have somewhere in the ballpark of a gigabyte of code saved (includes random apps I've compiled over the years). I don't know what most of it is, and I don't really care. If I need it, its there, and if not, whatever, there's not much, if anything, of a downside to having crap saved. My hard drive is still 75% free, access to the files I want is as fast as ever, and so on. With deprecated alias.... if you don't use it, whatever. With old code, if you don't use it.... you won't even notice its there. The only real downside I can think of is making the full download a bit slower. I don't think this is important. zipped code is small code. Besides, with the real world "problem" today, what are we even talking about? 50 kilobytes? Big deal.
Dec 02 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 02:58:57 Adam D. Ruppe wrote:
 On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
 I don't like leaving clutter in code, and in this case, I
 think that it's safe and reasonable to clean up that clutter.
 
 - Jonathan M Davis
+1
-1. There's really no harm in leaving it there. On my hard drive, I have somewhere in the ballpark of a gigabyte of code saved (includes random apps I've compiled over the years). I don't know what most of it is, and I don't really care. If I need it, its there, and if not, whatever, there's not much, if anything, of a downside to having crap saved. My hard drive is still 75% free, access to the files I want is as fast as ever, and so on. With deprecated alias.... if you don't use it, whatever. With old code, if you don't use it.... you won't even notice its there. The only real downside I can think of is making the full download a bit slower. I don't think this is important. zipped code is small code. Besides, with the real world "problem" today, what are we even talking about? 50 kilobytes? Big deal.
It's messy and ugly to leave dead code around in a library. It also makes it so that it's possible for people to keep writing code which uses it when they shouldn't be. I'm all for moving to a model where we keep deprecated stuff around for stuff that we deprecate in the future, but I'm completely against leaving the stuff that we currently have deprecated around. It was changed in an effort to clean up the library in preparation for having a clean, stable API, and leaving it around is messy and counter to that purpose. - Jonathan M Davis
Dec 02 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 1:03 PM, Jonathan M Davis wrote:
 It's messy and ugly to leave dead code around in a library. It also makes it
 so that it's possible for people to keep writing code which uses it when they
 shouldn't be.
It is not dead code, there are people using it. As for aesthetics, it can be moved to the end of the module, and visually segregated. Also, if the documentation for it is removed, I seriously doubt that sensible people will use it in new code.
 I'm all for moving to a model where we keep deprecated stuff around for stuff
 that we deprecate in the future, but I'm completely against leaving the stuff
 that we currently have deprecated around. It was changed in an effort to clean
 up the library in preparation for having a clean, stable API, and leaving it
 around is messy and counter to that purpose.
Breaking peoples' existing, working, stable code is worse than offending a notion of clutter, especially because only phobos developers will even see that clutter.
Dec 02 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 December 2012 at 02:04:01 UTC, Jonathan M Davis 
wrote:
 It's messy and ugly to leave dead code around in a library.
It's messier and uglier to break everyone else's code because a small group of people with phobos access decided to unilaterally change things. There's an easy solution to this btw, a versioning scheme in module names: --- module std.xml; pragma(msg, "std.xml sux. if you don't wanna break code import std.xml.1 instead. if you wanna use the rox version the latest is std.xml.2"); public import std.xml.1; /* legacy support */ /* if this wasn't an already existing module, we would static assert(0) instead of pragma msg. NEVER use a naked import like this since it is guaranteed to break. At least by picking a major version, you have a fighting chance of unmodified code still working out of the box down the line */ --- module std.xml.1; public import std.xml.1.4; --- module std.xml.1.4; // random number btw /* current std.xml */ --- module std.xml.2; public import std.xml.2.0; --- module std.xml.2.0; /* a brand new std.xml */ --- The package as module thing is some DIP magic but we could do without by naming it std.xml_2 and std.xml_2_0 or whatever too. Anyway the rules are: 1) Less specific numbers simply forward you to the next specific module, just like symlinks do on the ideal unix .so library. All modules from here on out have a version number, but current modules are grandfathered in, albeit perhaps deprecated. 2) The most specific thing includes the actual code 3) once a file has been released, it is immutable. ALL releases with changes bump up the version number accordingly and go to a new file. I'm sure we can do some kind of git tagging script or whatever to make this simple. 4) Users import a particular major version normally, or may import a minor version if they really want to get super specific. Boom, code never breaks and we have prettiness.
Dec 02 2012
prev sibling parent reply "Rob T" <rob ucora.com> writes:
To resolve this kind of no-win argument, you have to solve the 
root problem.

You cannot use an unstable version of D as a stable version, for 
obvious reasons, each new stable release of D "stable" appears to 
be a new unstable release of D.

It won't work to simply lock down D into only a stable version. 
Doing that will piss off a lot of people who want to see new 
breaking improvements implemented and released for use, and not 5 
years later either, but a lot sooner.

Here's a simple example of a possible real solution for Phobos, 
for sake of discussion I'm assuming DMD will be released under a 
major.minor.revision numbering system, with stable and unstable 
branches.

1) Assign Phobos it's own independent major.minor.revision number 
with the major number locked in with the corresponding compatible 
major DMD number. That way, users will know what Phobos version 
is compatible with what DMD version.

2) Include multiple backwards compatible versions of Phobos with 
each DMD release stored in a way that allows versions of Phobos 
to be selectable by the D programmer.

I know that there are plenty of challenges to overcome wrt 
changing the way D is being developed and released, but to try 
and develop D using only one version for both stable and unstable 
is simply not going to work. It also will not work to lock down D 
and prevent it from improving in breaking ways overthe next 5 
years (or whatever).

--rt
Dec 02 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 02:49:39 Rob T wrote:
 I know that there are plenty of challenges to overcome wrt
 changing the way D is being developed and released, but to try
 and develop D using only one version for both stable and unstable
 is simply not going to work. It also will not work to lock down D
 and prevent it from improving in breaking ways overthe next 5
 years (or whatever).
There is still a considerable difference between a library which is intended to be stable and one which is under heavy development. We've essentially been working under a model where the API was fluid enough that we could break code as long as we gave enough warning first. We want to move to a model where the API is stable enough that code written now will compile 5+ years from now with no changes. We can still look at phasing out stuff that needs to be replaced. It's just that we then need to keep it around (even if it's deprecated and undocumented), whereas when the API is under heavier development, more permanent breakage has been permissible. For instance, std.date is dead and gone, having been replaced by std.datetime, and that was a good decision at the time given the level of stability of the library. But if we were to replace std.xml with std.xml2 now, we would need to keep std.xml around long term (even if it's deprecated and undocumented) so that code would continue to compile for years to come, because we've reached a point when we want to have a stable API that people can rely on rather than trying to clean up all of the little things that we were trying to clean up before. So, yes having a development and stable branch will help manage things, but even with that separation, we don't want to be breaking people's code due to library changes. - Jonathan M Davis
Dec 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 1:00 PM, Jonathan M Davis wrote:
 So, yes having a development and stable branch will help manage things, but
 even with that separation, we don't want to be breaking people's code due to
 library changes.
I agree with that sentiment, but I find it to be completely at odds with your desire to clean up and remove clutter from Phobos whether or not that breaks user code.
Dec 02 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 03, 2012 13:28:05 Walter Bright wrote:
 On 12/3/2012 1:00 PM, Jonathan M Davis wrote:
 So, yes having a development and stable branch will help manage things,
 but
 even with that separation, we don't want to be breaking people's code due
 to library changes.
I agree with that sentiment, but I find it to be completely at odds with your desire to clean up and remove clutter from Phobos whether or not that breaks user code.
My goal has been to clean up Phobos so that we have an API which is reasonable to keep as it is with minor changes, if any at all. Doing so requires breaking code, but once it's done, then you have a clean, stable API. Further changes may end up being necessary from time to time, but they'd be rare and would be done in a backwards compatible manner. But as long as the clean up phase is underway, breaking changes would be invevitable. As such, I've been perfectly willing to break code as long as there's been warning given first so that people could change their code according to the API changes, but we're moving to a phase where that's not what we want to be doing anymore. Arguably, the cleaning that has happened has taken too long, and there's still some left which probably needs to be cleaned up, but regardless, we need to start focusing on stabilizing what we have. Fortunately though, most of the APIs that needed fixing have been fixed, and for the most part, those that still need to be fixed are in modules which need to be outright replaced anyway, so we can use the std.xml -> std.xml2 scheme to deal with those. It's never been the case that I've wanted to break Phobos' APIs all the time in order to make minor improments to them. It's just that I've wanted to clean them up further before stabilizing on what they'll ultimately be. - Jonathan M Davis
Dec 02 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 2 December 2012 at 23:32:56 UTC, Walter Bright wrote:
 On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
 On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
 On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been 
 deprecated which
 probably should be outright removed at some point here (e.g. 
 the
 deprecated functions in std.string which don't follow the 
 correct naming
 conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.
They're clutter, and they've been deprecated for a while, which means that no one has been able to use them without -d for a while. It's also trivial to fix code which uses them, because they're primarily naming changes. It's just not worth keeping that kind of clutter around in the library IMHO. And the documentation has made it clear that they were going to be removed.
This is really the crux of our disagreement. I do not see a problem with leaving "clutter" around if it prevents breaking existing code. It being trivial to fix user code is not good enough - the fact that the user has to go back and fix stable, working, debugged code is the problem that Chris is saying is preventing him from using D seriously. Remove them from the documentation, ok, but leave them there. It does not hurt to do so. Let them die on their own, we do not need to push them out the airlock.
The thing that you'll never agree. In fact you are both right : user must be able to rely on D to compile their code for an extended period of time, and cruft must be cleaned at some point. The 2 are really important. This is why both MUST be ensured, using 2 branches. Thoses 2 goal are not reconcilable, and no discussion will come up with the best solution. This disagreement is a symptom of a bigger issue.
Dec 02 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/3/2012 3:32 AM, Walter Bright пишет:
 On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
 On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
 On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
 Regardless, there's some stuff that's already been deprecated which
 probably should be outright removed at some point here (e.g. the
 deprecated functions in std.string which don't follow the correct
 naming
 conventions),
I do not see a compelling reason to remove them. Just leave them deprecated.
They're clutter, and they've been deprecated for a while, which means that no one has been able to use them without -d for a while. It's also trivial to fix code which uses them, because they're primarily naming changes. It's just not worth keeping that kind of clutter around in the library IMHO. And the documentation has made it clear that they were going to be removed.
This is really the crux of our disagreement. I do not see a problem with leaving "clutter" around if it prevents breaking existing code.
Code is not broken it just works only with version xyz. The library is only a part of the picture. The other 3rd party code also does change. So is the compiler.
 It being
 trivial to fix user code is not good enough - the fact that the user has
 to go back and fix stable, working, debugged code is the problem that
 Chris is saying is preventing him from using D seriously.
It is strange to crave for the latest version and expecting nothing to change. But it's very human thing to want it. My experience is that old modules are usually not properly maintained nor critical bugs are fixed. As long as scarce unittests pass its deemed working fine. If changes were only for the sake of change in API I might agree with you. For instance I had to patch std.outbuffer for DMDScript on D2 to work (not just compile but *work*). Even back then the patch was rejected. So what to do? Download the old version and maintain it on your own. It's Opensource after all. Same goes for std.signal, std.regexp. Just keeping them forever in the standard library has it share of problems. - There is a whole cluster of people who learn by example that is the old code (not the official docs). - If they are in library then we take the burden for keeping these cadavers going. - Bottom line is that 10 year from now we would still have to deal with them daily (and the bugs nobody knows how to fix) but without the documentation. Dead code is unavoidable (and grim) part of open-source. Not a single project lives without the constant work on accommodating updates to its components.
 Remove them from the documentation, ok, but leave them there. It does
 not hurt to do so. Let them die on their own, we do not need to push
 them out the airlock.
Either way it's compiler bug-fixes that amount to the most of code broken. It was wrong code but we had no spec and it seemed to work. Everything in the library goes through a painful cycle of about a year. During that time the most code that is "just there" in the wild got broken over a trivial fix in the compiler anyway. The truth of it is that the code wont update itself and it's too damn early to expect it to be backwards compatible forever. You may want it badly but it's not going to happen without a full halt of development on all fronts. And that's something nobody wants. Like I said deprecation is the part of every evolving library project under the sun. Let's finally accept some evolutionary process (and rules) and follow it. -- Dmitry Olshansky
Dec 02 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 6:48 PM, Dmitry Olshansky wrote:
 My experience is that old modules are usually not properly maintained
 nor critical bugs are fixed. As long as scarce unittests pass its deemed
 working fine.

 If changes were only for the sake of change in API I might agree with you.
Except that is what a lot of them are - simply name changes. Also, I have updated a lot of code to deal with removed Phobos functions and modules. This code was *not* broken in its original form.
Dec 03 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-02 22:28, Walter Bright wrote:

 For this case (and others like it) I strongly suggest putting the revamp
 in something called std.xml2, and keep std.xml, but let std.xml wither
 and die away of its own accord rather than killing it.
Then we'll be stuck with a stupid name like xml2, just because the correct name was already taken by something broken. -- /Jacob Carlborg
Dec 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
 On 2012-12-02 22:28, Walter Bright wrote:

 For this case (and others like it) I strongly suggest putting the revamp
 in something called std.xml2, and keep std.xml, but let std.xml wither
 and die away of its own accord rather than killing it.
Then we'll be stuck with a stupid name like xml2, just because the correct name was already taken by something broken.
So call it xmlex like Microsoft does. The exact name isn't that precious.
Dec 03 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 3 December 2012 at 08:37:24 UTC, Walter Bright wrote:
 On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
 On 2012-12-02 22:28, Walter Bright wrote:

 For this case (and others like it) I strongly suggest putting 
 the revamp
 in something called std.xml2, and keep std.xml, but let 
 std.xml wither
 and die away of its own accord rather than killing it.
Then we'll be stuck with a stupid name like xml2, just because the correct name was already taken by something broken.
So call it xmlex like Microsoft does. The exact name isn't that precious.
It is.
Dec 03 2012
parent "Chris" <wendlec tcd.ie> writes:
Thank you all for taking my input seriously. I do appreciate it. 
I can understand both "parties", but I think not breaking code is 
more important than the ideal of a clean library. The reality of 
coding is (as we all know) that programmers cannot constantly 
update their code, because there are other more urgent things to 
be done (bug fixes, new modules etc.). I think it is not fair to 
accuse a programmer of carelessness simply because s/he didn't 
have time to check all the deprecation warnings in the library. 
And from a marketing point of view it's never a good idea to put 
off users by telling them "Ah don't complain, it's your own 
fault, you simply weren't careful enough!"

Also, the existence of deprecated methods doesn't encourage me 
(or others, as far as I know) to keep on using them forever. What 
usually happens is that when I start to write new code, I use the 
new methods as soon as they are available (no matter which 
language I use), and once I am familiar with them, I can step by 
step replace the old deprecated methods with the new ones. So, 
the reason I wanted to use the latest version of D was exactly 
because I wanted to use the new methods. But what happened was 
that I could not use the new methods, because I had to use an 
older version of D, yet I didn't want to write new code using 
deprecated methods. I got stuck properly.

I think ideals have to be adjusted to the reality of coding and 
not vice versa. I do want to keep on using D as it solved a lot 
of problems for me and I will update my code once things have 
calmed down.
Dec 03 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/12 3:37 AM, Walter Bright wrote:
 On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
 On 2012-12-02 22:28, Walter Bright wrote:

 For this case (and others like it) I strongly suggest putting the revamp
 in something called std.xml2, and keep std.xml, but let std.xml wither
 and die away of its own accord rather than killing it.
Then we'll be stuck with a stupid name like xml2, just because the correct name was already taken by something broken.
So call it xmlex like Microsoft does. The exact name isn't that precious.
I'm thinking it would be nice to just define a package xtd that contains "new style" std libraries. Andrei
Dec 03 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I'm thinking it would be nice to just define a package xtd that 
 contains "new style" std libraries.
Where do you put the libs if there's one more update? Calling it std.xml2, std.xml3, etc is easy to understand and to find, it's short and future proof, and there's no need to remember new names like "xmlex" (I sometimes don't remember what's the name of the updated regex lib. If they are named std.re1, std.re2, std.re3, etc there isn't that risk). Bye, bearophile
Dec 03 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 December 2012 at 15:56:53 UTC, bearophile wrote:
 Calling it
 std.xml2, std.xml3, etc is easy to understand and to find, it's
 short and future proof
Yes. And if we also do std.xml1 then going to 2 won't seem weird. We've had version discussions before, both here and on project downloads like that one DIP. The easiest solution for libraries, old projects, and end users is to just stick a number in the name. Easy, obvious, functional.
Dec 03 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/12 10:56 AM, bearophile wrote:
 Andrei Alexandrescu:

 I'm thinking it would be nice to just define a package xtd that
 contains "new style" std libraries.
Where do you put the libs if there's one more update? Calling it std.xml2, std.xml3, etc is easy to understand and to find, it's short and future proof, and there's no need to remember new names like "xmlex" (I sometimes don't remember what's the name of the updated regex lib. If they are named std.re1, std.re2, std.re3, etc there isn't that risk). Bye, bearophile
Yup, there's a certain advantages to using numbers :o). Andrei
Dec 03 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2012 3:23 AM, Andrei Alexandrescu wrote:
 Yup, there's a certain advantages to using numbers :o).
It's almost like there's an implied ordering to them!
Dec 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 30 November 2012 at 15:04:02 UTC, Chris wrote:
 I have this sinking feeling that this is killing the language.
I feel your pain. I often wonder if the Phobos developers actually use D.
Nov 30 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:

 I started with D2 version 2.051 and created a medium-sized 
 project fairly quickly, but now I have a lot of deprecated 
 methods in my code. I couldn't keep up with all the changes and 
 I have been hesitant to update my code because there are still 
 a lot of "Will be removed in September/November/December ..." 
 warnings in the library. Much that I like D, I simply cannot 
 develop in D at the moment due to the constant changes in the 
 Phobos library. I have this sinking feeling that this is 
 killing the language.
Phobos is young, and several of its parts were designed by one or very few persons. So I think some changes are inevitable. Deprecation messages have the purpose to reduce the pain of updated. So those are not killing the language. In Phobos some changes are planned or are expected, like in std.algorithm.max/min, reduce, etc. Bye, bearophile
Nov 30 2012
parent reply "jerro" <a a.com> writes:
 In Phobos some changes are planned or are expected, like in 
 std.algorithm.max/min, reduce, etc.
What changes to std.algorithm.max/min are expected?
Nov 30 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
jerro:

 What changes to std.algorithm.max/min are expected?
Some time ago I have asked for some changes in max/min: http://d.puremagic.com/issues/show_bug.cgi?id=4705 Later Andrei has shown related different functions in two of his recent talks. I don't know what Andrei now thinks about such changes. Bye, bearophile
Nov 30 2012
parent reply "jerro" <a a.com> writes:
On Friday, 30 November 2012 at 17:00:15 UTC, bearophile wrote:
 jerro:

 What changes to std.algorithm.max/min are expected?
Some time ago I have asked for some changes in max/min: http://d.puremagic.com/issues/show_bug.cgi?id=4705 Later Andrei has shown related different functions in two of his recent talks. I don't know what Andrei now thinks about such changes. Bye, bearophile
Those proposed changes to min and max look useful. They shouldn't break much code either.
Nov 30 2012
parent reply "Chris" <wendlec tcd.ie> writes:
There have been quite a few changes since 2.051 and I cannot 
stick to that version, because I would introduce more deprecated 
code. I wanted to update my code but saw in the library that 
again loads of methods were scheduled for deprecation. So what's 
the point?

Changes are necessary and I think they are reasonable (like the 
regex algorithm), but as a developer who uses D, you need some 
sort of security, i.e. that your code won't break in a few 
months' time. I really appreciate the fantastic work on D, but 
sometimes it seems to me like a "code laboratory" where 
programmers test certain ideas, algorithms, approaches etc, which 
would be fine for a college project. But if you have to use and 
work with the library to develop real world applications, it's a 
nightmare. If this doesn't change, I fear D will never take off. 
Most frameworks at least "tolerate" deprecated functions until 
developers have time to update their code.
Nov 30 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:

 But if you have to use and work with the library to develop 
 real world applications, it's a nightmare. If this doesn't 
 change, I fear D will never take off.
It's useful to know your pain experience, but please don't turn this thread into FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt ). Possible solutions only come from more rational discussions. In another thread people are discussion a solution that will help you, a "Stable D", updated only once in a time, like every 6-8-12 months, that has no know regressions and where only nonbreaking changes are allowed (here Phobos modules deprecations are probably to be intended as breaking changes). Bye, bearophile
Nov 30 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2012 4:47 AM, bearophile wrote:
 In another thread people are discussion a solution that will help you, a
 "Stable D", updated only once in a time, like every 6-8-12 months, that
 has no know regressions and where only nonbreaking changes are allowed
 (here Phobos modules deprecations are probably to be intended as
 breaking changes).
I don't view the stable/dev branches of D as being a license to break existing code. Breaking code in the dev version should only be done if there's a very large benefit/cost ratio. Not for bikeshedding reasons, and not if there's a way we can keep the old behavior around.
Dec 02 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/30/2012 9:27 PM, Chris пишет:
 There have been quite a few changes since 2.051 and I cannot stick to
 that version, because I would introduce more deprecated code. I wanted
 to update my code but saw in the library that again loads of methods
 were scheduled for deprecation. So what's the point?
Java has plenty deprecated stuff. So does *cough* php. So do other languages. That alone is not an indication of anything except of the on-going development. There are always references to (usually) better replacements. There are still cases of simple renaming to make functions follow the convention, but these ones are easily fixed with find/replace.
 Changes are necessary and I think they are reasonable (like the regex
 algorithm), but as a developer who uses D, you need some sort of
 security, i.e. that your code won't break in a few months' time. I
 really appreciate the fantastic work on D, but sometimes it seems to me
 like a "code laboratory" where programmers test certain ideas,
 algorithms, approaches etc, which would be fine for a college project.
 But if you have to use and work with the library to develop real world
 applications, it's a nightmare.
I'd just keep certain version of the compiler & phobos + libs that are needed. And then when deadlines are passed do some refactoring/tweaking to bump used versions up a notch. I agree that it's far from ideal.
 If this doesn't change, I fear D will
 never take off. Most frameworks at least "tolerate" deprecated functions
 until developers have time to update their code.
The deprecated APIs do still work if you use the -d switch. What is far more shattering are compiler changes (and bugfixes, sadly) given that 2.051 is 9 versions behind he latest it won't surprise me that it breaks a _lot_.
 Most frameworks at least "tolerate" deprecated functions
 until developers have time to update their code.
Problem is these frameworks also have certain version requirement last time I checked it goes like this: requires php 5.3+ or say python 2.5+ etc. So we'd better have certain D versions that are more lasting. But that'll make sense once the feature set is fully implemented and polished. Anyway see D stable topic. -- Dmitry Olshansky
Nov 30 2012
parent "Chris" <wendlec tcd.ie> writes:
Great to hear that. I'd like to see D take off one day.
Nov 30 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-30 16:04, Chris wrote:
 Is there a way of telling when things in the library will calm down and
 it'll be save to develop in D and update old code?

 I started with D2 version 2.051 and created a medium-sized project
 fairly quickly, but now I have a lot of deprecated methods in my code. I
 couldn't keep up with all the changes and I have been hesitant to update
 my code because there are still a lot of "Will be removed in
 September/November/December ..." warnings in the library. Much that I
 like D, I simply cannot develop in D at the moment due to the constant
 changes in the Phobos library. I have this sinking feeling that this is
 killing the language.
You can either stay at a given version of D. Or you could use something more stable than Phobos. Tango, for example, is very stable. The problem is that it doesn't receive much changes at all. https://github.com/SiegeLord/Tango-D2 http://www.dsource.org/projects/tango/docs/current/ -- /Jacob Carlborg
Nov 30 2012
parent reply "sclytrack" <sclytrack thailand.com> writes:
 You can either stay at a given version of D. Or you could use 
 something more stable than Phobos. Tango, for example, is very
The problem with sticking to a certain version is that all the third party libraries are sticking to a previous or next version (eh ... sometimes same version). Requiring slight modifications for every (eh...) third party library.
Dec 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-02 00:47, sclytrack wrote:

 The problem with sticking to a certain version is that all the third
 party libraries are sticking to a previous or next version (eh ...
 sometimes same version). Requiring slight modifications for every
 (eh...) third party library.
Yeah, there's no silver bullet that solves all the problems. -- /Jacob Carlborg
Dec 02 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 30, 2012 16:04:01 Chris wrote:
 Is there a way of telling when things in the library will calm
 down and it'll be save to develop in D and update old code?
 
 I started with D2 version 2.051 and created a medium-sized
 project fairly quickly, but now I have a lot of deprecated
 methods in my code. I couldn't keep up with all the changes and I
 have been hesitant to update my code because there are still a
 lot of "Will be removed in September/November/December ..."
 warnings in the library. Much that I like D, I simply cannot
 develop in D at the moment due to the constant changes in the
 Phobos library. I have this sinking feeling that this is killing
 the language.
A lot of changes were being done for a while to try and rename stuff to the follow the correct naming scheme and make other needed adjustments. That has dropped off considerably however and the goal is to make deprecations rare. It's just that there were a lot of changes that needed to be made to clean up the library. Most of that has been done has been done now, and the remainder is likely to just not be cleaned up or to stick around long term with an alternative which has been cleaned up. We don't want a lot of churn in the standard library. We want it to be stable so that people can rely on their code continuing to compile. At present, there should be very little which is currently scheduled for deprecation, and it's unknown how long the stuff which has been actually deprecated will stay around. We were removing after 6 months of deprecation but have been re-examining that. What we're trying to get Walter to do is to make it so that deprecated just generates warnings, not errors (rather a new flag will be added to make them generate errors if that's what you want, and -d will stay the same). With that, anything that gets deprecated should stick around for quite a while (though there's a good chance that it'll end up being undocumented after a while in order to further discourage its use), and it won't actually prevent compilation, just bug you to update your code. But as deprecations should become much rarer, even that won't happen anywhere near as often. There's an open pull request to make the change, but Walter hasn't agreed to it yet: https://github.com/D-Programming-Language/dmd/pull/1287 I'd very much like to see the large blocks of stuff that was renamed or moved fully removed rather than sticking around as deprecated (e.g. std.ctype and all of the deprecated functions in std.string should go away), but we do want to be moving away from making large breaking changes like that, and deprecations should become quite rare. Pretty much all of those kind of changes which have been suggested recently have been rejected. - Jonathan m Davis
Nov 30 2012
prev sibling parent "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Friday, 30 November 2012 at 15:04:02 UTC, Chris wrote:
 Is there a way of telling when things in the library will calm 
 down and it'll be save to develop in D and update old code?

 I started with D2 version 2.051 and created a medium-sized 
 project fairly quickly, but now I have a lot of deprecated 
 methods in my code. I couldn't keep up with all the changes and 
 I have been hesitant to update my code because there are still 
 a lot of "Will be removed in September/November/December ..." 
 warnings in the library. Much that I like D, I simply cannot 
 develop in D at the moment due to the constant changes in the 
 Phobos library. I have this sinking feeling that this is 
 killing the language.
Why not make a branch of D then use the patch as the source for your compilation. When new changes occur you can try them out. If they break your source then try and update your branch with only things that do not break your source. No one is forcing you to use a newer version of D. The only purpose is for stability and enhancements. Not all stability patches and enhancements will break your code(many with be orthogonal). Obviously the drawback is managing the branch, but if it's such a big issue it can be done.
Dec 01 2012