On Sunday, 2 December 2012 at 19:06:22 UTC, Jonathan M Davis wrote:
> 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.

>
> 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..

It may introduce more administrative work, but should solve most problems in both camps.

On 12/3/12 3:37 AM, Walter Bright wrote:
> On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
>> On 2012-12-02 22:28, Walter Bright wrote:
>>
>>> 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.
>>
>> Then we'll be stuck with a stupid name like xml2, just because the
>> correct name was already taken by something broken.
>
> So call it xmlex like Microsoft does. The exact name isn't that precious.

I'm thinking it would be nice to just define a package xtd that contains "new style" std libraries.

Andrei

Andrei Alexandrescu:

> I'm thinking it would be nice to just define a package xtd that contains "new style" std libraries.

Where do you put the libs if there's one more update? Calling it
std.xml2, std.xml3, etc is easy to understand and to find, it's
short and future proof, and there's no need to remember new names
like "xmlex" (I sometimes don't remember what's the name of the
updated regex lib. If they are named std.re1, std.re2, std.re3,
etc there isn't that risk).

Bye,
bearophile

On Monday, 3 December 2012 at 15:56:53 UTC, bearophile wrote:
> Calling it
> std.xml2, std.xml3, etc is easy to understand and to find, it's
> short and future proof

Yes. And if we also do std.xml1 then going to 2 won't seem weird.

We've had version discussions before, both here and on project downloads like that one DIP. The easiest solution for libraries, old projects, and end users is to just stick a number in the name.

Easy, obvious, functional.

On 12/3/12 10:56 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I'm thinking it would be nice to just define a package xtd that
>> contains "new style" std libraries.
>
> Where do you put the libs if there's one more update? Calling it
> std.xml2, std.xml3, etc is easy to understand and to find, it's
> short and future proof, and there's no need to remember new names
> like "xmlex" (I sometimes don't remember what's the name of the
> updated regex lib. If they are named std.re1, std.re2, std.re3,
> etc there isn't that risk).
>
> Bye,
> bearophile

Yup, there's a certain advantages to using numbers :o).

Andrei

Am Mon, 03 Dec 2012 08:37:15 +1100
schrieb Walter Bright <newshound2@digitalmars.com>:

> 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!
> 

OK, I see I won't convince you so we probably won't have a big
break ;-) But I still believe it's too early for phobos to be stable.

In the end we have to choose between stabilizing phobos now or having a consistent interface (ranges, naming conventions) in all modules.

> > 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 having broken, unsupported code like that in phobos isn't exactly good advertising for phobos. And even if we mark it as deprecated and "don't use this" people will keep using it as long as there is no alternative and they will still complain if it's removed later on.
> 
> > 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.

Did we really have big breaks before? If those didn't work out well then another one is probably not a good idea.

Regarding names: Choosing the actual name often is bikeshedding but naming conventions (casing, no underscores, etc) are well defined and we still have modules in phobos which don't conform to them.
> 
> 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.
> 

But people may question the standard libraries quality if modules like std.xml are part of it.

On 12/4/2012 3:23 AM, Andrei Alexandrescu wrote:
> Yup, there's a certain advantages to using numbers :o).

It's almost like there's an implied ordering to them!