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