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?
