Deprecated Library Functions / Methods

Jonathan M Davis jmdavisProg at gmx.com
Sun Dec 2 11:05:43 PST 2012


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


More information about the Digitalmars-d mailing list