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

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?

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

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

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.

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.

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.

And if you accept dmd pull# 1287, then that's probably how deprecation will be 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

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 ?

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.

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.