Deprecated Library Functions / Methods

[deed]

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?