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

Great to hear that. I'd like to see D take off one day.

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.

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

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

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.

>
> 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.

>
> 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.

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

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.